Vi har veld å utsetje demo for Team Oransj til 12:00 tysdag 26/4. Dette på grunn av konflikt med planlegging av ny datafangst der mange av interessentane skal vere med.
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.
Løyst: Eksport fungerer ikkje heilt.
Mange får no feilmelding ved eksport frå Vegkart:
Vi undersøker…
Demo datafangst 23.3.2022
Denne sprinten har vi hatt redusert kapasitet pga intern opplæring og en del andre forhold.
Datafangst:
- Norge i bilder fungerer utenfor SVVs nettverk. Dessverre utløste det en ny bug: Kartutsnittet flyttes på forvirrende måte når du bytter bakgrunnskart, selv om du har skrudd av automatisk zoom.
- Vi flytta den nye «velg alle» – knappen slik at låseknappen fikk tilbake sin opprinnelige plassering.
- Vi har gått tilbake på valget om å vise alle objekter for alle valgte objekttyper. Nå ser man kun objektene for den første objekttypen man velger, slik som før.
- Innlasting av vegsystemreferanser går mye raskere
- Datafangst støtter import av vegobjekter fra NVDB som mangler stedfesting
- Rettet en feil som gjorde at man ikke kunne navigere til innstillinger for kontraktgrupper
- Rettet en feil som gjorde at man ikke kunne velge alle vegobjekter
Også i denne sprinten har det vært krevende å balansere forbedringer i eksisterende Datafangst-løsning mot supportoppgaver samtidig som vi sikrer grei fremdrift på ny Datafangst.
Rapportgenerator:
Vi har brukt mye tid på feilsøking som viste seg å ikke være reelle feil. På veglister var det en type datafeil som må rettes i NVDB. På driftskontrakter var det uklarhet rundt fremtidig dato med vinterdriftsklasser. Dette tok det tid å få ryddet opp i, men gir oss også trygghet for at joda, V2 og V3 – rapportene regner riktige lengder for vinterdriftsklasser. Men saken vitner også om at vi må bli bedre på å kommunisere fallgrubene som finnes hvis du skal lage din egen lengde-summering ut fra V4-rapportene.
Tiltak foreslått på demo:
- Bedre dokumentasjon (artikkel som forklarer innholdet i rapportene, og hvordan de brukes + fallgruver)
- Rapportene har ny linje med lenke til dokumentasjonen.
En ny underside til dette formålet er opprettet på adressen https://www.vegdata.no/produkter-og-tjenester/nvdb-rapporter/driftskontrakt-rapporter/brukerveiledning-driftskontrakt-rapporter/ . Dette er p.t en tom side som vi fyller med innhold
Feil! IND stoppa opp ei lengre periode 16. mars.
Klokka 12:07 16. mars fekk NVDB-IND problem med ei endring i vegnettet. Dette førte til auka serverbruk som førte til fullstendig frys i Les rundt 13:00.
Les fekk vi raskt tilbake med enkle justeringar i servelast, men IND stod fast på vegnettsendringa heilt fram til rundt 15:30 der vi klarte å «hoppe over» den aktuelle endringa og gå vidare med køa.
NVDB funger no som normalt igjen, med eit lite unntak. på fv. 410, fv. 420 og tilstøytande vegar i Arendal er det avvik mellom vegnettet som er registrert i Skriv (og databasen) og det som er vist ut til verda gjennom Les. Dette vil føre til problem dersom nokon forsøker å gjere endringar i dette området. Det ligg difor ein lås på det berørte området og endringar som er innanfor låsen vert ståande på vent til vi har løyst det lokale problemet.
Når låsen er fjerna vert dei lagt inn i køa som nye endringar og vi reknar med dei fleste går gjennom, men enkelte kan verte avviste på grunn av at objektet er oppdatert av andre enringssett i området.
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)
— NEDETID I NVDB LES — Planlagt oppdatering av NVDB i helga (11-13. mars 2022)
Oppdatering 14. mars:
NVDB Les-API er tilbake i normal drift og oppdateringa ser så langt ut til å vere ein suksess. Vi har fått inn normalt med endringssett så langt i dag, og har ikkje registrert kø enda.
Oppdatering 11. mars:
Test i våre testmiljø er veldig positive. Vi har utført testing med registrering av fleire endringar i NVDB enn vi normalt har i produksjonsmiljø samstundes som vi simulerte ekstrem last på API-et med mange store spørjingar i Les.
Resultatet var at vi berre opplevde midlertidig kø på få minutt i samband med endringar i vegnettet. Men køa tok seg inn igjen etter få minutt. Vi opplevde og at Les er litt tregare (brukar litt lengre tid på å svare) når lasta er størst. Dette var og forventa, men vi reknar gevinsten med å få tilgang på oppdaterte data raskare som større enn ulempene med at svartida vert litt større.
Planlagt oppdatering
Vi driv testing av ei endring i NVDB som skal redusere tida som går med til indeksering av data – eller tida det tek frå NVDB mottek ei endring til den er tilgjengeleg i Les.
Vi har gode erfaringar med testing så langt og ser ut til å kunne redusere tidsbruken med opp mot 90%. Det vil sei at vi kan gå frå dagens situasjon der vi midt på dagen får inn meir enn dobbelt så mange endringar kvart minutt enn vi kan handsame, og dermed kontinuerleg bygger opp kø, til å kunne handsame opp til dobbelt så mange endringar som vi får inn no.
Konsekvens under oppdatering
Men innføring av endringa vil føre til komplett nedetid for Les-API og dermed alle system som er avhengige av dette (Vegkart, Datafangst og eksterne klientar som viser eller nyttar data i NVDB).
Reserveløysing
API v2 og Vegkart-2019 vil vere tilgjengeleg, men det er her ikkje informasjon om vegsystem eller nye fylkes- og kommunestrukturar. Det kan brukast for å finne fagdata om vegobjekt, men vil då innehalde gamle referanse til vegnett, fylker og kommunar.
Nasjonal vegdatabank API.v2 (NVDB API.v2)
Vegkart-2019 (vegvesen.no)
Vurdering nytte/ulempe – tilbakemelding
Vi ser gevinsen med å innføre denne endringa som så stor at dersom vi ikkje finn store problem under testing fra til fredag vil vi innføre det alt no i helga (startar arbeidet fredag 11. mars 2022 kl 16:00).
Dette er kort varsel, men vi har arbeida lenge med å finne ei løysing på dette problemet som stadig vert sørre og som vi får veldig mange tilbakemeldingar på at skaper problem for våre brukarar.
Dersom dette fører til store operasjonelle problem for nokon ber vi om tilbakemelding på dette til NVDB@vegvesen.no.
Feil i vegkart
Vi opplever for tida feil i Vegkart.
Ofte skjer det ved vising av Vegnett i kartet:
Vi feilsøker og vil rette feilen så raskt vi kan.
Feilretting Datafangst kurve-alias
Vi rettet nettopp to feil knyttet til vegobjekt-alias i Datafangst. Feilen rammet noen av brukerne våre hardt, mens andre ikke opplevde problemer. Vi beklager ulempene!
Et alias er et midlertidig navn vi bruker for å skille objekter fra hverandre i tabell, for eksempel «Kurve 1» eller «skiltpunkt:85397901». I størst mulig grad prøver vi å gjenbruke SOSI-numerereringen, slik at når det står «Kurve 1» i SOSI så bruker vi også «Kurve 1» i Datafangst. For Geojson prøver vi også så langt det går prøver å tolke tagger for å finne passende kurvenummer. Hvis vi ikke klarer finne noe passende informasjon så genererer vi et tall.
Feil nummer 1 var at innlesning til Datafangst feilet hvis det sto andre ting, for eksempel datoer, i den taggen der vi forventet å finne et heltall. Da fikk du feilmeldingen «kan ikke lese vegobjekter for visning» når du trykker på en vegobjekt-type.
Feil nummer to var knyttet til kopiering, der et objekt med en alias («Kurve 1») blir til to objekter med samme alias. Når du prøver å endre disse to så ga det kun effekt på den ene av dem, noe som var både forvirrende og frustrerende.
Begge disse feilene ble retta og rullet ut i produksjon i løpet av torsdag og fredag, ref driftsmeldingene på twitterkontoen vår NVDB åpne vegdata (@NVDBapi) / Twitter
Vi prøver ut import av GML i Datafangst
Som vist på BA-nettverkstreff 20. januar så har vi nå lansert en prototype for import av GML til datafangst. Dette gjør du manuelt via menyen for filopplasting, som nå støtter filtypene .SOS og .GML. Direktelenke til presentasjonen BA-nettverkstreff 20.1.
Vi understreker at dette er en prototype som gjør det lettere å prøve ut de ulike GML-variantene som finnes i markedet og avdekke styrker og svakheter.
GML-en min virker ikke, kan dere fikse?
Vi vil svært gjerne kartlegge hvilke problemer som evt dukker opp, så den GML-filen som feiler kan du sende til Datafangst-support krøllalfa vegvesen punkt no. Sammen med Vegvesenets standardiseringseksperter vil vi sjekke om problemet er i GML-filen, i datafangst import – og eventuelt om applikasjonsskjemaet bør videreutvikles for å støtte det du prøver å få til. Dine feilmeldinger inngår i kunnskapsgrunnlaget når vi videreutvikler støtte for GML.
Det vi IKKE kommer til å gjøre – er å fikse feilen raskt. Akkurat nå, vinteren og våren 2022, må vi prioritere ny datafangst-løsning samtidig som vi sikrer stabil drift av nåværende løsning.
Datafangst ønsker til fremtidig GML-funksjonalitet
Sett fra Datafangst sin side så ønsker vi at det blir mulig å beskrive følgende i fremtidige GML-dokument
- Flere objekttyper i samme GML-dokument (dette tror vi er fullt mulig i dag, men vi må få erfaring med «beste praksis» og eventuelle snublefeller)
- Angi hvilke NVDB skriveoperasjoner som ønskes for de eksisterende NVDB-objektene (registrer, oppdater, korriger m.m.)
- Angi relasjoner mellom objekter: Internt i GML-dokumentet, mellom objekter i GML og eksisterende NVDB-objekter og mellom eksisterende NVDB-objekter.
Denne funksjonaliteten kan ikke løses av Datafangst alene, men krever et samarbeid om hvordan vi videreutvikler GML «Beste praksis» i markedet. Men vi på Datafangst er veldig gjerne med på å prøve ut disse mulighetene.