Stikkordarkiv: NVDB

Søk etter historiske data

Publisert av

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?

Publisert av

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.

Trafikkmengde (ÅDT) per 2013.08.06

Publisert av

Det tar TID å endre innarbeide vaner og metoder. Sist uke ble vi spurt veldig pent om vi kunne lage de samme dataene som i fjor og forfjor. Rent prinsippielt burde vi kanskje tvunget alle til å hente slike data fra vegkart og/eller api‘et, men så er det noe med å revolusjonere verden i små steg, respekt for at andre enn oss kan være i tidsnød og at vi generelt liker å føle oss snille.

I hvert fall, siden vi ble spurt veldig pent laget vi et datasett med ÅDT tall for europa-, riks-, fylkes- og kommunale veger på ESRI geodatabase (gdb-format) gyldig per 6. august 2013. Det finner du her (last ned).

Tilføyelse 13.08: Vi har også konvertert disse trafikkmengedatene til det åpne formatet spatialLIte. (last ned). Eller browse mappen på vår ftp-server ftp://vegvesen.hostedftp.com/~StatensVegvesen/trafikkmengde/ 

Merk at vi har opprettet et eget attribute domain for å få menneskelig lesbare egenskapsnavn. De fleste verktøy vil automatisk bruke disse navnene (f.eks. alle ESRI produkter). Men spatialLite-dataene viser egenskapsnavnene for selve tabellene, og disse er nok ikke så veldig intuitive uten kjennskap til NVDB datakatalog. (Dette gjelder også hvis man åpner gdb-dataene i f.eks. FME). De mest relevante egenskapene er

TADT_4623: Selve ÅDT verdiene (årsdøgntrafikk). 
AR_4621: Hvilket år ÅDT-tallet er beregnet for.
ALNGX_4624: Andel lange (>5.6m) kjøretøy, i prosent.

Tallverdiene i egenskapsnavnet er ID til denne egenskapen i NVDB datakatalog. Hva dette betyr kan du slå opp i api’et, f.eks. slik: https://www.vegvesen.no/nvdb/api/datakatalog/egenskapstype/4623 . Hver  objekttype har sitt sett med egenskaper, hvilke som gjelder for trafikkmengde kan du finne ut her https://www.vegvesen.no/nvdb/api/datakatalog/objekttyper/540. Eventuelt kan du finne de samme kodene i den offisielle datakatlogen (java-program).

Merk også at dette datasettet kun inkluderer de strekningene på ERFK-vegnettet som har trafikkdata (per 6. august 2013). Du får altså ikke et komplett vegnett ved å laste ned disse dataene.

Bruk av dataene skjer (som alltid) etter Norsk lisens for offentlige data.