Lengderapport i V1, summering lengde bilveg, ramper, sykkelveg => denne fines nå i V2 og V3 – rapportern. Merk at tomme rader filtreres vekk, så hvis du ikke har ramper så har du ingen rad for ramper.
Innspill: Sett inn ordet «herav» på det som er delsummer (herav rundkjøring, herav rampe osv).
Vi har løst problemet med at trafikantgrukke i vegsystemreferanse gir feilmelding når du limer inn vegsystemreferanser fra vegkart. For eksempel EV39 K S21D1
Innspill: Krevende å få oversikt over tilstand på stikkrenner (og for så vidt alt som dreier seg om tilstandsgrad, tilstand / skade m.m.).
Idé til ny rapport: Mor-> datter rapport. Vi tror dette kan gi en enkel oversikt over hvilke tilstandsobjekter som er knyttet til vegobjekt, og i tillegg ha stor bruksverdi for alle andre som trenger denne typen logikk (for eksempel skiltpunkt-> skiltplater, tunnel->tunnelløp og så videre).
Gamle Datafangst:
Loggen forsvant – og vi måtte bruke tid på å finne dem igjen.
Fikset feil på «vis kun valgte» muligheten.
Rekkefølgen på egenskaper i datafanen var tilfeldig sortert, endret slik at vi bruker den rekkefølgen som er presisert i datakatalogen.
Nye Datafangst – hva jobber vi med?
Jobber med kontraktløs redigering og lagring til NVDB (på vegobjekter som allerede finnes i NVDB).
DF er blitt smartere med hvordan og når vi henter data fra NVDB LES versus når vi kun henter statistikk over antall objekter, og hvordan dette tegnes i kartet: DF-kartet oppfører seg mer likt som Vegkart når det er for mange vegobjekt til at det gir mening å tegne alt i kartet samtidig. Innspill: Mouseover med informasjon på klynger (cluster) i kartet.Tilføyelse: Etter møtet foreslo utviklerne at dette ønsket diskuteres på neste møte i DF referansegruppe.
Valg av operasjon ved kontraktløs innsending. Flere forbedringer på GUI for redigering.
Tilgang og roller: En rekke oppgaver knyttet til tilganger og roller, f.eks innlogging via norge.no for folk utafor SVV. Sikkerhetstest neste uke, viktig milepæl som avhenger av at rollene er etablert både i norge.no og i TESTPROD-miljøet (også kalt akseptansetest, ATM).
Har løst noen oppgaver knyttet til håndtering av kontrakter, milepælsplaner og maler for milepæler og leveranseplan (f.eks dra-og-slipp for å endre rekkefølge på en milepælsplan eller leveranseplan).
Kan bruke trafikantgruppe som stedfestingsparameter. Håndtere eksport av flategeometri til SOSI.
Flere forbedringer på det tekniske maskineriet som er usynlig for brukerne.
Status designarbeid nye datafangst
Systematiserer data fra brukerintervju, hva er smertepunkt i dagens løsning og hvordan kan vi gjøre det bedre i nye DF? Bygger brukerreiser for hvordan ulike folk i ulike roller jobber i dagens DF, og hvilke ønsker og problemer de har. Det største problemet: Brukerne har ikke nok oversikt over oppgavene de må løse. (På hvilken måte da?). Designarbeidet fokuserer på arbeidsflyt for kombinert stedfesting og sammenkobling, men noterer seg også alle problemstillinger knyttet til andre deler av arbeidsflyten.
Nye datafangst – live demo av utviklingsmiljø
Antall vegobjekt i kartet. Oppfrisking uten at vegobjekt lastes inn på ny (laster kun dem som er nye ift det nye kartutsnittet).
Vise kluster (klynger) per kommune når det totalt er for mange objekt innafor kartustnitt. Gjør om flater til punkt når du zoomer ut. Konsistente farger på vegobjekttyper. Dvs hvis du har grønne skiltplater og blå kummer så endres ikke fargen på kummer fra blå til grønn når du sletter det grønne kartlaget for skiltplater.
Kan bytte operasjon fra oppdater => korriger ved innsending (lagring) til NVDB. Innspill: Kan vi sette inn gyldig fra-dato? Ikke foreløbig, men det er en god idé som vi tar inn i neste sprint. Tilføyelse: Det blir kun mulig å velge dato for operasjon oppdater.
Det er for tiden stort fokus på å få til et datagrunnlag som kan gi bedre analyser og hjelp i planleggingsarbeid for å unngå skader ved ekstremvær. Blant annet jobbes det med etablering av et nasjonalt kunnskapsgrunnlag, bestående av data for terreng, dreneringslinjer, stikkrenner, kritiske punkt, klimadata og hydrologiske beregninger.
I Nasjonal vegdatabank (NVDB) har vi 560 000 stikkrenner registrert. Utfordringen er at man tidligere registrerte stikkrenner kun med en vegreferanse. Nå krever Datakatalogen egengeometri fra innløp til utløp (linje). Men dessverre har kun 43 % av stikkrennene egengeometri i dag.
Hvorfor vil vi skille på stikkrenner med og uten egengeometri?
For å oppnå best mulig resultat i analysesammenheng. Vi er avhengige av gode data på blant annet stikkrenner. Med gode data mener vi egengeometri og tilstrekkelig med egenskaper.
Stikkrenner uten egengeometri har kun stedfesting i forhold til vegnettet. Denne stedfestingen kan ha stor usikkerhet (+- 100 meter). Disse objektene kan derfor ikke brukes i en analyse for å finne dreneringslinjer.
Stikkrenner uten egengeometri har ofte lite eller ingen påkrevde egenskaper ihht Datakatalogen.
Stikkrenner uten egengeometri kan brukes for å estimere tidsbruk for kvalitetsheving av stikkrenner på europa- riks og fylkesveger (kommunale veger har i liten grad stikkrenner registrert på denne måten).
Kunne se på utviklingen i etablering av bedre kvalitet og fullstendighet på stikkrennedata i ulike områder.
Få en oversikt over hvor i landet en trenger å gå inn med ressurser for å få et bedre datagrunnlag.
Hvorfor økt fokus på etablering av egengeometri på alle stikkrenner, uansett vegeier?
Erfaring fra flom- og skredhendelser
Viktig med registrering av stikkrenner og flomveger for å kunne forebygge skader ved stor vannføring.
Tette stikkrenner er utløsende faktor eller bidragsyter til flomskred og skred, og at vannet tar nye løp og forårsaker skade.
Få til et datagrunnlag som kan gi bedre analyser og hjelp til blant annet kommunene i planleggingsarbeidet for å unngå skader ved ekstremvær.
Hvor tar vannet vegen og hvorfor tar vannet vegen? Kunne gjøre analyser for å vise hva som skjer hvis f.eks ei stikkrenne går tett.
I regi av Geovekst arbeidsgruppe Vann, NVDB-brukerforum Innlandet og erfaringer fra noen kommuner, er det laget en veileder som tar for seg hvordan stikkrenner skal måles og kodes. Samt hva en bør tenke på før en starter prosessen med registrering. Enkelte kartkontorer er også godt i gang med å etablere dreneringslinjer for fylket. Stikkrenner med egengeometri fra NVDB er brukt som datagrunnlag sammen med andre vanndata og høydedata. For å få et mer riktig analyseresultat trengs en bedre fullstendighet i datasettet.
For å si noe om kvaliteten på dreneringslinjer i et område, har Statens vegvesen laget en statistikk over stikkrenner med og uten egengeometri som et hjelpemiddel. Oversikten kan også brukes for å prioritere områder som trenger kvalitetsløft.
Kan laste ned zip-fil med de 5 mest relevante rapporttypene (V1,V2,V3,V4 og tilstand/skade).
Vegnettslengde – har ny rad med summen av gang/sykkelveg og kjøreveg.
Veglisteproduksjon: Komma som desimaltegn, bruke lang tankestrek, ikke kort bindestrek i strekningsbeskrivelse; fjerne mellomrom før og etter tankestrek. Dette er i hht klage fra Språkrådet
Datafangst:
Ikke så mye ny funksjonalitet å vise fram, fokus har vært på stabilitet (og dermed også ytelse). Datafangst har crashet pga minneforbruk. Årsaken har vært at Datafangst ikke har hatt noen form for begrensning ved «vis eksisterende objekter». Det var veldig enkelt å laste inn f.eks. skiltplater for hele Norge. Nå har vi satt begrensning slik at du kun laster inn «eksisterende objekt» for små områder, dvs at du må zoome inn.
Begrensning ved innlasting «eksisterende objekt», du må zoome ganske langt inn før systemet tillater deg å hente objekter. (Workaround de gangene dette blir plundrete: Importer data fra vegkart API-lenke).
Sammenkoblingsfanen – hadde samme problem ved søk etter NVDB-objekter, fikk crash pga minneproblemer. Har satt en begrensning, søkeradius er redusert til 1000 meter. (Workaround de gangene dette blir plundrete: Importer data fra vegkart API-lenke).
GML på vei mot produksjon
Last opp fil med eksisterende objekt: Datafangst har tidligere lest inn ett objekt av gangen. Nå leser vi 200 av gangen. Ved vår test prøvde vi innlesning av 1000 objekter og tiden for innlasting ble redusert fra flere minutter til en håndfull sekunder.
Maks størrelse SOSI fil: Har satt en begrensning på 3000 objekter.
Opplasting med sensitive egenskaper: Kunne ta veldig lang til hvis man ikke hadde rettighet til å lese sensitive egenskaper, fiksa.
Sjekker at relasjon er reell før vi endrer på relasjonen. (dvs sjekke at mor-objekt finnes og det finnes en eksisterende relasjon til datterobjekt før vi sletter eller endrer mor->datter relasjonen). Vi har hatt en del supportsaker der brukerne våre står fast med avviste endringssett fordi enten mor-objekt eller relasjonen mor->datter er historiske.
Tilbakemeldinger
Hva hvis vi skal koble mor-objekter som ligger langt unna, kan vi bruke vegkart søkelenke for å hente inn objekter som ligger lengre unna enn 1000 m? F.eks. tunnelløp->skiltplate relasjon kan være i stor avstand. Ja – og dette er en veldig god workaround for de tilfellene der våre nye begrensninger gir plunder.
Får ikke lese hendelsesloggen lenger? Forslag om å kun vise siste del av hendelsesloggen? Godt forslag, notert!
Legge inn vegreferanser? Pass på at det ikke blir multiple stedfestinger. Enig, notert!
Problemer med å opprette belysningsstrekning. Gjelder alle brukere, ser det ut til. Even G tror han vet hvor problemet ligger, og at han klarer løse det greit og raskt..
Norge i bilder (flybilder bakgrunnskart) – visning funker ikke for brukere utenfor SVV-nettet. Takk for feilmelding! Her kom Kartverket forleden med ny tjeneste som Vegkart allerede har tatt i bruk. Vi tar i bruk samme løsning som Vegkart bruker, så blir dette problemet løst. (Dette vil også gi bedre ytelse på flyfoto).
Vi pleier ikke poste oppsummering fra demo, men på grunn av situasjonen med dårlig stabilitet i Datafangst så kom det fram ting på demo vi mener bør nå fram til flere.
NVDB Rapporter:
Kan bestille zip-fil med V1,V2,V3,V4 og tilstand/skade. Sum veglengder: Ny rad med summen av kjøreveg og gang/sykkelsti.
Datafangst – ytelse og stabilitet
Ytelse og stabilitet henger sammen – hvis en type spørring går tregt så vil det bli en lang «kø» med disse trege spørringene, og i verste fall blir det så mange samtidige trege spørringer samtidig at alt sammen stopper opp.
Vi har tatt vekk «røde prikken» som viser hvilke kontrakter som er endret. Dette var en av de trege spørringene som ga oss utfordringer. Vi skal gjøre denne databasespørringen raskere og når den blir rask nok så kommer prikken tilbake.
Brukerønske ang den røde prikken: Vi har behov for denne typen «Vis at her er det skjedd endringer» på alle GUI-elementer, fra den overordnede listen med kontrakter helt ned til visning av enkeltobjekter.
Ekstremt tydelig og klar tilbakemelding på at vi må bli flinkere til å publisere driftsmeldinger fortløpende på twitter, og dernest bli flinkere til å skrive oppsummeringer om arbeidet med problemløsning (og øvrige planer) på vegdata.no.
Ny funksjonalitet i datafangst: «Opprett nytt strekningsobjekt»
Vist på forrige demo, men måtte gå en runde til fordi brukertesten avdekket mangler. I denne testprosessen fått gode innspill og idéer fra testerne våre, og ut fra det har vi laget flere løsningsforslag som vi mener tilsammen skal gi knallbra funksjonalitet. Men disse må prioriteres bak arbeidet med ytelse og stabilitet. Vi vil prøve å snurpe sammen en minimumsløsning som ikke vil være så brukervennlig som vi ønsker, men som fungerer godt nok til at den kan tas i bruk. Så får den knallgode implementasjonen komme senere, når vi har mer overskudd.
Balansering – arbeidet med ny versus gammel datafangst-løsning
Vi kommer ikke til å offisielt «fryse» videreutvikling av gammel datafangst-løsning selv om vi lager en ny. Verden endrer seg, og det kan dukke opp behov som er for viktige til at de kan vente på den nye løsningen. Vi nekter derfor å sette opp harde regler for hva vi gjør og ikke gjør av forbedringer i gammel løsning.
Aller høyest prioriterer vi at Datafangst virker! Ytelse og stabilitet henger sammen, og dette prioriterer vi høyt. Ref oversikten over arbeidet med å forbedre brukeropplevelse
Bortsett fra den nye funksjonen «Opprett nytt strekningsobjekt» vil det ikke bli tilført noe særlig nytt i eksisterende datafangst.
Vi vil også prøve å gjeninnføre del av de tingene vi måtte deaktivere på grunn av ytelsesproblemer, for eksempel «rød prikk» ved de kontraktene der det har skjedd endringer. Og det er ett og annet småtteri og bugs som ikke lenger fungerer like godt som før, det prøver vi å fikse. Og så er det slik at hvis vi med liten innsats kan gjøre en fiks eller forbedring som gir brukerne våre en bedre arbeidshverdag så prøver vi jo å klemme det inn. Men ikke forvent for mye.
Her er oppskrift på hvordan du kan ta ut historiske data for trafikkmengder i ulike verktøy. I prinsippet er enkelt – du føyer til parameteren tidspunkt=VALGT DATO i spørringen til NVDB api LES – i tillegg til andre søkeparametre (som f.eks kartutsnitt m.m). Alle spørreparametrene er beskrevet i dokumentasjonen for NVDB api LES.
For å få all tidsutvikling i samme spørring kan du i stedet for tidspunkt bruke parameteren alle_versjoner=true (for vegobjekter). Resultatet blir litt mer uhåndterlig spagetti med absolutt alle historiske og nåværende data fra NVDB, og krever gjerne litt sortering, filtrering og gruppering før man får struktur på dataene. For vegnett heter denne parameteren historisk=true.
Nedenfor viser vi eksempel på gamle og nye data for biter av gammel og ny E18-trasé ved Arendal. Den nye motorveien Arendal-Tvedestrand åpnet juli 2019, og trafikkmengden på gammel E18-trasé (nåværende Fv421) har gått ned med om lag 10.000 kjøretøy per døgn.
Ny E18 (rød pil) ble åpnet i juli 2019. Gammel E18 (blå pil) heter nå Fv421.Før åpningen av ny E18 var det registrert ÅDT på 13200 kjøretøy per døgn på gammel E18-trasé. i dag (15.11.2021), to år etter åpningen, har vi ÅDT på 3775 på Fv421, ned cirka 10.000 kjøretøy per døgn fra den gang E18 gikk her. På ny E18 har vi ÅDT = 10279 kjøretøy per døgn. Og her er fargeskalaen vi har brukt i disse plottene (som er laget med QGIS, forresten).
EDIT: Vegkart støtter nå historiske data
Våren 2022 satte vi i produksjon vegkart med støtte for historiske søk. De historiske søkene er fremdeles tregere enn standardsøkene, men det er etter vårt syn til å leve med.
Vi har laget ferdig en vegkart-versjon der du kan søke etter historiske data, men det gikk for tregt til at vi kunne produksjonssette den. Vi opplevde kanskje 20-30 sekunders ventetid før vegkartspørringen etter historiske data ga respons – og dette er helt uaktuelt å tilby brukere av en moderne webløsning i 2021. Historiske søk kommer nok til vegkart, men vi trenger mer tid før det blir bra nok.
Vegkart eksport – SOSI og CSV
Her er et tjuvtricks som bruker CSV- og SOSI eksport for å laste ned historiske data – det fungerer, selv om vegkart ikke innbyr til det. Gjør et vegkart-søk og kopier nedlastingslenken fra søket ditt (ekspander treffboksen og høyreklikk over det klikkbare feltet CSV eller Sosi for å få tilbud om å kopiere lenken). Denne lenken limer du inn i en teksteditor og føyer til valgt dato på formen &tidspunkt=2021-03-15 Merk at spørreparametrene skal være adskilt med ampersand (& – tegnet).
Denne modifiserte lenken kan du så lime inn i nettleserens adressefelt + ENTER. Nedlastingen skal nå starte automatisk.
Hvis du kopierer nedlastingslenkene inn i en teksteditor så kan du manipulere på dem, for eksempel ved å føye til parameteren &tidspunkt=2021-03-15
Firmaet Geodata A/S tilbyr en geoprosesseringstjenste hvor man asynkront kan laste ned data fra NVDB. Data blir pakket om til en esri-vennlig datastruktur på fil-geodatabase format, og når det er ferdig får du epost med lenke til nedlasting. Menyvalg for område, objekttyper, egenskapsverdier og andre typer filter blir bygget dynamisk i arcgis pro når du kobler deg til. De fleste (og viktigste) filtreringsmulighetene er støttet, men ikke alle. For eksempel tilbys menyvalget tidspunkt=DATO, men ikke historisk=true.
Qgis 3
Vi har laget et python-bibliotek hvor du bruker python konsoll for å laste ned data fra NVDB api LES direkte til kartflaten i QGIS 3, det finner du her. Følg oppskriften for nedlasting og kjør scriptet qgis3script-importernvdbdata.py med dine lokale tilpasninger, slik at biblioteket blir riktig importert til python konsollet. Deretter er du klar til å laste inn data med kommandoene
Naviger til og velg egendefinerte rapporter. Menyen for å velge objekttyper er todelt: I den venstre menyen søker du etter Trafikkmengde og huker av. Bruk pilene for å flytte markerte objekttyper over til høyre meny – som er de objekttypene som kommer med i rapporten.
Scroll lenger ned for å velge område. For dataene i vårt eksempel har vi brukt valgene kommune = Arendal og tidspunkt = 2019-04-01
Menyvalg for å avgrense rapporten på område (fylke, kommune eller kontraktsområde).
Den ferdige rapporten får litt begrenset bruksverdi når vi henter data som er eldre enn vegreferansesystemet som ble innført november 2019. I den ferdige tabellen er det derfor kun fyllt ut data for vegnummer, ikke strekning, delstrekning og meter – og dermed er det litt tungvint å vite hvilke rader som er hvor på vegnettet.
Den ferdige rapporten har hentet data eldre enn vegreferansesystemet (november 2019), og har derfor ikke data for strekning, delstrekning og meter. Det reduserer bruksverdien en hel del.
Python
Den mest elegante metoden er å bruke det fulle GIS-arsenalet blant annet geopandas, men ikke alle trenger dette – og installasjonen kan være litt fiklete. Derfor har vi skilt lesing fra NVDB (som funker rett ut av boksen i plain python) fra de avanserte GIS-bibliotekene (som kan være litt plundrete å installere rett). Starter du fra scratch med python så anbefaler vi Anaconda-distrubusjonen, og så fortsette med bruke conda-systemet for pakkehåndtering og bruke conda til å lage et separat python-miljø (detaljert oppskrift).
sys.path.append( 'Sti til der du har repos https://github.com/LtGlahn/nvdbapi-V3' )
import nvdbapiv3 # reposet https://github.com/LtGlahn/nvdbapi-V3
traf = nvdbapiv3.nvdbFagdata( 540 )
traf.filter( { 'kommune' : 4203, 'tidspunkt' : '2019-04-01' } )
myList = traf.to_records()
Nå har du data i minnet som en liste med json-dictionaries, og det kan jo knas videre i alle retninger.
En mulighet hvis du har pandas, geopandas og shapely-biblioteket installert kan du for eksempel lagre det som kartlag til harddisken din. Her går vi omveien om en såkalt dataframe til en geodataframe, som igjen har funksjoner for å lagre til et knippe geografiske formater – for eksempel det suverene filformatet geopackage
I 2020 og 2016 laget vi datadump med alle (datitdens) gyldige og historiske trafikkmengde-data. Ved siden av la vi også en dump av objekttypen 532 Vegreferanse, slik at man hadde mulighet til å se hvilke vegnummer som var gyldige til ulike tider på en bestemt strekning.
Info om datadumpen finner du her (vegdata-artikkel fra 2016, oppdatert med 2019-data. Når jeg sier 2019-data er det dette de ÅDT-verdiene som var tilgjengelig i 2019, dvs med År, gjelder for = 2018.
Sinus infra
I Sinus Infra kan du ta ut historiske data som var gyldige på en bestemt dato. Søk fram Trafikkmengde og trykk på områdefilter:
Søk fram Trafikkmengde og trykk på områdefilter
Velg Historisk og sett ønsket dato. Angi geografisk område (kommuner, fylker, kartutsnitt, eller som vist her – søkeradius i meter).
Velg Historisk og sett ønsket dato. Angi geografisk område (kommuner, fylker, kartutsnitt, eller som vist her – søkeradius i meter).
Det vi trenger er en oversikt for hva som er nytt per år. Altså hvis en veg får flere gatelys, fortau osv.
Dette er et behov som mange vegeiere og -driftspersonale har. Akkurat denne gangen kom spørsmålet fra Trondheim kommune, men det samme behovet har fylkeskommunene, entreprenører, Nye Veier A/S og Statens Vegvesen.
Vår anbefaling: Ta differansen mellom to datasett for ulike tidspunkt
NVDB api LES støtter datauttak på angitt tidspunkt (dato), med et par forbehold om at det ikke har vært gjort endringer på områdegrenser fra det første tidspunktet til i dag. Her er status på historisk søk i ulike verktøy per oktober-2019:
NVDB rapporter, alle rapporttyper støtter datauttak på angitt tidspunkt. I denne sammenheng er det driftskontrakt-rapportene som er mest relevant.
Vi har testet historiske søk i Vegkart. Det fungerte, men ytelsen var ikke bra nok. Vi jobber med saken!
Vi har noen forbehold! Hvis det har vært gjort justeringer på kontraktsområder og/eller vegnett kan du få litt … lite intuitive resultater, se under. I tillegg får du litt merarbeid om du ønsker å sammenligne data før og etter en kommunesammenslåing.
NVDB bruker kun de nyeste kommunegrensene!
I NVDB bruker vi kun ferske data for fylker og kommuner – med tilbakevirkende kraft. Så i 2021 finner du for eksempel ingen spor etter gamle Klæbu kommune.
Dette betyr at når du søker etter belysningspunkt i Trondheim for en tidligere dato, for eksempel 1. februar 2017, så får du treff pådagensTrondheim kommune. Mer presist 10625 objekter, hvorav 927 er i gamle Klæbu kommune.
Selv om Trondheim og Klæbu først slo seg sammen i 2020 så gir søket etter belysningspunkt per 2017 deg 927 treff i gamle Klæbu kommune,
Men hva med endret – funksjonen i NVDB api? Hvorfor ikke bruke den?
NVDB api LES tilbyr parameteren endret_etter, og den har sin anvendelse – men for akkurat dette behovet blir det for mange snublefeller. Resultatene fra denne spørringen:
må suppleres med en hel del datamassasje: Du må skille endret fra nye objekter, evt om det er nye versjoner av gamle objekt – og du må sjekke om noen objekter kan være slettet. Etter vårt syn er det bedre å ta differansen mellom to ulike datoer.
Historiske data per Kontraktsområde – brukes på egen risiko
Hvis du henter ut historiske data for et kontraktsområde og enten vegnettet eller kontraktsområdet (eller begge deler!) har vært endret så må vi ta forbehold om at du kan få færre vegobjekter enn det riktige.
Hvis du vet at vegnettet og ditt kontraktsområde har ligget i ro i tiden mellom i dag og bakover til det eldste tidspunkt du trenger data for – så kan du helt fint ta ut historiske data på dette kontraktsområdet.
Forklaringen er komplisert: Når kontraktsomrdet skal brukes som søkefilter i NVDB api les så klarer vi ikke gjenskape området slik det så ut før endringen, men bruker området slik det ser ut i dag – også for historiske søk.
Hvis en bit av vegnettet var i k.området i 2019, men ble satt historisk i 2020 – så vil du ikke klare finne den når du søker på k.området i dag med tidspunkt=2019.
Tilsvarende hvis k.området har vært justert i 2020: Du klarer ikke få frem riktige 2019-data ved å bruke k.området som søkefilter.
Det finnes krokveier om dette problemet, men det er komplekst (hent ut historisk 538-objekt per tidspunkt, finn dette objektet stedfesting og hent ut vegobjekter som hadde overlappende stedfesting på det tidspunktet.) Vi ønsker å tilby ferdige rapporter basert på denne logikken, men det ligger noe fram i tid.
Såkalte «Vegnettsrapporter» er blant de tingene våre flinkeste og ivrigste brukere er vant med å kunne ta ut via NVDB Studio eller NVDB 123, som jo termineres 1. august 2021.
Vi har laget en ny vegnettsrapport i systemet «NVDB rapporter«, i den modulen som er skreddersydd for drift og vedlikehold av vegene (såkalte «driftskontrakter»). Den er ikke identisk med de gamle vegnettsrapportene, men den er såpass lik at de fleste kjenner seg igjen.
Velg geografisk område: fylke eller kommune – minst én, men gjerne flere. Eventuelt kontraktsområde, hvis det er riktig for deg
Du kan også filtrere på vegkategori (eksempel: E) og vegnummer (eksempel: Ev39) i boksen vegfilter.
Søkeinnstillinger for vegnettsrapport
Når du har valgt rapporttype og geografisk område skifter «Hent data» – knappen farge fra grå til blå og lar seg trykke på.
Når du trykker på «Hent data» får du ei stoppeklokke som viser at systemet setter sammen en rapport til deg. Når rapporten er ferdig byttes stoppeklokka ut med teksten «Rapporten er klar til nedlasting» og en knapp for å laste ned rapporten.
I NVDB rapporter for driftskontrakter har vi et par måneder slitt med feil i lengdeberegning av vinterdriftsklasse og ÅDT. Våre utviklere er nå sikre på at de har løst problemene og at systemet nå regner riktig – men at noen av testene feiler.
Hva mener du, feil i testene våre?
Våre tester – fasiten, om du vil – er ingen ferdiglaget fasit, men en separat opptelling hvor vi ut fra V4-rapporten (detaljert mengdeoversikt) regner ut antall, lengde og areal som sammenlignes med tallverdiene i V2- og V3-rapportene (aggregert mengdeoversikt, sum per vegkategori eller per vegnummer) . Det er i denne opptellingen utviklerne nå påpeker en svakhet som gjør at testopptellingen vår blir for upresis for noen av verdiene.
For kontraktsområdet 9305 Sunnfjord er utviklerne for eksempel skråsikre på at opptellingen av ÅDT-verdier mellom 0 og 500 kjøretøy per døgn nå er riktig i produksjonssystemet – men for upresis i vår testopptelling.
Utdrag fra testrapport for 9305 Sunnfjord. Vi har 15% skyldes feil i testopptellingen vår, mens systemet nå gir riktige tall for ÅDT og vinterdriftsklasse i V2 og V3-rapportene.
Hva kan vi gjøre?
P.t. ser vi disse to alternativene:
Stole på utviklerne når de sier at de går god for de nye beregningene, men at «fasiten vår» ikke er perfekt, og at vi derfor kan begynne å bruke systemet
Avvente til vi har finregnet på ny fasit og forbedret testene våre
Å forbedre testene tar tid, trolig minst en uke eller to. Vi har derfor valgt å produksjonssette og gå ut med denne informasjonen. Dermed kan du selv best vurdere om avvikene som gjenstår er til å leve med – eller om du heller venter en stund til.
Kan jeg se testrapportene?
Selvsagt! De ligger her! En fil per kontraktsområde som er testet (p.t. 6 stykker), samt en felles testrapport som oppsummerer de verste resultatene fra alle kontraktsområdene.
Hva betyr fargeverdiene?
Grønt betyr identisk antall eller mindre enn 0.5 prosent avvik på lengde og areal.
Gult betyr inntil 1 stykk avvik på antall eller mellom 0.5 og 2 prosent avvik på lengde og areal
Rødt betyr mer enn 1 stykk feil på antall eller mer enn 2 prosent avvik på lengde og areal
