Miljø for ATM (test) og STM (systemtest) i NVDB er oppe igjen

Det var som kjent driftsproblem i IT-systemene til Statens vegvesen før påske. Dette førte til at mange system gjekk ned både internt og eksternt for SVV.

Fokuset var først på å få opp alle system med publikumsløysing i produksjon. Interne system og testmiljø vart prioritert seinare.

No skal ATM (test) og STM (systemtest/utv) for NVDB vere oppe igjen og utviklarar kan igjen starte testing aveigne løysingar mot desse miljøa.

Feilen er retta i IND/NVDB-Les.

Vi har klart å løyse feilen vi har slit med i NVDB denne veka. Det vert då ikkje behov for å bygge opp data på nytt i helga. Det vert starta normal reindeksering som vanleg i helga, og API-et og alle klientar som nytta det vil fungere som normalt.

Vi vil no fortsette å sjå på forbetringar i API-et for å gjere data raskare tilgjengeleg etter registrering.

Ustabilitet i NVDB

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.

Testing av feilretting i ATM

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.

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.

NVDB api LES fungerer ikke

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

– OPPDATERT – Feil med oppdatering av data i NVDB

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.

Om vegdata.no

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.

Søk etter historiske data

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:

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å dagens Trondheim kommune. Mer presist 10625 objekter, hvorav 927 er i gamle Klæbu kommune.

Skjermdump av kart som viser hvordan et søk etter belysningspunkt i Trondheim kommune per 2017 gir 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,

Selve søket mot NVDB api ser slik ut:

https://nvdbapiles-v3.atlas.vegvesen.no/vegobjekter/87?kommune=5001&tidspunkt=2019-02-01&inkluder=alle

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:

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.

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.