Gå til hovedinnhold

2 innlegg merket med "Datafangst"

Vis alle tagger
Nullstill alle tagger
· 4 min lesetid

Siden 2016 har Datafangst vært samarbeidsverktøyet der eksperter på dataforvaltning kvalitetssikrer og beriker data fra dem som bygger og drifter vegene våre. Dessverre er Datafangst teknologisk utdatert og må byttes ut.

Erstatteren Nye datafangst (DF20) går nå inn en pilotfase.

Om Datafangst

Datafangst er en felles arbeidsflate der de som bygger veg samarbeider med vegeiers eksperter for å sikre gode dataleveranser til Nasjonal Vegdatabank (NVDB) og Felles Kartbase (FKB). Systemet ble lansert som en prototype i 2016, og har vokst derifra – men er blitt kvalt av sin egen suksess: Datafangst sin arkitektur er ikke egnet for dagens datavolum. Selv om systemet har mye god funksjonalitet så er det også viktige arbeidsflyter som burde vært revidert.

Målet med Datafangst 2.0 er at det skal bli bedre enn 1.0 samtidig som vi viderefører det gamle datafangst er god på – og med en arkitektur som er godt egnet for morgendagens datavolum.

I Datafangst så leverer entreprenøren data til NVDB og FKB i henhold til avtalte krav og objektliste. FKB-data blir kontrollert før de sendes videre til Statens Kartverk, mens NVDB-data må gjennom en komplisert prosess før de er klare til å lagres til NVDB: Data blir beriket med flere egenskaper, koblet sammen med relasjoner og koblet sammen med NVDB vegnett.

Status november 2024

Datafangst 2.0 er på vei over i en pilotfase. Her vil utvalgte fagbrukere bistå med testing av systemet med reell produksjonsdata.

Om arbeidet som gjenstår – visuell roadmap

Videre plan for Datafangst kan deles inn i tre faser.

Fase en: Pilotfasen.

Her vil et utvalg brukere slippes inn i systemet for å kunne utføre sitt daglige arbeid der.

I denne perioden vil det parallelt foregå videreutvikling av resterende funksjonalitet, samt feilretting av saker meldt inn av pilotbrukerne.

Etter som piloten skrider fremover kan det være at flere brukere blir invitert inn for å teste løsningen. Hvis dette er av interesse for deg kan du sende en henvendelse til datafangst-support@vegvesen.no. For å delta er det en forutsetning at du har god kjennskap til Datafangst fra tidligere av.

For å kunne gå videre til neste fase er det enkelte kriterier som må være oppfylt.

  • Utviklingsteamet har ferdigstilt alle saker som er definert fra teamet som nødvendig for at det skal være hensiktsmessig for brukere benytte Datafangst 2.0 fremfor Datafangst 1.0
  • Ytelsen møter forventningskrav

Fase to: Datafangst 2.0 åpnes opp for alle brukere.

I denne perioden vil systemet åpnes opp for alle brukere.

Det vil fortsatt foregå utvikling av funksjonalitet og forbedringer av eksisterende funksjonalitet. Fortsettelse av arbeidet med ytelsesoptimalisering vil også være svært viktig. For de aller fleste vil Datafangst 2.0 på dette tidspunktet være det beste verktøyet å benytte for å utføre sine arbeidsoppgaver. I noen utvalgte tilfeller kan det være hensiktsmessig å benytte Datafangst 1.0. Dette vil vi i så fall informere om.

For å kunne gå videre til neste fase er det enkelte kriterier som må være oppfylt:

  • Funksjonaliteten på Datafangst 2.0 er ferdig utviklet og systemet har gått over i en driftsfase.
  • Vi opplever får henvendelser knyttet til tekniske problemer.
  • Brukere får utført sine arbeidsoppgaver.

Fase 3: Datafangst 2.0 er ferdig utviklet. Datafangst 1.0 blir skrudd av.

Datafangst 2.0 er ferdig utviklet. Systemet har nå gått over til en forvaltningsfase og brukerne opplever få tekniske problemer. Ytelsen blir også ansett som stabil og effektiv. Datafangst 1.0 blir nå gjort utilgjengelig og brukerne skal kun benytte Datafangst 2.0. Systemet endrer navn til kun å hete Datafangst.

Roadmap

Merk: Dette er en foreløpig plan. Endringer kan forekomme.
Følg med på nyheter og produktsiden for løpende oppdateringer!

· 6 min lesetid

Vi beklager alle problemene og plunder og heft som våre brukere av Datafangst 1.0 har stått i den senere tid.
Statens vegvesen har brukt store ressurser på å bedre ytelsen, feilsøking og feilretting. Dessverre har vi ikke vært flinke nok til å kommunisere med brukerne våre om hvilke problemer de bør vite om, og hvilke tiltak vi jobber med.

Ytelsen i Datafangst 1.0 ble vesentlig bedre 14. november

Gladnyheten er at vi omsider har funnet en teknologisk løsning som gir akseptabel ytelse. Fra og med torsdag 14. november innførte vi avansert teknologi for indeksering og caching oppå databaselaget. Omsider klarte vi finne en løsning der Datafangst 1.0 får tilbake den ytelsen vi hadde for noen år tilbake.

I 2024 har vi brukt store ressurser på ytelsesproblemer, samt feilsøking på ulike problemer. Noen av disse problemene var på grunn av treghet i systemet. Andre problem skyldtes endringer utenfor Datafangst: Flere av tjenestene Datafangst er avhengig av, for eksempel vegkart eksport eller SKRIV sine valideringfunksjoner, har endret seg de siste månedene. Dette har gjort arbeidet med ytelsesforbedring vesentlig mer komplisert.

Ytelse, belastning og svartid fra databasen har vært hovedbekymringen siste året - her er vi bokstavelig kvalt av vår egen suksess, med et systemarkitektur og databasestruktur som ikke er egnet for de datavolumene og antall samtidige brukere som er i systemet. Men vi har også funnet og fjernet andre flaskehalser.

Caching i nettleser er skrudd av

Ett tiltak for å redusere belastning på databasen var å skru på såkalt "caching" i brukerens nettleser. Det vil si at når du åpner en fane som du så på for mindre enn 5 minutter siden så hentes ikke data fra serveren (og databasen): Data er allerede lagret i minnet til nettleser, og er derfor tilgjengelig uten forsinkelse. Ulempen er hvis data endrer seg så risikerer du å måtte gjøre en "refresh" (oppfrisking) av nettleser før endringene blir synlige for deg. For eksempel hvis du er innom vegobjekttabellen, og så laster du opp en fil og så går tilbake til vegobjekttabellen: Da blir ikke data fra den nye filen synlig før du gjør en tvungen oppfriskning (refresh) av nettleser. Vi har fått flere klager på support på dette temaet.

På grunn av disse ulempene - og fordi ytelsesforbedringene 14.11 var så gode - så har vi nå valgt å SKRU AV funksjonen med mellomlagring ("caching") i nettleser.

Kopier egenskap til mange er strengere - men raskere

I vegobjekttabellen gjorde om på valideringen ved kopier til mange (evt til alle). Før så ble hvert eneste objekt validert for den nye egenskapverdien ved kopiering. Denne valideringen skjer ved en spørring til SKRIV sin valideringstjeneste. Det går greit når du jobber med 15-20 objekter, men når du jobber med flere hundre objekt så tar det mangfoldige minutter. Nå validerer vi EN gang: FØR kopiering, og det går veldig mye raskere enn før. I tillegg skriver vi kun én bulkedit-oppføring i endringsloggen, ikke én oppføring per objekt.

Ulempen er at denne valideringen er strengere: Hvis objektet du kopierer fra mangler en egenskap med viktighet påkrevd absolutt så er kopieringen inaktiv - også når det er en helt annen egenskap du ønsker å kopiere. Her hadde det vært gunstig med en bedre tilbakemelding til brukeren, men det har vi ikke prioritert.

Så hvis du plundrer med kopiering av egenskaper: Sjekk om objektet du kopierer fra har alle påkrevde egenskaper.

Fjernet mye unødvendig datainnhenting

Vi fant og ryddet vekk mye unødvendig datainnhenting. For eksempel når du åpner fanen for endringslogg så trenger du ikke også laste ned alle for filer og vegobjekter. Slike eksempler fant vi mange av, og vi ryddet vekk eller slo sammen mye overflødig datainnhenting. Hovedsiden for kontrakten er også delt inn i flere elementer som lastes uavhengig av hverandre, med flere "underspinnere".

Noen tilfeller der registering til NVDB feilet på grunn av ugyldig versjonsnummer

Den 31. oktober fikk over 200.000 objekter endret versjonsnummer i NVDB. Årsaken var opprydding i historiske data der vi fjernet ugyldige versjoner og berørte objekt fikk dermed et lavere versjonsnummer enn før. Dette berører et par prosent av alle rekkverk, skiltpunkt og skiltplater. Alle datafangstkontrakter som importerte data fra NVDB før 31.10 kan være rammet, og vi har allerede en håndfull supportsaker med dette problemet.

Vi har rullet ut en kodefiks der vi skrur ned versjonsnummer når vi møter meldingen "vegobjektet finnes ikke xxxxx:Y", der Y er det versjonsnummeret som ble ugyldig 31.10. Berørte brukere skal nå kunne sende inn data til NVDB som normalt.

Skydrift av server og database

Et svært viktig grep var å flytte både databasen og server opp på mer moderne driftsplattform i skyen (Amazon web services). Uten skydrift hadde det ikke vært mulig å anvende den teknologien oppå databaselaget som til slutt ga den ønskede ytelsesforbedringen 14.11.

Høydereferanse (HREF) er straks på plass

Koden for visning og redigering av høydereferanse, også kalt HREF, har vært klar til testing siden september - men andre akutte driftsproblemer og arbeidet med ytelse har bokstavelig talt blokkert utrullingen. Hvis det ikke dukker opp mer uforutsett så regner vi med at denne koden kommer i produksjon i løpet av noen arbeidsdager.

I motsetning til andre metadata geometri (også kjent som kvalitetsparametre) så blir kolonnen for Høydereferanse editerbar av brukeren.

Dobbeltlagring til NVDB

Dette problemet er vi rimelig sikre på skyldes allmenn treghet i database (og systemet for øvrig): Ved lagring av mange objekter til NVDB så har noen brukere opplevd at ingenting skjer etter at de har trykket "registrer til NVDB". Neste gang de prøver så viser det seg at joda - feilmedling om versjonskonflikt er jo fordi data ble lagret til NVDB den første gangen, men fordi ting gikk såpass tregt har nettleser "gitt opp" å vente på resultatet av denne lagringen.

Vi har innført et lite tricks som deaktiverer "registrer"-knappen den første gangen du trykker. Men generelt tror vi det beste tiltaket her er at systemet nå er blitt mye kjappere enn før.

Driftsmeldinger på web og epost

Vi minner om at driftsmeldinger for alle NVDB-produktene publiseres på https://nvdbstatus.atlas.vegvesen.no/. Der kan du også legge inn epostadressen din hvis du vil ha varsling på epost.