Kategoriarkiv: NVDB api

Vegnett i NVDB api

Publisert av

Vi har jobbet med erfaringene fra den første vegnett-prototypen vi lanserte i september 2013, og er nå stolte over å kunne lansere den første beta-versjonen av vegnettsfunksjonalitet i NVDB api’et. Formatet er GML (versjon 3.2), og applikasjonsskjemaet er basert på SOSI Vegnett 4.5. Merk at funksjonalitet og grensesnitt vil bli utviklet i nye versjoner.

Vegnett-beta i NVDB api

Vegnett-beta i NVDB api

https://www.vegvesen.no/nvdb/api/dokumentasjon/vegnett

Vi jobber hardt for å fjerne beta-stempelet fra endepunkt for å hente fagdata (data langs vegen). Det kan hende at vi ønsker å beholde beta-stempelet for veg-endepunktet litt lenger, det avhenger av erfaringene vi gjør oss nå.

NVDB api fagdata er på vei ut av beta, mens vegnett-delen av api’et er ultra-beta

Vi minner også om at det er laget en QGIS plugin for å laste ned vegnett fra den prototypen vi lanserte i fjor. For å ta i bruk det nye vegnett-endepunktet må plugin’en bygges om: I stedet for å bygge geometriske objekter i python (json-parsing i python er gøy!) må man bruke generiske GML-støtte i enten QGIS eller python. En fin test på interoperabiliteten til åpne formater og vårt nasjonale standardiseringsarbeid!

Har kun halvparten av ulykkene geometri?

Publisert av

Et vegkart-søk gir kjapt svaret at kun halvparten av ulykkene har egenskapen «Geometri, punkt».

Vegkart-søk - er det virkelig slik at kun halvparten av ulykkene har koordinater?

Har kun halvparten av ulykkene geometri?

Men dette kan da umulig stemme… hvis vi ikke vet hvor ulykken er så kan vi heller ikke knytte den til riktig veg, få statistikk for ulykker per kommune, langs E6 og så videre.

Selvfølgelig er det ikke slik at halvparten av ulykkene ikke er stedfestet

Forvirringen skyldes at ikke alle objekter har det vi kaller egengeometri. Da får man ut koordinater som en egen attributt til objektet, i listen over egenskaper

<egenskap>
<id>5123</id>
<navn>Geometri, punkt</navn>
<verdi>POINT (270201.0 7038482.0)</verdi>
</egenskap>

Alle objekter i NVDB er stedfestet på vegnettet. Detaljene står i lokasjons-objektet, lengre ned.

<lokasjon>
<egengeometri>true</egengeometri>
<fylke nummer="16" navn="SØR-TRØNDELAG"/>
<geometriUtm33>POINT (270201 7038482)</geometriUtm33>
<geometriWgs84>POINT (10.397118021702223 63.40058266939705)</geometriWgs84>
<kommune nummer="1601" navn="TRONDHEIM"/>
<kontraktsomrader>
<kontraktsomrade navn="1606 TrondheimMalvik 2010-2015"/>
</kontraktsomrader>
<politiDistrikt nummer="20" navn="Sør-Trøndelag"/>
<region nummer="4" navn="MIDT"/>
<riksvegruter>
<riksvegrute nummer="6A" navn="RUTE6A"/>
</riksvegruter>
<vegAvdeling nummer="16" navn="Sør-Trøndelag"/>
<vegReferanser>
<vegReferanse>
<fraMeter>403</fraMeter>
<fylke>16</fylke>
<hp>12</hp>
<kategori>E</kategori>
<kommune>0</kommune>
<nummer>6</nummer>
<status>V</status>
</vegReferanse>
</vegReferanser>
<veglenker>
<veglenke til="0.150519" sidepos="NULL" id="72811" fra="0.150519" direction="WITH"/>
</veglenker>
</lokasjon>
<versjonsId>1</versjonsId>
</vegObjekt>

Ulykker uten egengeometri vil mangle parameteren <egengeometri>true</egengeometri>, ellers er lokasjonsobjektet likt. Det beskriver eksakt hvilken veglenke som ulykken skjedde på. Vegnummer, meterverdi og hp-inndeling – og for den saks skyld kommunenummer – kan bli endret gjennom vegutbygging eller administrative vedtak, men veglenke er en persistent koblingsnøkkel på tvers av disse endringene.

Referansegeomerti  – den posisjonen som står i lokasjonsobjektet – er på vegen senterlinje. Dette gir god mening for f.eks. fartsgrenser og trafikkmengde, mens f.eks. et skilt som regel er plassert godt utenfor vegkroppen. Den fysiske posisjonen blir best beskrevet med egengeometri.

I NVDB har vi et par hundre tusen trafikkulykker registrert gjennom cirka 40 år. Rutiner for stedfesting har endret seg ganske mye gjennom disse årene. Datakilde kan være så mangt, som legevakt, sykehus, politi eller Vegvesenets egne folk. Stedfestingen vil derfor ha varierende presisjon, og noen ganger har vi rett og slett ikke nok opplysninger til å gi hverken egengeometri eller knytte ulykken til riktig veg (hvorfor krasher så mange i Nordmarka?)

Hvorfor krasjer så mange i Nordmarka?

Publisert av

Zoomer du inn på Nordmarka og søker på trafikkulykke får du 5.570 treff:

NVDB har 5.570 trafikkulykker midt i skauen i Nordmarka

Hvordan klarer folk å krasje midt i svarte granskauen?

Lenke til dette vegkart-søket

Dette må jo være feil…? Jepp, og årsaken er at vi i Vegvesenet ikke har klart å knytte riktig ulykke til riktig veg. Det er mange kilder til ulykkesdata (helsevesen, politi etc), og svært få av dem som rapporterer er vegnettsnerder. Det er vrient å få en fornuftig stedfesting ut av beskrivelser som «påkjørt i gangveg, Stabekk».

Vi har ennå ikke fått gjennomslag for at håndbok v830 Nasjonalt vegreferansesystem bør være pensum på politi- og sykepleierhøgskolen… men så er vi nok alene om å synes at det er litt for få vegnettsnerder i verden.

Selv uten stedfesting er dette viktige data som skal inngå i statistikk over antall registrerte ulykker. Da må de inn i NVDB, og da må de ha en vegnettstilknytning. Løsningen vår er langt fra perfekt: Vi knytter dem til vegnummer 99.999, og legger denne fiktive vegstubben langt utenom allfarveg. Det gir litt pussige utslag når vi plotter data på et kart, men det må vi inntil videre leve med.

Vi gratulerer Geodata med kul trafikkdata-applikasjon

Publisert av

Geodata A/S har fått masse velfortjent skryt for sin applikasjon som viser statistikk over trafikkulykker. Vi er selvsagt hemningsløst overbegeistret over at andre lager kule løsninger basert på de datasettene vi forvalter og gjør åpent tilgjengelig i vårt api.

Vårt motto: Åpne data er bra — åpne api’er er fantastisk!

Snerten webapplikasjon for interaktiv "datadrilling" ned i trafikkulykker

Geodata har laget en snerten webapplikasjon for interaktiv «datadrilling» på trafikkulykker-statistikk

Men — vi må dessverre også helle litt malurt i begeret: Tallene avviker en del fra den offisielle fasiten i NVDB, av flere grunner:

  • Løsningen bruker et datauttrekk fra en tid tilbake. Når det skjer endringer i NVDB vil geodata-løsningen ikke fange opp disse — i hvert fall inntil Geodata lager oppdateringsrutiner for å fange opp alle endringer. (Med bruk av NVDB api’ets søkefunksjon og parameteren «endretdato» bør det være en smal sak)
  • Geodata har filtrert ut en del ulykker der kvaliteten på koordinater og/eller egenskapsverdier var mangelfull. (Ja, vi vil svært gjerne ha NVDB ID på disse, slik at vi kan rette dem).
  • Muligens er det også andre grunner til avvik…?  Det kan ikke vi svare på.

Geodata har lovet å oppdatere sin «disclaimer» med riktig beskrivelse av datagrunnlaget… Vi venter i spenning!

Men i hvert fall – nå vet du hvorfor søk i vegkart eller NVDB api’et ikke gir identisk svar med Geodata sin løsning. Og hvorfor statistikken derfra må brukes med en viss varsomhet, i hvert fall inntil videre.

Har dette noe å si? Er ikke dette meningsløst flisespikkeri?

Tja… det spørs helt på hva man skal bruke dataene til. Jeg vil nok tro at Geodata sin webapplikasjon jevnt over viser et sannferdig bilde av ulykkesdata, fordeling og historikk. Jevnt burde avvikene i forhold til fasiten i NVDB være få og små (men vi har ikke sjekket det.) Til utforsking, «data drilling» og for å få et bilde av ulykkesfordeling i rom og tid — og gjerne filtrert på kjøretøy, skadegrad etc — så er applikasjonen et fantastisk verktøy! Men hvis man trenger offisielle tall og statistikk så bør man vite at denne løsningen ikke stemmer 100% med fasiten.

NVDB api og FME

Publisert av

FME — Feature Manipulation Engine — er et verktøy som geodatanerder fort blir glade i. Det er generelt et veldig kraftfullt verktøy for alle hånde datakonvertering, transformasjon, geografiske analyser og en del anna moro.

Undertegnede hadde det utrolig moro med å lage et par FME workspace-eksempler som leser data fra NVDB api. Både presentasjon og workspace eksempler er tilgjengelig her:

https://github.com/LtGlahn/vegdatalabs_fme

Smertefri oppgradering møter brutal virkelighet

Publisert av

Tilføyelse 08:58 12/5: Vegkart er ustabilt, vi regner med at det ikke er langvarig.

Tilføyelse 09:17 29/4: Vegkart er ørlite grann ustabilt, og kan innimellom være utilgjengelig. Som regel blir Vegkart tilgjengelig igjen etter kort tid (og viser at rutinene for avviksdetektering og restart fungerer!). Vi jobber med å finne og fjerne årsaken til stabilitetsproblemene. Men NVDB api fungerer!

Tilføyelse 09:08 25/4: Vegkart friskmeldt. (Men visning av flyfoto fungerer ikke!). For å få flyfoto til å fungere må vi a) å få ordnet nytt oppsett på kartverkets BAAT tjener, b) justere vår egen konfigurasjon ørlite grann. Enkelt å fikse (uten nedetid!), men regner nok med at det tar et par dager — det er mange aktører som hver må gjøre en liten justering.

Tilføyelse 08:40 25/4: Vi var litt for raske med å friskmelde vegkart. Konfigurasjonen må justeres litt. Vi har en kvikk fiks som vi regner med vil løse problemet, håper det kan gå fort å få det på plass. API’et fungerer normalt.

Tilføyelse 10:50 24/4: Både NVDB API og vegkart fungerer normalt. Eneste unntak er visning av flyfoto i vegkart (ny funksjonalitet), pga endringer i konfigurasjonsoppsett. (Vår tilgang til Norge Digitalt-tjenester må justereres etter ny konfigurasjon, og det tar trolig noen dager)    

Tilføyelse 10:50 24/4: Hverken NVDB API eller vegkart er tilgjengelig. 

Tilføyelse 09:36 24/4: Vegkart fungerer ikke, men NVDB api fungerer fungerte normalt; Situasjonen stabiliserte seg onsdag ettermiddag, og alt så ut til å virke i både vegkart og NVDB api. Men — torsdag morgen sluttet vegkart å fungere pga et konfigurasjonsproblem. Vi regner med at dette skal la seg løse raskt..

Tilføyelse 15:36 23/4: Vi jublet litt for tidlig; det mangler manglet tydeligvis noen objekttyper, f.eks fikk vi null treff på trafikkmengde. FIKSA i løpet av onsdag ettermiddag.

Tilføyelse 14:54 23/4: Alt ser ut til å virke normalt igjen. Vi beklager ulempen, og krysser fingrene…

Vi ruller ut ny versjon av Vegkart og NVDB api’et. Dette skal skje uten at brukerne merker noe som helst — annet enn at vi har gjort en del flotte forbedringer.

Dessverre gikk det ikke slik i dag. Eksakt hvorfor vet vi ikke helt, vi kommer tilbake med mer info når vi vet hva som gikk galt, og når ting kommer på lufta igjen. Sist gang dette skjedde måtte vi vente på at total re-indeksering skulle bli ferdig, og det tok dengang cirka halvannet døgn.

Vi beklager på det sterkeste de ulempene dette medfører. Beta-perioden skal brukes aktivt til å perfeksjonere driftsrutiner — men uten at det gir denne typen ulemper for brukerne våre.

KOSTRA-rapportering for kommunal veg

Publisert av

KOSTRA-rapportering er en oppgave som krever mye ressurser av offentlig forvaltning. En av de vanskelige tingene er å telle riktig lengde på vegnettet — selv internt i Vegvesenet sliter vi med det. I vår iver etter å fornye, forbedre og forenkle har vi selvsagt tenkt på hvordan dette kan gjøres mer elegant.

I vegkart og NVDB api’et får man summert opp lengden til alle strekningsobjekter i et søk (det inngår i responsen fra api’et søkefunksjon). Slik sett kunne man brukt et hvilket som helst heldekkende datasett (f.eks. fartsgrenser) til å finne lengden på vegnettet. Vi vegdata-nerder anbefaler at man bruker vegreferanse, men det er et par fallgruber: Vi tar ikke med såkalt «fiktiv veg», og søket avgrenses til vegstatus «eksisterende veg».

Eksakt hvorfor det er slik blir litt for omfattende å gå inn på nå, men interesserte anbefales å begynne lesningen i den aldeles utmerkede håndbok v830 Nasjonalt vegreferansesystem.

For alle andre så holder det å vite at dette vegkart-søket gir deg lengden på kommunale veger i Arendal kommune. Tallet du er ute etter er 239.419 meter (per 9/5 2017), som du ser i Vegkart.

Vegkart-søk for KOSTRA-rapportering. Vegreferanse på kommunalveger med filter: Vegtype forskjellig fra "Fiktiv veg" og vegstatus lik "Eksisterende veg" og "konnekteringslenke forskjellig fra konnekteringslenke" (dvs vi tar IKKE med konnekteringslenker i søket)

Disclaimer: Jeg aner ikke om KOSTRA rapportering også omfatter private veger og skogsbilveger. I så fall er det trivielt å føye dem til i søkefeltet.

For lokalpatrioter utenfor Arendal er det selvsagt trivielt å skifte ut den vakre sørlandsbyen med sin egen favorittkoummune: Klikk på «x», en bak Arendal, klikk på en ledig plass i søkefeltet og skriv ditt kommunenavn. Press Enter.

Voila, instant KOSTRA-rapportering!

NVDB gjør åpen forvaltning

Publisert av

Vi som synes det er artig med vegdata og sånn synes det er kjempeartig at de nye tingene vi gjør  — er nettopp den typen digitalisering som Storting og regjering ønsker fra forvaltningen. At vi kan gjøre det — i stedet for å snakke om det — er selvsagt kjempemoro.

Åpne data er bra — åpen forvaltning er fantastisk!

På mange måter slipper Nasjonal Vegdatabank (NVDB)  ekstremt billig unna fra det felles digitaliseringsprosjektet: Andre etater må sikre at svært sensitive personopplysninger ikke havner på avveie, samtidig som data flyter elegant mellom fagsystem og etater. Vi vegnerder skal bare bygge moderne grensesnitt mot vårt felles register over vegnettet. Med ytterst få unntak er dette offentlig informasjon som bør, kan og skal være åpent tilgjengelig.

NVDB api’et inngår i en modernisering av Vegvesenets tekniske infrastruktur. Det nye API’et gjør at vi kan fornye, forenkle og forbedre, med svært gode resultater — og vi er bare så vidt i gang:

  • Hva skal NVDB inneholde? Informasjonen i NVDB har en nøkkelrolle i planlegging av samferdsel (på alle tidshorisonter!), og i forvaltning og drift av vegnettet. Balansegangen mellom hva som skal lagres i NVDB og hva som hører hjemme i andre fagsystem er krevende, og krever et godt hode og evne til samarbeid på tvers av fagmiljø og avdelinger.
  • Vi vil servere et topologisk, navigerbart vegnett i API’et. (Vi mekket en kjapp prototyp til frigjøringen av kartdata H-2013, bare for å vise hvordan vi tenker).
  • Skrivefunksjoner for fagdata basert på REST prinsipper. Dette er faktisk litt tøffere enn det høres ut som, f.eks. har en moderne tunnel relasjoner til flere tusen andre vegobjekter – eksempel. Krevende, men moro! 
  • Ny vegnettseditor.
  • Skrivefunksjoner for vegnett (dette tar vi til sist).

Dette gjør vi fordi vi trenger disse moderniseringene internt i Vegvesenet — men det er en fryd og fornøyelse å kunne tilby de samme grensesnittene til resten av samfunnet.

Dette er åpen forvaltning i praksis — og det er vi stolte av!

A little note to oor our international fans

Publisert av

We (the Norwegian Road Administration) have received some intriguing questions about the API to the Norwegian Road Data Base. Unfortunately for Non-Norwegian programmers, all documentation is in Norwegian only. Hopefully, this very brief introduction may motivate you to learn a very beautiful language. (It aint that hard – even the children here speak it fluently). Or perhaps we some day should adapt to the other 99.93% of the population and provide documentation in English…

Update 2020: Use version 3 of NVDB api https://nvdbapiles-v3.atlas.vegvesen.no/dokumentasjon/

Update 2020: You may also enjoy this English summary: https://nvdbtransportportal.vegdata.no/

Virtually all data in the Norwegian Road Data (NVDB) base are available under the Norwegian Licence for Open Government Data (NLOD), without carge.

If you want road data for navigational purposes you should have a look at the data we use in our own route planner (esri and spatialLite formats).

Besides the road network itself, the NVDB has of lots of data attached to the road network (think of those as anything road related found along the topological network). We have more than 300 different types of objects tied to the road network: Speed limits, toll station, traffic flow, traffic accidents, curvature, … the list goes on. Those objects are all defined in our data catalogue. (The official version is a java program, you’ll find a link to it here, most of you will probably prefer our unofficial web version). And (virtually) all of those data are available through our road database (NDRB) api.

The data structure in the NVDB API may seem a little complex at first, in particular if you expect everything to have a straightforward name – value data structure. Each object has a list of egenskaper  (properties, plural), containing any number of  the element egenskap (property, singular). Each egenskap (property) has an ID, a name (navn), a value (verdi) and a link to it’s own definition in the data catalogue.

To find what it actually costs to pass the station you’d search through the list of egenskaper  for the egenskap  with ID = 1820 and inspect that value (verdi). You’d probably expect the value to be in Norwegian Kroner, and you’d be right — which is confirmed by the tag enhet (unit).

And don’t forget the API’s twin companion Vegkart, which is a web application that shows data directly from our API. Seeing the objects location and probing their properties might be helpful to those unfamiliar with our API. Your successful Vegkart-query contains a download-link that takes you directly to NVDB api.

Toll station at Klett, south of Trondheim, Norway.

Toll station at Klett, south of Trondheim, Norway.

Any results from a successful Vegkart query can be downloaded (as csv or SOSI), but with some caveats.

Vegkart og NVDB API er oppdatert

Publisert av

Det ble i dag installert en ny versjon av både Vegkart i NVDB API. Leveransen har hatt fokus på å feilrettinger og utvidete søkemuligheter i Vegkart.

Endringer i Vegkart:

  • Det er nå mulig å søke innenfor én eller flere riksvegruter
  • Det er nå mulig å søke innenfor én eller flere kontraktsområder
  • Feilretting: Maptiles blir ikke lenger plassert feil i IE10 ved rask zooming

Endringer i NVDB API:

  • Det er nå mulig å søke innenfor én eller flere riksvegruter i /sok-endepunktet
  • Det er nå mulig å søke innenfor én eller flere kontraktsområder i /sok-endepunktet
  • Feilretting: Noen objekter inneholder ikke lenger referanse til feil morobjekt
  • Feilretting: /omrader-endepunktet inneholder CORS-headere