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.

Hvor mangler vi kontraktsområde?

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.

Skjermdump som viser vegkart-søk etter utstrekningen til kontraktsområde 1202 Stor-Bergen 2015-2020

Men hvordan finner vi det vegnettet som mangler kontraktsområde?

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:

Har du kodeeksempler?

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.

Webinar i Datafangst for vegforvalter

2. og 9. september hadde vi webinar rettet mot dere som mottar data.

Se mer informasjon her

Del 1:

  • Prosjektadministrasjon
  • Leveranseplan
  • Brukerhåndtering
  • Kontraktsgrupper
  • Objektliste
  • Slett og arkiver kontrakt
  • Kommentarer
  • Godkjenne leveranse

Opptak finner du her

Del 2:

  • Stedfesting av objekt
  • Eksisterende data i NVDB
  • Datoproblematikk
  • Sammenkoblinger og assosiasjoner i Datakatalogen
  • Registrer i NVDB

Opptak finner du her

NVDB Rutedatasett – nytt datasett for navigasjon

Elveg 2.0 er et datasett som i utgangspunktet ble laget for to formål: Være forvaltingsdatasett mot kommunene gjennom Sentral FKB, og også være et datasett som grunnlag for navigasjon. Med tanke på navigasjon har vi nå laget et svært forenklet alternativ til dette. NVDB Rutedatasett er et verktøyuavhengig rutedatasett (SpatiaLite) der vegnettet er segmentert på aktuelle strekningsegenskaper fra NVDB. Vegsperringer og svingerestriksjoner leveres som egne objekter. Datasettet vil tilgjengeliggjøres i nye versjoner samtidig med Elveg 2.0, dvs. minimum 10 ganger i året.

NVDB Rutedatasett levers som veglenker segmentert på utvalgte egenskaper. Vegsperringer og svingerestriksjoner leveres som egne objekter.

Et testdatasett (fylkesvise filer) og en foreløpig versjon av produktspesifikasjonen er lagt ut på NVDB Rutedatasett – Geonorge Register. I løpet av høsten 2021 vil datasettet suppleres med flere egenskaper. Disse er nevnt i produktspesifikasjonen. NVDB Rutedatasett er likevel tilgjengeliggjort som testdatasett slik at ev. innspill til produktet og innholdet kan vurderes frem mot en første offisiell versjon.

Innspill til innhold eller andre kommentarer eller spørsmål stilles til linda.stoeng@vegvesen.no, ev. via kontaktmail satt opp der du finner datasettet. Tilbakemeldinger svares ut i løpet av august 2021.

Utviklingplanar er lagt ut

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.

Registrering av Vegdekke

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.

Bindelag og Slitelag

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.

Fremgangsmåte ved samlet leveranse/fil

  1. Leveransen eksporteres til fil (eller lignende) for senere arbeid
  2. Alle data som omhandler slitelag fjernes fra prosjektet/kontrakten
  3. Data for bindelag kontrolleres og klargjøres for innsending
  4. Datasettet sendes til NVDB med dato tilbake i tid
    • fortrinnsvis med dato for faktisk dekkelegging
    • alternativt dagen før slitelagdato dersom det er samme dato
  5. Datasett leses inn på nytt fra backup-fil (punkt 1)
  6. Alle data som omhandler bindelag (allerede registrerte data) fjernes fra prosjektet/kontrakten
  7. Data for slitelag kontrolleres og klargjøres for innsending
  8. Objekter opprette ti NVDB i punkt 4 hentes inn i prosjektet/kontrakten for lukking
  9. Datasett sendes til NVDB med dato minimum 1 dag etter startdato for objekter som skal lukkes
    • fortrinnsvis med dato for faktisk dekkelegging

Ved registrering av flere dekkelag deles datasettet opp i flere delsett og punkt 5-9 repeteres til alle lag er registrert.

Registrering av flere objekter på samme strekning

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.

gang-/sykkelveg

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

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 som ikke er del av vegen

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.

Utvikling fremover

  • Vi håper på at utviklingen av registreringsklienter på sikt vil automatisere mye av problematikken rundt dekkelegging. Vi ser for eksempel for oss at klienten kan skille på om det er bindelag/slitelag og ta inn be om dato for legging av de ulike lagene og på den måten håndtere alt med deling, lukking og oppdatering.
  • Fortau og gangstier vil på sikt få vegsystemreferanser i NVDB. Når det skjer vil det være mulig å legge vegdekke på disse objektene likt med gan-/sykkelveg.
  • Vi vurderer innføring av et nytt objekt «Dekke» som kan benyttes til dekkeobjekter som ikke er del av vegen, men likevel har en tilhørighet.
  • Vi vurdere endring av Vegdekkeobjektet fra dagens utforming som tillater egengeometri til å være et «abstrakt» objekt som bare forholder seg til stedfesting (og feltvalg) på vegnettet.

Webinar i Datafangst for entreprenører

27. mai holdt Statens vegvesen og datafangstverktøyet et webinar for entreprenører.

Datafangst er et webbasert verktøy som brukes i dataflyt til Nasjonal vegdatabank (NVDB) og Felles kartdatabase (FKB). Her mellomlagres data for kontroll og redigering før data sendes til NVDB.

Webinaret hadde fokus på praktisk bruk, tips og triks og svarte på ofte stilte spørsmål rettet mot entreprenører.

NVDB-Skriv URL uten «atlas» legges snart ned

NVDB API Skriv har blitt etablert i nye driftsmiljøer på Atlas-plattformen hos Statens vegvesen. Vi har hatt begge miljøene opperative i en god periode nå og regner med mange har byttet til nye URLer. Vi vil nå starte prosessen med å stenge av de gamle URLene, og ber nå alle brukere om å se over at alle system er oppdatere med nye URLer.

Planlagt stenging av gamle URLer er 1. juli 2021.

På grunn av tilbakemeldinger om at ikke alle systemer har oppdatert URL-ene til de nye utsettes stenging av gamle adresser til August 2021. Vi kommer tilbake med ny dato etter hver som vi får tidsplan fra de systemene som ikke er klare.

Siden dette kom nært opp til ferie for mange og at informasjonen ikke ser ut til å ha nådd frem til alle i tidligere faser er vi litt fleksible med nedstengingsdato her.

Systemtestmiljø:
https://www.utv.vegvesen.no/nvdb/apiskriv/* => https://nvdbapiskriv-stm.utv.atlas.vegvesen.no/*

Akseptansetestmiljø:
https://www.test.vegvesen.no/nvdb/apiskriv/* => https://nvdbapiskriv.test.atlas.vegvesen.no/*

Produksjonsmiljø:
https://www.vegvesen.no/nvdb/apiskriv/* => https://nvdbapiskriv.atlas.vegvesen.no/*

I Atlas-miljøet brukes en ny autentiseringsmekanisme, basert på OAuth2 (OpenId Connect). Når klienter skifter over til nye URLer må derfor også autentiseringlogikken omprogrammeres. Hvordan dette kan gjøres er forklart på https://apiskriv.vegdata.no/autentisering.

Dersom det er spørsmål rundt dette, ta kontakt med nvdb@vegvesen.no.

Dersom det er behov for å holde det gamle miljøet oppe en stund til fremover må vi ha tilbakemelding om dette snarest med begrunnelse og dato for når det ikke er nødvendig lenger.