Vegvesenet legger om vegreferansesystemet i Nasjonal Vegdatabank, og mange lurer på hva det betyr. Vi har prøvd å oppsummere de viktigste endringene her. For mer detaljer se håndbok v830 Nasjonalt vegreferansesystem.
Som hjelp i overgangen har vi laget en kartløsning som viser både gammel og ny vegreferanse for et punkt på vegnettet. Du kan bruke tekstfeltet til å søke på både gammelt og nytt, eller klikke i kartet.
Kartløsningen finner du her
Hvordan kan jeg få NVDB-data inn i kartsystemet mitt? Enten som ferdige kartlag (f.eks. WMS), eller som redigerbare data.
Kartverket har endret sine tjenester som har fått konsekvenser for NVDB123 funksjonalitet.
NVDB har besluttet at vi ikke ønsker å benytte midler på å reetablere denne funksjonen i NVDB123, da det er en programvare som skal fases ut. Det finnes andre tjenester som kan gjøre eiendomssøk som Seeiendom og VisVeg, alternativt finnes det også i GisLine.
Hvordan kan jeg finne kollektivfelt eller andre typer kjørefelt i NVDB?
Informasjon om kjørefelt er i NVDB lagret på de enkelte veglenke-delene. Den som liker å programmere kan lese mer om datastrukturen her: http://api.vegdata.no/endepunkt/vegnett.html
For resten av oss er 616 Feltstrekning til stor hjelp. Inntil relativt nylig var det på denne objekttypen vi lagret oversikt over kjørefeltene. Denne blir fremdeles holdt a jour: Ved vegnettsredigering kopieres kjørefelt-informasjon fra veglenkene over på 616-objektet, mer presist som tekst i egenskapsverdien feltoversikt.
Kollektivfelt har koden «K», og vi finner dem med filteret «feltoversikt = *K*. De to stjernene (*) betyr at du kan ha hvilken som helst tekst foran og bak bokstaven K.
Lenke til dette vegkart-søket
Feltene er numerert i stigende rekkefølge fra senterlinja og utover, oddetall til høyre og partall til venstre, sett fra starten på veglenka.
Felt uten bokstaver er helt vanlige kjørefelt, mens spesialfelt som sykkelfelt (S), kollektivfelt (K), ferjeoppstillingsplass (O) og svingefelt (H eller V) har egne bokstavkoder i tillegg til nummerering.
Den fulle oversikten finnes i den utmerkede håndbok v830 Nasjonalt vegreferansesystem, der figuren er hentet fra.
Vi bruker hashtag – # – for å skille kjørefeltene fra hverandre.
Dette gjelder alle objekter med egenskapstypen dato!
Vi har enkelte feil med filtrering av egenskaper i vegkart. Spesielt har vi en feil med filtrering på alle datoegenskaper i siste versjon av vegkart. Feilen skal bli rettet så snart som mulig.
Jeg har laget et FME workspace som utnytter muligheten til å få «delt opp» lange objekter i kortere segmenter. Hvert segment har unike vegreferanseverdier og veglenkeposisjoner. (I tillegg unngår man alle «multilinestring» – geometrier).
Trikset er nøkkeordet inkluder=vegsegmenter (evt inkluder=alle). Slik:
https://www.vegvesen.no/nvdb/api/v2/vegobjekter/616/91452898.xml?inkluder=vegsegmenter
Med NVDB api V2 kan man velge å få lange objekter delt opp i segmenter med unike vegreferanseverdier og veglenkeposisjoner. Dokumentasjon
Så får vi
https://github.com/LtGlahn/Nvdbapi_v2_FME#nvdbapi_v2_bruksklassefmw
Den mest komplette visningen av NVDB datakatalog er et javaprogram med MYE raffinert funksjonalitet: Fargekoder for påkrevde egenskaper, søkefunksjon m.m. Programmet har eksistert en del år, og har mange ivrige og dedikerte brukere.
En del har problemer med å starte datakatalog-viseren fra denne siden:
Siste gyldige versjon av datakatalogen vises ved å klikke på det høyeste versjonsnummeret (2.05, 2.06 og så videre). Da skal følgende skje:
På mange PC’er funker ikke lenger dette oppsettet: Nettleseren er ikke satt opp til å fyre i gang java web start, eller det er deaktivert av sikkerhetsgrunner, eller tusen andre årsaker. Å finne ut av dette kan være veldig pirkete, og kanskje har man ikke rettigheter til å gjøre noe med det.
Da er det langt lettere å fyre i gang java web start med et vanlig kommanduvindu (cmd.exe, ledetekst). Dette er hele kommandoen for å starte versjon 2.09 av datakatalogviseren:
javaws http://tfprod1.sintef.no/datakatalog/dakat-209.jnlp
Resten tar automatikken bak java web start seg av.
Får du denne feilmeldingen:
javaws gjenkjennes ikke som en intern eller ekstern kommando,
kjørbart program eller satsvis fil.
Så har du ikke java installert, eller du mangler java web start – komponenten. Java får du her.
Skriv kommandoen over inn i en tekstfil, lagre den med navnet dakat-209.bat, og du har en kjørbar fil du kan klikke på.
Her er en zip-fil med en slik bat-fil: datakatalog-216 Last ned, pakk ut. Denne versjonen er også sukret med et par ekstra kommentarer, pluss at vinduet holdes åpent i 15 sekunder, slik at du ser eventuelle feilmeldinger.
Dernest har vi de vanlige standardtricksene for å få noe lettvint å klikke på: Lagre .bat-fila på skrivebordet, eller lag en snarvei til skrivebord, menylinje eller et annet sted der det er lettvint for deg.
Mange lever veldig godt med de andre visningene vi har av datakatalogen:
Men det er ikke alle behov som dekkes via disse løsningene. Dette Java-programmet er fremdeles den mest komplette visningen av datakatalogen, og har mange ivrige og kyndige brukere. (Versjon 3 av NVDB api vil tilby alle detaljene, men det gjenstår å bygge gode, lesbare visninger av denne informasjonen)
I fremtiden vil nok oppsettet rundt jpnl-filene bli endret; etter hvert vil disse bli flyttet fra server hos sintef til en katalog på www.vegvesen.no. Den offisielle visningen av datakatalogen, inklusive tabellen med lenke til de ulike jpnl-filene, vil du alltid kunne finne her: http://www.vegvesen.no/fag/Teknologi/Nasjonal+vegdatabank/Datakatalogen
Vi har nå gleden av å tilby en utviklerutgave av NVDB Skrive-API. Denne er tilgjengelig via docker-hub. Utviklere som ønsker å skrive data til NVDB kan dermed få kjøre en virtuell utgave av skrive-apiet på sin maskin.
Skrive-apiet er et asynkront REST-API som tar imot Endringssett på vårt eget vegobjekt-format. Skrive-apiet er tett knyttet opp mot NVDB og Datakatalogen. For å kunne bruke Skrive-API’et i produksjon, må du:
En oversikt over NVDB API’ene, med tilhørende kode-eksempler er tilgjengelig her: https://github.com/nvdb-vegdata/nvdb-utviklerkonferanse-2015 Dokumentasjonen til skrive-apiet pakkes og distribueres sammen med applikasjonen og er inkludert i utviklerutgaven.
Denne utviklerutgaven mocker all Statens vegvesen infrastruktur, inkludert NVDB databasen, men lar deg få lov til å utforske kommunikasjonen med API’et og validere dine data. Denne varianten har ingen vegdata og skriver heller ingen data til NVDB. Det er altså bare for å kunne utvikle mot APIet. Den inneholder imidlertid siste versjon av datakatalogen og kan validere innsendte data mot denne.
Docker-utgaven oppdateres når vi oppdaterer skrive-apiet i akseptansetestmiljøet, den vil altså følge neste produksjonskandiat av apiet. Datakatalogen oppdateres fortløpende.
Om alt har gått bra er Skrive-apiet nå tilgjengelig på http://localhost:8080/ på en Linux-maskin. For Windows og Mac kjører docker daemon i en Linux VM og localhost må erstattes med korrekt IP-adresse. For å finne denne åpne et command prompt/terminal og kjør kommando docker-machine ip.
Når man åpner denne siden i nettleseren vises en side der man kan velge innlogging. Dette er ikke knyttet til reelle brukere, men dummybrukere som kun lever i SDKen. Når bruker er valgt vil man bli sendt til /nvdb/apiskriv. Her ligger lenke til dokumentasjonen av APIet, og en testklient som kalles Generator.
Generator-klienten viser eksempler på requester som sendes til APIet, og forventet respons fra APIet.
For å opprette en sesjon programmatisk kan du POSTe ønsket user-id til /login (eks: user-id=toillbaill). Da blir en serversesjon opprettet. For å bruke denne sesjonen må du bruke JSESSIONID-cookien som returneres ved login.
Loggene til Skrive-APIet nås ved å utføre:
docker exec -it nvdb-skriveapi bash
cd maven/apache-tomcat-8.0.32/logs
En godt skjult hemmelighet er hvordan webapplikasjonen vegkart gjør livet enklere for deg som skal i gang med å høste ferske NVDB data direkte fra NVDB api. Vegkart gjør at du kommer i gang fortere, enklere og med langt mindre plunder!
Dette burde være opplagt, men det er mange som overser nytten av å gjøre seg kjent med datasettet, både før man programmerer, og underveis i prosessen. Mange tabber og mye knot hadde vært unngått med å bare grave litt rundt og få litt føling med datasettet
Et kjapt vegkart-søk lærer deg mye om hva som finnes i NVDB, hvor det finnes og hva det kan brukes til!
NVDB api’et søkefunksjon er et kraftfullt verktøy, men kan være litt plundrete å komme i gang med.
Nå er det vesentlig enklere enn før – ny oppskrift her!
Oppskriften nedenfor ble utdatert i vegkart-versjon lansert oktober-2015 – men vi har erstattet den med en ny og vesentlig enklere metode.
Bak stien https://www.vegvesen.no/nvdb/api/sok? skal man føye til nøkkelordet og verdien kriterie={søkeobjekt}. Vi synes selvsagt vi har vært grasat flinke til å skrive dokumentasjon og veiledning med flere eksempler på hvordan man bygger opp et søkeobjekt — men innser at mange plundrer med dette.
Vegkart er redningen — i stien til ditt favorittsøk i Vegkart er det nemlig gjemt et søkeobjekt!
Ved å kopiere søkeobjekt fra nettleserens adressefelt kan datautforsking i Vegkart anvendes direkte som ditt første søkeeksempel mot NVDB api. La oss si at du søker etter bomstasjoner med takst under 30 kroner i et spesielt vakkert geografisk område:
Hvor er bomstasjonene der det ikke koster mer enn 30 kr å passere?
Lenken til dette vegkart-søket er såkalt URL encodet, det vil si at spesialtegn som krøllparanteres er erstattet med prosentkoder. Mange teksteditorer kan dekode dette direkte, eller man kan finne online URL dekodere på nett. For eksempel denne.
meyerweb URL encoder/decoder. Fiffig online verktøy for å oversette prosentkode-grøt til lesbar tekst. Merk disclaimeren!
Når jeg setter inn et par linjeskift og mellomrom så blir det jo bortimot lettlest:
https://www.vegvesen.no/vegkart/vegkart/#!/
kartlag:geodata/
vegreferanse:260452.12090424:6556932.0971975/
sok:{
"lokasjon": {
"bbox": "262973,7033178,287844,7046873"
},
"objektTyper": [{
"id": 45,
"antall": "15000",
"filter": [{
"type": "Takst liten bil",
"operator": "<=",
"verdi": ["30"]
}]
}]
}
Den våkne leser har selvsagt for lengst oppdaget at alt bak sok: er det JSON søkeobjektet som vi har beskrevet i dokumentasjonen. Alt som gjenstår er å føye til teksten
{«lokasjon»:{«bbox»:»262973,7033178,287844,7046873″},»objektTyper»:[{«id»:45,»antall»:»15000″,»filter»:[{«type»:»Takst liten bil»,»operator»:»<=»,»verdi»:[«30»]}]}]}
bak lenken https://www.vegvesen.no/nvdb/api/sok?kriterie=
Som da selvsagt blir https://www.vegvesen.no/nvdb/api/sok?kriterie={«lokasjon»:{«bbox»:»262973,7033178,287844,7046873″},»objektTyper»:[{«id»:45,»antall»:»15000″,»filter»:[{«type»:»Takst liten bil»,»operator»:»<=»,»verdi»:[«30»]}]}]} Lenken er klikkbar, men ettersom du da gjør en spørring uten å angi riktig media-Type så er du ikke garantert at resultatet kan vises i din nettleser (ms-ie pleier spørre deg hva du vil gjøre med den json-fila du nettopp fikk, mens Google chrome pleier laste ned og vise XML formattert i nettleser).
Avhengig av klienten du bruker og nettverket ditt kan det hende du må URL encode denne lenken før den brukes — gjør gjerne det, for sikkerhets skyld!
I tillegg til å formattere spørring korrekt skal klientene oppgi ønsket Media-type, det vil si en såkalt http-header der du ber om nvdbdata som enten JSON eller XML. Se dokumentasjonen.
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).
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.
Det er ikke alle veglenker som har trafikkmengde. Ett eksempel er dette krysset ved Lysaker:
Grønne prikker er bomstasjoner, blå linjer er trafikkmengde. Vi mangler trafikkmengdedata for Strandveien og forbindelsen E18-Strandveien.
Manglende data er kodet som «-9999».
På 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.