Vi har litt utfordringar i NVDB igjen. Feilen har pågått heile veka og mange har nok merka at Les ligg langt etter med etterbehandling. Dette er på grunn av at tenesten plutselig stoppar opp.
Vi har ute ein midlertidig fiks som omgår problemet i produksjon, men vi opplever likevel at alt går litt tregare enn normalt.
Det pågår no testing og feilretting i ATM-miljø (test-PROD). Les kan difor vere ustabil i dette miljøet framover til vi har løyst problemet.
Datafangst 2022-2.0.1 er ute i PROD
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.
6.12.2021 klokken 12:44 Vi FRISKMELDER NVDB api LES, i både PRODUKSJON og TESTPROD (ATM). Utviklingsmiljøet vårt har ikke hatt disse problemene
6.12.2021 klokken 12:30: Alt ser greit ut så langt, vi vurderer full friskmelding, men testing pågår ennå
6.12.2021 klokken 11:50: Vi har fått NVDB api LES igang igjen, har ikke rukket å teste alt grundig, men det ser OK ut så langt
Vi jobber med feilsøking, oppdaterer så snart vi har mer informasjon
Feilen påvirker alle systemer som bruker data fra NVDB api LES, deriblant Vegkart, NVDB rapporter, Datafangst med flere
Feilen er no retta og Lese-API fungerer igjen som normalt. Det er framleis litt etterslep i oppdatering av statusen «Etterbehandlet», men reknar med det og snart er i orden.
Det er ein feil med indeksering/etterbehandling av data i NVDB. Indeksering har no stoppa heil opp, og vi jobber med å rette feilen.
Dette fører til at ingen data som er levert til NVDB etter 00:00 16/11-2021 vert synlege i NVDB Les-API og tenestar som brukar denne som vegkart.
Regsitrerte data er lagra og vil verte indeksert når vi har systema oppe igjen, men synleg data vert meir og meir utdaterte etter kvart som det kjem nye oppdateringar og tida går.
Nasjonal vegdatabank (NVDB) inneholder landets vegnett og hundrevis av fagdatatyper knyttet til vegen.
Det meste av denne informasjonen har Statens vegvesen gjort fritt tilgjengelig, og vi oppmuntrer publikum til å bruke datagrunnlaget på kreativt vis.
På nettstedet Vegdata.no vil vi fortelle om hvordan du kan finne frem i jungelen rundt NVDB, og fortelle om status på de verktøyene og produktene NVDB-miljøet tilgjengeliggjør rundt NVDB.
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.
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:
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.
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å dagens Trondheim kommune. Mer presist 10625 objekter, hvorav 927 er i gamle Klæbu kommune.
Selve søket mot NVDB api ser slik ut:
https://nvdbapiles-v3.atlas.vegvesen.no/vegobjekter/87?kommune=5001&tidspunkt=2019-02-01&inkluder=alleNVDB 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:
https://nvdbapiles-v3.atlas.vegvesen.no/vegobjekter/87?kommune=5001&endret_etter=2021-09-22T00:00:00 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.
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.
Fra våre venner hos fylkeskommunen fikk vi denne utfordringen:
Det fylkeskommunen ønsker, er å finne ut om det er noen deler av fylkesvegnettet som ikke har knyttet et kontraktsområde til seg. Slik det er i dag, må man sammenligne to rapporter og finne forskjellen
Dette er et flott eksempel på noe som ikke er ferdig støttet i våre produksjons- og rapporteringsystemer, men som fint lar seg løse med ørlite grann koding, for eksempel i FME eller python.
Kontraktsområder er såpass viktige at vi i NVDB api segmenterer alle andre data med informasjon hentet fra objekttype 580 kontraktsområde. Dermed kan du bruke navnet på kontraktsområde som søkefilter i Vegkart og NVDB api. I vegkart-veiledningen har vi et eksempel på hvordan du kan vise vegnettet for et kontraktsområde i Vegkart.
Ta en litt grundigere titt på en bit av segmentert vegnett: https://nvdbapiles-v3.atlas.vegvesen.no/vegnett/veglenkesekvenser/segmentert/804767 . På JSON-format ser det noenlunde slik ut (forkortet for lesbarhet):
{
"href": "https://nvdbapiles-v3.atlas.vegvesen.no/vegnett/veglenkesekvenser/segmentert/804767",
8< --- forkortet for lesbarhet
"kontraktsområder": [
{
"id": 1013305686,
"nummer": 9304,
"navn": "9304 Bergen 2021-2026"
},
{
"id": 1010943925,
"nummer": 1202,
"navn": "1202 Stor-Bergen 2020-2021"
}
]
8< ---- forkortet for lesbarhet
}For hvert eneste vegsegment har vi altså en liste med de kontraktsområdene som gjelder for dette vegsegmentet. Hvis det ikke er registrert noe kontraktsområde for et segment så er denne listen enten tom (for JSON-formatet) eller mangler (XML-formatet). For eksempel https://nvdbapiles-v3.atlas.vegvesen.no/vegnett/veglenkesekvenser/segmentert/2720672
{
"href": "https://nvdbapiles-v3.atlas.vegvesen.no/vegnett/veglenkesekvenser/segmentert/2720672",
8< --- forkortet for lesbarhet
"kontraktsområder": [],
8< --- forkortet for lesbarhet
}Løsningen for å finne veger uten kontraktsområde blir da å lage litt kode som henter data fra NVDB api:
Klart det – her er et enkelt python kodeeksempel
Et mer komplett python-kodeeksemplet gjør bruk av Pandas Dataframes og Geopandas Geodataframes, samt mitt eget python-bibliotek for å lese data fra NVDB api. Installasjon av disse komponentene kan gi høy brukerterskel for uøvde brukere.
Vi kan helt sikkert lage et FME-kodeeksempel hvis det er interessant.
Utviklingsplanar med liste over alle saker vi har registrert for utvikling er no lagt ut under dei ulike produkta Statens vegvesen leverer i NVDB-portefølgen. Ei ovrsikt over alle planane Utviklingsplaner NVDB produktportefølje.
«Kjente feil»-posten er samstundes fjerne då feil er registrert som saker og plassert inn i utviklingsplanane våre. Eventuelle nye kritiske feil vil vi poste som eigne innlegg eller på Twitter dersom vi ser behov.
241-Vegdekke er en objekttype mange har utfordringer med å registrere i NVDB i nye løsninger. Datakatalogen og regelsettet generelt er uendret i forhold til NVDB-123, men mange hadde nok utarbeidet en rutine for å få gjennomført oppgaven i klassisk løsning.
Det er funksjonalitet for å gjøre det samme i nye løsninger, men det krever ofte en del manuelle rutiner.
Her er noen retningslinjer og tips for å få utføre arbeidsoppgaver med registrering av 241-Vegdekke.
Binde- og Slitelag må registreres i to omganger med ulik dato i NVDB.
Årsaken til dette er at det er to objekter av samme type og de kan ikke ha overlapp. Bindelag må derfor settes historisk for at slitelaget kan registreres. NVDB krever at et objekt er gyldig minimum 1 dag. Et objekt med lik start og slutt-dato vil i NVDB-verden tolkes som ikke å ha eksistert.
Fortrinnsvis bør da data leveres i separate leveranser fra entreprenør og behandles/leveres til NVDB separat i registreringsverktøy. Det kan for eksempel gjøres ved å levere data for Bindelag til NVDB før Slitelag leveres til dataløsningen, eler at det leveres til ulike «prosjekter/kontrakter» dersom løsningen ikke har støtte for utvalg ved innsending.
Ved registrering av flere dekkelag deles datasettet opp i flere delsett og punkt 5-9 repeteres til alle lag er registrert.
241-Vegdekke kan tillater i følge Datakatalogen ikke overlapp. Dersom dekke måles inn i flere objekter på samme strekning, f.eks. et objekt pr. retning/felt, sykkelfelt, avkjøringsfelt osv. må disse skilles ved å sette feltkode på objektene. Det er tillatt med et objekt pr. felt pr. punkt i vegnettet.
Gangveg, gang-/sykkelveg og sykkelveg er egne vegsystemer som kan ha vegdekke. Vegdekke på disse vegene skal ikke stedfestes på hovedvegen men på sine respektive vegstrekninger.
Fortau er ikke definert som felt i dagens vegnett. Dekke på fortau anbefales ikke å registreres som egne vegdekkeobjekter. Dette ivaretas i dag som egenskap på objektet 48-Fortau.
Dekker på områder som ikke er en del av vegen skal ikke registreres som vegdekke i NVDB selv om det er vegeier som forvalter dekket. Dette kan være gangstier på/rundt kollektivpunkter, turistattraksjoner, holdeplasser osv.
Tidligere har vi publisert oppskrifter på hvordan du kan bruke vegkart til å finne lengder av veg til KOSTRA-rapportering. Disse oppskriftene er fremdeles gyldige, men nå er det kommet flere muligheter.
Fra systemet «NVDB rapporter» for driftskontrakter , under fanen for «Egendefinerte rapporter kan du ta ut «vegnettsrapport» for en kommune. Denne løsningen finner du her: https://nvdb-vegnett-og-objektdata.atlas.vegvesen.no/generisk/
Velg «Vegnettsrapport (V1)» og angi kommune og eventuell dato før knappen «Hent data» blir aktiv.Valgene for Kontraktsområde og Fylke lar du stå tomme.
Last ned ved å klikke den blå knappen «Hent data». Hvis knappen er grå (dvs inaktiv) betyr det at du må se over valgene en gang til. Knappen byttes ut med beskjeden «kjører» og hvor lang tid det har gått til nå. Etter et par minutters venting er rapporten klar, og telleverket byttes ut med dialog for nedlasting:
Last ned rapporten ved å klikke på den blå knappen.
Vegnettsrapporten (excel) må filtreres før den gir riktige verdier. Den har fanene «Samlet, alt vegnett» som inneholder alle vegkategorier, for både gående og syklende. I tillegg har vi egne faner for kjørende og gående for hhv «riksveg» (vegkategori E og R), fylkesveg og «andre» (vegkategoriene K, P og S). Stort sett må du alltid filtrere regnearket for å få fornuftige tall.
Her er oppskriften på «Kostra»-rapportering med utgangspunkt i fanen «Samlet, alt vegnett»
Etter filtrering summeres lengden med kolonne V «Lengde veg (m)»
