Kvalitet på stikkrenner i NVDB

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.

Et annet prosjekt som er i startfasen, er Geosats 2023, initiert av Nasjonalt geodataråd, med et underprosjekt Forebygge konsekvenser av ekstremvær. Her vil etableringen av stedfesta terrengdata, kritiske punkt, dreneringslinjer og annen kritisk infrastruktur ha en sentral rolle.

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.

Denne, samt andre rapporter og statistikk legger vi ut her: https://www.vegdata.no/rapporter-og-statistikk/

Kontaktperson i Statens vegvesen: Kari Anne Midtvold (kari.midtvold@vegvesen.no)

Les-API i ATM/test-miljø blir utilgjengeleg.

Vi er nødt til å ta ned API-Les i ATM/test-miljø for å teste ei endring vi planlegg i PROD til helga. ATM Les vil då vere nede frå eit tidspunkt no i ettermiddag (3/3 2022) til i morgon formiddag ein gong.

Målet med endringa er å kraftig redusere tidsbruken i IND som vil gjere at ventetida frå registrering i Skriv til data er tilgjengelg i Les vert betydeleg kortare enn i dag. Potensiell gevinst her er så stor og etterspurd at vi prioriterer å teste dette i ATM no så vi kan innføre det i PROD alt denne helga.

Demo datafangst 2. februar 2022

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.

Hvorfor bygger vi splitter ny Datafangst?

Kortversjon: På fem år har Datafangst vokst fra en enkel prototype til en kompleks applikasjon. I dag håndterer DF større datavolum enn den ble bygget for, og vi har en veldig uheldig blanding av gammel kode skrevet i ett rammeverk (Angular, som ikke blir videreutviklet) og ny kode skrevet i et annet rammeverk (React). Brukerne våre opplever treghet, og utviklernes jobb er unødig plundrete.

Den aller første versjonen kommer våren eller sommeren 2022. Denne versjonen vil kun ha det minimumet av funksjoner som trengs for å levere data til NVDB, men da kun for et snevert utvalg av data, med et minimum av de aller mest nødvendige funksjonene. Nye releaser vil komme i form av hyppige, men små forbedringer. Slik vil vi gradvis føye til mer avansert funksjonalitet. Gradvis vil den nye løsningen kunne overta stadig flere arbeidsoppgaver fra den gamle løsningen.

Presentasjon og stikkord fra møte 25.1.2022 om ny datafangst:

Ny datafangst-versjon satt i produksjon

Datafangst 2022-2.0.1 er ute i PROD

  • Mulighet til å vise kommentarer for flere objekter og objekttyper gjennom verktøymenyen i datafanen.
  • Mulighet til å fjerne flere kommentarer gjennom filtrering og markering.
  • Nye, mer beskrivende farger på kommentarboblene.
  • Vegsystemreferansen kan nå sees i datafanen for objekter som er registrert i NVDB eller er stedfestet.
  • Metreringsretning er nå standard retning i datafangst.
  • Man kan nå se retningen på veglenker i kartet, både i datafanen og stedfestingsfanen.
  • Sideposisjon og felt kan nå sees og redigeres selv om det er flere av disse for et vegobjekt.
  • Sideposisjon og felt vises i forhold til metreringsretning i motsetning til før da de vistes i forhold til geometriretning.
  • Sideposisjon og felt er nå markert gult om det er endret ifht NVDB.
  • Ved stedfesting kan du nå sende med vegkategori for å spesifisere stedfestingen mer nøyaktig.
  • Den gamle stedfestingstypen ble visualisert bedre når det kom til krappe svinger som nærmet seg sirkler. Dette er nå fikset.
  • Ved import av SOSI kan man nå velge operasjon, som betyr at man kan importere eksisterende NVDB-objekter som SOSI.
  • Endring av enkeltattributter i datafanen har blitt raskere.
  • Når det dukker opp en feilmelding får du oppgitt en lenke til ofte stilte spørsmål for mer informasjon.
  • Andre mindre feilrettinger og forbedringer.

Obs! Vi har et script som kjører og fyller inn metreringsretning på alle veger det er stedfestet på. Dette tar ca. et døgn å kjøre. Det betyr at vi har ikke metreringsretning på alle veger enda.

Om man har et objekt som er stedfestet på veg uten metreringsretning vil sideposisjon og felt være grået ut i vegobjekter-fanen og hvis man hovrer på dette feltet vil det stå «Objektet er stedfestet på veg uten metreringsretning og sideposisjon/felt kan ikke oppgis.». Hvis objektet har sideposisjon eller felt vil det dukke opp så snart metreringsretningen har blitt hentet inn. Hvis man vil se sideposisjon og felt med en gang kan man stedfeste på nytt og vi vil da hente inn metreringsretningen på veglenka. Alle veglenker forventes å ha fått metreringsretning innen fredag morgen. I løpet av helga. EDIT: Dette scriptet gir såpass stor belastning at vi må kjøre det i helga, når det er færre brukere.

Gamle ÅDT-tall er satt historisk

Vi har nettopp sendt alle trafikkmengde-objekter med ÅDT, gjelder for lik 2019 eller eldre over i historien, dvs objektene er lukket og har fått en sluttdato. De vises ikke lenger i Vegkart, men de kan hentes fram fra NVDB api LES med oppskriftene beskrevet her: Hvordan får jeg historiske data for trafikkmengder?

Grunnen er at disse gamle ÅDT-verdiene skapte en del kluss, heft og problemer for analyser og bruk av trafikkmengde-data. Vi hadde også stor pågang på support med å forklare hvordan det hang sammen at vi hadde opp mot ti år gamle data liggende ved siden av 2020-data.

Snublefeller, historiske data

Bruk av historiske data har en del interessante snublefeller og begrensninger

Sjekk også vår artikkel om hvordan du tar ut historiske data i ulike verktøy.

Vegsystemreferanse fantes ikke før november 2019

I november 2019 innførte vi det nye referansesystemet, populært kalt vegsystemreferanse. Sjekk artikkelen Hva må jeg vite om vegsystemreferanse? Denne er ikke gitt tilbakevirkende kraft, det vil si at hvis du tar ut de dataene som var gyldige i 2018 så får du ikke med detaljer om strekning, delstrekning, kryssdeler, trafikantgruppe og metrering. Spesielt interesserte kan skjøte på med info hentet fra historiske 532 Vegreferanse – objekter.

Men vi la på detaljer om vegnummer, fase og vegstatus på alle historiske objekter i NVDB api LES, så du kan søke på f.eks. Fv915 når du skal ta ut historiske data. Merk at data eldre enn 2019 har fått 2019-vegnummeret.

I NVDB bruker vi kun de nyeste kommunegrensene!

Endrer vi på kommune- og fylkesgrenser så får det tilbakevirkende kraft i NVDB. Du kan ikke lenger søke etter belysningspunkt i Klæbu, for Klæbu er en del av nye Trondheim kommune. Og motsatt – søker du etter historiske data for belysningspunkt så er det dagens kommunegrense som brukes som søkefilter. Kartskissen under viser 2017-grensene for Trondheim samt de belysningspunktene du får når du søker på belysningspunkt med filteret tidspunkt=2017-02-01&kommune=5001

Kart med gamle kommunegrense for Trondheim og belysningspunkt i nye Trondheim 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,
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,

I NVDB bruker vi kun de nyeste kontraktsområdene – og liker best det nyeste vegnettet

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.

Trenger du hjelp?

Les først dokumentasjon du finner under menypunktene eller ved å søke her på vegdata.no og vegvesen.no.

Finner du ikke svar, ta kontakt med NVDB igjennom kontaktskjemaet.

Melde feil i NVDB?

Informasjon i Nasjonal vegdatabank (NVDB) er registrert på en systematisk måte, og holder jevnt over høy kvalitet. Men trenger du like vel å melde feil i NVDB? Her finner du en oversikt over hvordan du melder fra.