Koordinatkrangel i NVDB api V1

Vi har nettopp satt i produksjon en ny versjon 1 av NVDB api.

  • Hvis du bruker lengde- og breddegrad så er rekkefølgen nå er byttet om – eller mer presist: Vi har byttet tilbake slik det var før juni 2016.
  • Vi serverer nå kun 2D koordinater. Ikke en blanding av 2D og 3D.

Mange eksisterende klienter fikk problemer på grunn av dette. Derfor ruller vi V1 tilbake slik det var før juni 2016. Beklager at dette tok tid!

Merk at V1 nå avviker fra V2 på de to punktene over.

Koordinatkrangel.

Dette med rekkefølgen på koordinater for lengde- og breddegrad har gitt mye hodebry.

  • Matematikere og programmerere har ofte foretrukket rekkefølgen X, Y, det vil si rekkefølgen (øst, nord) – eller (lon, lat) (lengdegrad, breddegrad).
  • Geografer har likt best rekkefølgen (grader N, grader E), eller (lat, lon).

Heldigvis har vi internasjonal standardisering. V2 vil følge denne standarden, og det samme gjør skriveAPI’et. Der er det (lat, lon) som gjelder, evt (lat, lon, z) for 3D koordinater.

For V1 gjør vi det motsatt: Her tilbyr vi lengde- og breddegrad som (lon, lat). Altså motsatt av standarden. Og uten høydeinformasjon.

<geometriWgs84>POINT (10.63317257269053 63.42266891319099)</geometriWgs84>

Dette gjelder altså bare lengde- og breddegrad: For UTM-koordinatene er det heldigvis ingen som krangler på rekkefølgen.

Og så er det bare å beklage – både at vi gjorde denne endringen i utgangspunktet, og at det tok såpass lang tid før vi fikk skrudd det tilbake.

 

Bruk NVDB api i PowerBI

Med forbehold om at jeg har forstått alt rett — PowerBI er (et av) Microsofts tilbud for lettvint dataanalyse. Takket være twitterbruker @Alslinet har vi nå en vel fungerende oppskrift for å anvende data rett fra NVDB api rett inn i PowerBI.

Selve appen er ikke lenger tilgjengelig  (det hadde vi heller ikke ventet, det var en kjapp test/demo som gikk på gratiskvoten til @Alslinet).

Eksempel fra hvordan man bygger visualisering / dataanalyse med NVDB data i powerBI

Eksempel fra hvordan man bygger visualisering / dataanalyse med NVDB data i powerBI. Takk til Vegard @Alslinet .

Bruksanvisning ligger her. (Evt også som word-vedlegg her: PowerBI og NVDB). Vi har standardtrickset for å laste ned større datamengder i én klump (sette antall = f.eks. 10.000). Dette trickset vil ikke fungere like bra i kommende versjoner av NVDB api – man må gå over til å bruke pagineringsfunksjoner, og det blir jo spennende å se hvor bra dette funker mot tjenester som PowerBI. Ellers må du manuelt fortelle systemet at det skal navigere nedover i JSON-strukturen, samt hvordan du konverterer listen med egenskapsverdier til tabell. En del museklikk per verdi, men i grunnen ikke avskrekkende, er mitt inntrykk.

Tusen takk til Twitter-bruker Vegard @Alslinet for at han vil dele sine erfaringer!

Undertegnede er ikke vel bevandret i PowerBI, men for et geodata-hode er inntrykket at PowerBI har de standardmetodene du forventer for å drille ned i datasettet og se på statistikk per område, fordeling av egenskverdier med mere – koblet mot kartpresentasjon slik at du ser hvilket geografisk område du forsker på.

Nå er det ENDA enklere å lage søk mot NVDB api

Vis eksportvalg. Eller "last-ned-data-pila", som jeg kaller det. (eller «eksporter data» som er mouseover-teksten) har fått ny funksjonalitet: Du får nå fiks ferdig lenke til et gyldig søk mot NVDB api’et.

"Vis eksportvalg" har fått ny funksjon. Der det står API finner du lenken til eksakt det samme søket som Vegkart bruker mot NVDB api.

«Vis eksportvalg» har fått ny funksjon. Der det står API finner du lenken til eksakt det samme søket som Vegkart bruker mot NVDB api.

Dette forenkler utvikling mot NVDB api vesentlig. Fremfor å mekke på søkeobjekt fra nettleserens adressefelt (denne oppskriften) henter man nå fungerende NVDB api-søk direkte fra vegkart.

 

Vegvesenets første åpen kildekode-prosjekt?

Vi har i hvert fall ikke funnet noen andre eksempler på prosjekt som i sin helhet er kjørt som åpen kildekode-prosjekt. Riktignok snakker vi om et lite prosjekt (ca 150 utviklingstimer til nå), og all utvikling så langt er gjort av et lite team hos én leverandør — så forskjellen til andre utviklingsprosjekt er i praksis ikke så veldig stor. Bortsett fra dette med at kildekoden ligger åpent fra dag 1, selvfølgelig (gplv2 lisens).

Det er alltid morsomt å sette rekord — og vi er NESTEN helt sikre på at dette er Vegvesenet sitt aller første utviklingsprosjekt basert på åpen kildekode fra dag 1.

Det vi har laget er en mobilfiendtlig webklient til test av ruteplantjenesten. Dette er ingen publikumsklient, og derfor har vi heller ikke tatt hensyn til universell utforming, tenkt mobile first eller lagt vekt på responsivt design. Vi har strengt tatt ikke hatt andre brukere enn oss selv i tankene for dette testverktøyet — og vi er geodatanerder og vegnettspesialister som trenger et lettvint testverktøy. Punktum.

Testklient ruteplantjenesten. Høyreklikk i kartet for å velge start, stopp, viapunkt eller blokkere rute. Eller bruk stedsnavn- og adressesøk.

Høyreklikk i kartet for å velge start, stopp, viapunkt eller blokkere rute. Eller bruk stedsnavn- og adressesøk.

Teknologisk gjør vi god bruk av anerkjente komponenter, og med mye logikk implementert i javascript. Noe konservativt valgte vi ikke Leaflet, men OpenLayers fordi vi ønsker mest mulig fleksibilitet — det skal være kjapt og billig å føye til nær sagt de særeste datakilder i løsningen.

Teknologivalg og design er styrt av to ønsker: 1) Gjør det enkelt, 2) sikre fleksibilitet for å teste ut nye idéer.

For et lettbeint, billig testverktøy var det effektivt å la leverandøren jobbe i det rammeverket han selv mener han jobber mest effektivt i. Det meste av koden er typescript, og den ferdige løsningen er driftsatt i windows azure. Poenget med å gi leverandøren frihet er fleksibilitet, lave kostnader og at vi har lav terskel for hyppige oppdateringer.

Hva kan den gjøre?

  • Stedsnavn- og adressesøk (kartverkets API) for start- og sluttpunkt
  • Klikk-i-kartet og dra-og-slipp for start, stopp, viapunkt og blokker rute. (Blokker område er foreløbig ikke støttet, men det kommer).
  • Ruteplan innstillinger (foreløbig litt tynt her, men mere kommer)
  • Føy til WMS lag  (bruk   Føy til egne WMS lag – symbolet)
  • Last ned til fil (foreløpig kun KML-format, og uten interessante egenskaper — dette videreutvikles.)

Hvorfor åpen kildekode med GPL-v2 lisens?

Fordi vi hadde lyst, og fordi vi mener dette er den rette tingen å gjøre. Vi tror nok også noen vil finne dette et nyttig arbeidseksempel på hvordan man kan bruke forskjellige API’er fra statsforvaltningen: Ruteplan, søk på adresser og stedsnavn (kartverket), ortofoto fra Norge i Bilder samt hvordan man bruker Norge Digitalt tilgangsnøkler.

Vi valgte en GPLv2-lisens fordi vi ønsker å se andres bidrag til løsningen videreført som åpen kildekode.

Skrevet i GIS

Trafikkmengde der står bomstasjoner

Vi elsker spørsmål — det gir oss føling med behovene der ute, og vi lærer masse av å svare på dem. Men av og til må vi svare nei:

Jeg lurte altså på om det var mulig å få ut trafikkdata (ÅDT) på bomstasjonene i tillegg til de andre variablene som ligger tilgjengelig på bomstasjonsdatasettet hos DIFI.

Grunnen til at vi svarer nei er at det skal svært gode grunner til at vi oppretter nye sekundære datasett. Det beste er å hente data direkte fra NVDB api’et eller fra Vegkart (der man også kan laste ned cvs og excel). Vi kan heller bidra med tips, tricks og vink, samt selvsagt forbedre tjenestene våre. Bomstasjon-datasettet er i en særstilling, det ble lansert før NVDB api’et og er så populært at vi må vedlikeholde det.

En svakhet ved NVDB api’et (og vegkart) er at vi ikke kan gjøre spørringer på objekter som er knyttet til samme sted — for eksempel trafikkmengde der det står bomstasjoner. Denne logikken må i dag skrives på klientsiden.

Dette spørsmålet er en ypperlig anledning til å gi et kodeeksempel på hvordan man finner vegobjekter som deler posisjon i vegnettet.

Prinsippet er at man først henter det minste dataasettet (bomstasjoner). Deretter finner man veglenkene til hver bomstasjon.

"veglenker": [ {  
    "id": 625504,
    "fra": 0.162819,
    "til": 0.162819,
    "direction": "WITH",
    "felt": "2#4K",
    "sidepos": "NULL"
 } ]

Veglenke ID, til og fra brukes til å søke etter trafikkmengde på akkurat den samme posisjonen for denne veglenka. Dette inngår i lokasjonselementet i NVDB api’ets søkefunksjon. I tillegg angis vi objekt ID etc på vanlig måte. Formattert for lesbarhet ser kallet slik ut

https://www.vegvesen.no/nvdb/api/sok?kriterie={'lokasjon': 
   {'veglenker': [{
         'fra': 0.706074, 
         'til': 0.706074, 
         'id': 1811554}
       ]}, 
     'objektTyper': [{
        'start': 0, 
        'id': 540, 
        'antall': 1}
      ]}

Fjerner vi formatteringen og gjør litt URL encoding får vi lenke til et  gyldig søkeeksempel (nettleseravhengig; google chrome gir deg en pent formattert xml).

Hoppsann — her fant vi visst en bug i ny versjon av API’et

Det viser seg at siste API-versjon (produksjonssatt 10.9) returnerer en liste der det samme objektet finnes to ganger. Indekseringsfeil, feilen rettet 17.9.

Men 18 bomstasjoner mangler trafikkmengde!

Det er ikke alle veglenker som har trafikkmengde. Ett eksempel er dette krysset ved Lysaker:

Trafikkmengde finnes ikke på alle ramper og forbindelser i Lysakerkrysset

Grønne prikker er bomstasjoner, blå linjer er trafikkmengde. Vi mangler trafikkmengdedata for Strandveien og forbindelsen E18-Strandveien.

Manglende data er kodet som  «-9999».

Hvor finner jeg data og kode?

Github, selvsagt. Og det er mulig å laste ned en CSV-fil generert den 10.9.2014.

Vi har behold de samme egenskapene som for bomstasjonene på Difi’s datahotell, men har lagt på noen nye:

bomstasjonId - NVDB ID til denne bomstasjonen
aadtTotal - ÅDT, total, d.v.s. årsdøgntrafikk
aadtLGV - ÅDT, andel lange kjøretøy
aadtYear - ÅDT, gjelder for 
aadtId - NVDB ID til denne trafikkmengdeforekomsten

Med NVDB ID er det enkelt å se nærmere på det enkelte vegobjekt. For eksempel bomstasjonen i Drammensveien med ID 86574496

https://www.vegvesen.no/nvdb/api/vegobjekter/objekt/86574496

… og vårt pythonscript har allerede funnet at på denne veglenka har vi denne trafikkmengden:

https://www.vegvesen.no/nvdb/api/vegobjekter/objekt/328461107

Vi ville ikke vært geodatafolk om vi ikke hadde lagt til rette for visning på kart

Derfor skriver vi også to geojson-filer: En som er identisk med bomstasjoner.csv, og en som viser trafikkmengde som strekningsobjekter. (På desktop har github en enkel kartvisning av disse objektene.

Vegdata for navigasjon

Linda Therese Støeng og Knut Jetlund, Statens vegvesen, og Tore Abelvik, Statens kartverk

Statens vegvesen, Statens kartverk og kommunene samarbeider om innsamling, kvalitetssikring og leveranser av data for navigasjon i vegnettet.

 

Tjensvollkrysset i Stavanger. Foto: Knut Opeide, Statens vegvesen

Tjensvollkrysset i Stavanger. Foto: Knut Opeide, Statens vegvesen

Ruteplanlegging, flåtestyring og sanntidsnavigasjon i vegnettet ved hjelp av satellittnavigasjon og digitalt vegnett har blitt en sentral del av hverdagen for både privatpersoner, transportnæringen og ikke minst nødetatene. Med utgangspunkt i nettverksdata og avanserte beregningsalgoritmer finner systemene beste veg mellom to posisjoner. Dette sparer tid for den enkelte og for transportørene, det sparer miljøet for unødvendige utslipp, og det redder liv og verdier ved at nødetatene kommer raskere fram til riktig adresse.

Vi gjør oss avhengige av løsningene, og forventer at data til en hver tid er oppdaterte — samtidig som konsekvensene av feil i data eller feil bruk av dataene kan være dramatiske

Samtidig er det også slik at vi gjør oss avhengige av løsningene, og forventer at data til en hver tid skal være oppdaterte og korrekte. Konsekvensene av feil i data eller feil bruk av dataene kan være dramatiske, enten det er utenlandske vogntogsjåfører som kjører seg fast på vinterstengte fjellveger, eller enda verre: et utrykningskjøretøy som kjører feil og bruker for lang tid på å finne fram til skadestedet.

Det stilles andre krav til data til bruk i nettverksnavigasjon enn til vanlige kartdata. Et navigerbart nettverk må henge sammen i kryss, og lenkene må kjenne hvilke andre lenker de henger sammen med (nettverkstopologi). Nettverket har også restriksjoner og begrensninger som styrer hvor det er mulig og tillatt å ta seg fram. Dette kan for eksempel være envegskjøringer, svingerestriksjoner, fartsgrenser eller høydebegrensninger. I kompliserte kryss med flere felt er det behov for informasjon om hvilket felt man skal plassere seg i for å komme videre dit man skal.

Andre data skal også henge sammen med nettverksdataene. Spesielt gjelder dette adressedata, der det er viktig å ha den logiske sammenhengen mellom et adressepunkt og tilhørende veg. I mange tilfeller kan nærmeste veg til et adressepunkt være en annen enn den innkjørselen går fra, og ved manglende kobling kan da kostbar tid gå tapt ved en utrykning.

Denne artikkelen beskriver forvaltning, kvalitetssikring og distribusjon av vegdata. Adressedata forvaltes i Matrikkelen, og er ikke tema for artikkelen.

Forvaltning av vegdata

Det digitale vegnettet og informasjon knyttet til dette forvaltes i Nasjonal vegdatabank, NVDB. Det topologiske vegnettet er selve basisnettet i NVDB, og all annen informasjon knyttes til dette basisnettet. På denne måten kan vegnettet holdes stabilt selv om tilhørende informasjon som fartsgrenser, vegbredder osv. endres, og informasjon kan også knyttes til vegnettet uavhengig av kanalisering og inndeling i felt.

Data for europa-, riks- og fylkesveger forvaltes av Statens vegvesen gjennom kontinuerlig oppdatering, og viktige endringer skal være på plass i NVDB ved åpning av veganlegg. Data for kommunale, private og skogsbilveger forvaltes av Statens kartverk etter periodiske innmeldinger fra kommunene i forbindelse med forvaltningsrundene for FKB. Statens vegvesen og Statens kartverk avsluttet i 2013 et fellesprosjekt for forbedring av vegnettsgeometrien i NVDB, og dette prosjektet ga spesielt en markant forbedring på fullstendighet og nøyaktighet på kommunale, private og skogsbilveger.

Dataflyten mellom Statens kartverk og kommunene har vært en utfordring over tid, og for å bedre denne er det nå utviklet et eget forvaltingsdatasett, FKB-Vegnett. Datasettet eksporteres fra NVDB, og kommunene bruker så dette for å melde endringer tilbake til Statens kartverk. Statens kartverk kvalitetssikrer endringene, og legger disse inn i NVDB. Det er også satt i gang et arbeid i regi av Geovekst på forvaltningsstrategi for primærdata. En egen arbeidsgruppe for vegtema omfatter blant annet FKB-Vegnett. Det er grunn til å tro at arbeidet vil gi ytterliggere forbedring av forvaltningen, med bedre muligheter for kommunene for å rapportere endringer fortløpende. Videre er det utviklet en ny vegnettseditor for NVDB, som allerede etter kort tids bruk hos Statens vegvesen og Statens kartverk viser positive resultater.

Statens kartverk har som mål å ta tak i endringsdata fra kommunene fortløpende. Dette har vært en utfordring til nå, men med nytt redigeringsverktøy og nye forvaltningsrutiner er det håp om at situasjonen vil bli mye bedre.

Kvalitetssikring

Vegdata skal gjenspeile det fysiske nettverket med topologi, kanalisering og felt, samt restriksjoner og annen informasjon knyttet til nettverket. Konsekvensen er at datamodell og redigering av data blir noe mer komplisert enn vanlige kartdata. Statens vegvesen og Statens kartverk har derfor egne spesialister som sitter på fulltid med redigering og kvalitetssikring av vegnett.

Som nevnt i innledningen kan konsekvensene av feil og mangler i vegdata være dramatiske, og det er derfor behov for en sentral kvalitetssikring av data som skal legges inn. Dette omfatter geometri og topologi, med krav om sammenheng i nettverket på ulike detaljeringsnivåer, fullstendighet på restriksjoner mm.

Det stilles andre krav til data til bruk i nettverksnavigasjon enn til vanlige kartdata

I tillegg til kvalitetssikringen ved innlegging av data kjøres det også en rekke kontroller og tilhørende oppretting i forbindelse med leveranse av produkter fra NVDB. Dette omfatter test av sammenhenger og logisk konsistens i nettverket, og beregning av kjente ruter for å finne avvik. Typiske situasjoner er små gap eller manglende sammenkoblinger i nettverket, som fører til at en rute blir lagt via store omveger.

Distribusjon

Det finnes i dag flere kanaler ut for vegdata fra NVDB. De ferskeste dataene er tilgjengelige via NVDB-API, som gir enkel og rask tilgang til både vegnett og annen informasjon. Enkelt innsyn i dataene via NVDB-API er mulig både via portalen Vegkart (https://www.vegvesen.no/vegkart/vegkart/) og gjennom egne tillegg for vanlige GIS-løsninger. Statens vegvesen har fått mye skryt for å åpne opp tilgangen til NVDB gjennom NVDB REST-API, og ble i 2013 kåret av Difi til Norges mest åpne etat på bakgrunn av nettopp dette.

For leveranse av produkter og tjenester for nettverksnavigasjon er det imidlertid ikke nok med tilgang til de ferskeste dataene. Da vil en fort kunne få feil i form av at en ny veg er lagt inn i datasettet, men at viktige restriksjoner ikke er lagt inn enda. Et annet eksempel er manglende koblinger på grunn av at bare deler av et nytt veganlegg er lagt inn. Det er derfor viktig å kunne tilby kvalitetssikrede, versjonerte produkter og tjenester.

Elveg er et slikt produkt som har eksistert i mange år. Dette produktet leveres i samarbeid mellom Statens vegvesen og Statens kartverk fire ganger i året (http://data.kartverket.no/download/). Produktet består av kommunevise datasett med vegnett, restriksjoner og adressedata. I forbindelse med produksjon av Elveg kjøres en rekke tester og opprettinger slik det er omtalt over. Elveg har sine klare svakheter, og i første rekke gjelder det hyppighet på leveranser, kommunevise datasett, kun SOSI-format, og et begrenset utvalg restriksjoner i tekstfiler. Likevel er Elveg et produkt som blir aktivt brukt av mange.

Mer moderne løsninger er å tilby kun endringsdata, leveranse av en komplett, landsdekkende nettverksdatabase i åpne formater, og ikke minst ruteplanlegging som en tjeneste. I dette inngår også en bedre kobling mellom gater i vegnettverket og adressepunkt fra Matrikkelen.

Vi arbeider med alle disse løsningene, og både ruteplantjenesten og databasen som brukes i den er tilgjengelige via data.norge.no (http://data.norge.no/data/statens-vegvesen/vegnettsdata-til-navigasjon). Mer moderne løsninger gjør det også enklere for tilbydere av data og tjenester å levere oppdaterte produkter til brukerne.

Utvidet nettverk

Vegnettet i NVDB omfatter alle kjørbare veger, samt skiltede gang- og sykkelveger. Tradisjonelt har bruksområdet for denne typen data vært bilnavigasjon, men vi ser i økende grad at det digitale vegnettet må ses på som en del av et større, multimodalt nettverk der både bil, buss, tog, båt og fly inngår, samt nettverk for gående og syklende. Dette ser vi blant annet gjennom arbeidet med INSPIRE Transport Networks.

Vegvesenet er en aktiv pådriver i arbeidet med norges leveranser av Inspire Transport Networks.

Vegvesenet er en aktiv pådriver i arbeidet med norges leveranser av Inspire Transport Networks.

De ulike transportformene må bindes sammen av overgangsnoder, og i tillegg er det behov for registrering av stier og snarveger der syklister og fotgjengere tar seg fram. Også traktorveger som ikke er kjørbare med vanlig bil er viktige lenker i et komplett nettverk, for eksempel for utrykningskjøretøy.

Det nye primærdatasettet FKB-TraktorvegSti er et trinn på vegen mot et mer komplett nettverk. Datasettet skal omfatte stier, gangveger, traktorveger mm. som i dag ikke inngår i NVDB. Mye av dette finnes allerede i produkter som N50, men gjennom FKB-TraktorvegSti skal dataene samles og struktureres bedre for bruk som nettverksdata.

Både nasjonalt og internasjonalt er løsninger og tilrettelagte data for navigasjon i vegnettet et stort forretningsområde. Begge de to store internasjonale leverandørene av data ble kjøpt av andre aktører i 2008: Navteq ble kjøpt av Nokia for 40 milliarder kroner, mens TeleAtlas ble kjøpt av TomTom for 23 milliarder kroner. Det er her verdt å merke seg at Nokia pekte på data til fotgjengernavigasjon som en av de store motivasjonsfaktorene for å gå inn på dette området. Parallelt med disse bygger også Google sitt eget nettverksdatasett.

Alle disse aktørene bruker store summer på å vedlikeholde sine datasett. I Norge har vi en skattkiste i form av NVDB, en løsning andre nasjoner misunner oss sterkt og som de private aktørene har stor glede av. Men vi er avhengige av at både innsamling, foredling og distribusjon av data skjer på en måte som sikrer kvalitet og oppdaterte data. Og disse prosessene skal vi forbedre videre for å kunne tilby enda bedre data og løsninger for navigasjon i et komplett, framtidsrettet nettverk.

Vegnett i NVDB api

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!

NVDB api og FME

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

Hvordan laste vegnett fra NVDB inn i QGIS med 6 linjer Python

I dag ble Kartverkets og Statens vegvesens skattekister åpnet, et frislipp mange har ventet på lenge. Vi hadde gleden av å presentere en ny prototype for dataleveranser av vegnett, hvor vegnettet kan hentes på GeoJSON-format gjennom en REST-basert webtjeneste: http://vegnett.vegdata.no/ Prototypen er lagt i graven

Kombinasjonen GeoJSON og REST kan gi mange muligheter i GIS-verktøy, spesielt de som har integrasjon mot språk som Python. Dette innlegget beskriver hvor enkelt og raskt det er å importere vegnettet inn klienten Quantum GIS (QGIS), som er basert på åpen kildekode.

APIet som tilbyr vegnett har foreløpig ikke mange paremetere, siden det kun er en prototype. En bruker har følgende valg:

  • Hent vegnettet innenfor hele Norge, innenfor et bestemt fylke, eller innenfor en bestemt kommune.
  • Hent vegnettet innenfor én eller flere vegkategorier: Europaveg (E), RIksveg (R), Fylkesveg (F), Kommunalveg (K), Privatveg (P), Skogsbilveg (S)

For å importere vegnettet inn i QGIS, er det ønskelig å lage en funksjon i Python som oppretter et nytt vektorlag. Funksjonen skal ha tre innparametere:

  1. Lokasjon
  2. Vegkategorier
  3. Lagnavn
def lag(sted, vegkategori, navn):
    api = 'http://vegnett.vegdata.no/nvdb/api/vegnett/' 
    uri = api+sted+'.json?kategori='+vegkategori

    lag = QgsVectorLayer(uri, navn, "ogr")
    QgsMapLayerRegistry.instance().addMapLayer(lag)

UTDATERT – denne vegnetts-prototypen eksisterer ikke lengre. Vegnettsendepunktet til NVDB api V1 kan brukes i stedet. Eksempel 

Merk at NVDB api’et V2 har fått nytt vegnett-endepunkt.

Ovenfor er den ferdige funksjonen, med 5 linjer Python-kode, pluss et mellomrom for å øke lesbarheten. De tre øverste linjene er selvforklarende.

Den nest nedeste linjen laster et vektorlag fra APIet, ved hjelp av OGR-biblioteket: http://www.qgis.org/en/docs/pyqgis_developer_cookbook/loadlayer.html

Den nederste linjen registrerer laget i QGIS sitt brukergrensesnitt: http://www.qgis.org/en/docs/pyqgis_developer_cookbook/canvas.html

Funksjonen kan kalles på følgende måte:

lag('17/19', 'ERF', 'Levanger ERF')

Koden ovenfor laster ned alle europa-, riks- og fylkesveger i Levanger kommune. Lokasjon angis ved hjelp av fylke- og kommunenummer. For en rask referanse, kan dere benytte samme liste som APIet prototypen benytter: http://vegnett.vegdata.no/js/lokasjon.js

Nedenfor er et utsnitt fra QGIS etter at koden ovenfor er kjørt.

vegnett-prototype

Med den grunnleggende funksjonen i boks, er det lett å utvide med mer avanserte spørringer etter data. Funksjonen nedenfor henter hele vegnettet i en bestemt fylke eller kommune, og oppretter samtidig ett lag for hver vegkategori.

def lag_kategorier(sted, navn):
    vegkategorier = ['e', 'r', 'f', 'k', 'p', 's']

    for kategori in vegkategorier:
        lag(sted, kategori, navn+' '+kategori)

 

Prototyp: Last ned vegnett fra NVDB api

Nedlastingsløsning for vegnettsdata.

Det skal være like enkelt å laste ned vegnett som alle andre NVDB data!

 

Fredag 27. september 2013 ble sentrale kartdata frigitt av Kartverket og Statens vegvesen, inkludert Norges digitale vegnett fra Nasjonal vegdatabank (NVDB). Dette betyr at produktet Elveg, som inneholder alle kjørbare veger og deres egenskaper, nå kan lastes ned kostnadsfritt. I tillegg frigjør vi — som annonsert tidligere — de samme vegnettsdataene vi bruker i vegvesenets ruteplantjeneste.

Lenke til vegnett-prototyp: http://vegnett.vegdata.no/

Vi ønsker å gjøre informasjonen fra NVDB så lett tilgjengelig som mulig. For å møte den økende etterspørselen etter våre data, vil vi utvikle en tidsriktig og fremtidsrettet webtjeneste hvor dere fritt kan velge de informasjonselementene dere er interesserte i. Det er allerede lansert et API hvor de fleste fagdata (fartsgrenser, skilt, rekkverk med mer) kan hentes, men der er foreløpig ikke indrefileten i NVDB; selve vegnettet, tilgjengeliggjort.

Vi har testet ut (geo)json i QGIS, med dynamisk nedlasting fra dette API’et. Funker helt utrolig nydelig!

“Vegnett prototype” er første steg på veien til å lage en enkel webtjeneste som levererer på vegnettet på maskinlesbare. Dette en prototype vi lanserer for å først og fremst få tilbakemeldinger på hvordan tjenesten bør utformes. Datasettet vil derfor inneholde feil og mangler, da det ikke er vårt aller nyeste datagrunnlag, og er heller ikke kvalitetssikret i like stor grad som Elveg-produktet. Datasettet vil heller ikke bli oppdatert i prototype-perioden.

Informasjon fra Nasjonal vegdatabank tilgjengeliggjøres under Norsk lisens for offentlige data. Dette betyr at Informasjonen kan, med de begrensningene som følger av lisensen, brukes til ethvert formål og i en enhver sammenheng. Informasjonen kan inneholde feil og utelatelser, og Statens vegvesen gir ingen garantier for informasjonens innhold eller aktualitet.

Ved bruk av informasjon fra Nasjonal vegdatabank, skal følgende tekst alltid oppgis: «Inneholder data under norsk lisens for offentlige data (NLOD) tilgjengeliggjort av Statens vegvesen.»