Påskeegg, replikeringsfeil og datafeil i kontraktsområdene

Søkeindeksen bak vegkart og NVDB-apiet betjenes av 5 søkemotor-noder. Vi opplever fortiden problemer med at disse nodene er kommet i utakt som en følge av feil med replikeringen. Dette påvirker responsen for alle objekttypene i NVDB, spesielt dersom du søker med områdefilter. Vi må derfor gjøre om på oppsettet av disse nodene og deretter foreta en full reindeksering. Vi håper å få dette gjort så fort som overhode mulig, kanskje allerede i kveld, senest i løpet av påskeuken.

Vi har også en datafeil med kontraktsområdene våre. Det har blitt opprettet uhorvelig mange kontraktsområder i enkelte kommuner og dette har trigget en feil i API’et. Her jobber vi med å rette opp data og korrigere API’et; dette håper vi er på stell like over påske.

God påske.

Utviklerutgave av skrive-apiet tilgjengelig på docker-hub

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.

Om NVDB skrive api

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:

  • Ha bruker i Statens Vegvesen, med NVDB roller i LDAP
  • Få tildelt datarettigheter i skrive-apiet til de objekttypene, de vegkategoriene og de områdene du ønsker å skrive data for.
  • Ha kjennskap til Datakatalogen: Alle objekter som skal skrives blir strengt validert mot siste utgave av datakatalogen.
  • Ha kjennskap til Vegnettet i NVDB: Skrive-apiet krever at objekter er stedfestet på vegnettet (med angitt veglenkeid og posisjon).

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.

Om 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.

For å få tak i docker-utgaven:

  1. Installér Docker https://docs.docker.com/engine/installation/
  2. Kjør docker run -d -p 8080:8080 –name nvdb-skriveapi nvdbapnevegdata/nvdb-skriveapi
  3. For å stoppe kjør docker stop nvdb-skriveapi

Når docker kjører:

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.

Logge inn i skrive-apiet programatisk

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.

Feilsøk:

Loggene til Skrive-APIet nås ved å utføre:

docker exec -it nvdb-skriveapi bash
cd maven/apache-tomcat-8.0.32/logs

Re-indekseringens forbannelse

Oppdatering 9.3.2016: Vi har fått bekreftet at re-indekseringen var vellykket (ferdig om ettermiddagen 8.3) og at automatisk oppdatering fungerer. 

Vi var nødt til å tømme datalageret bak NVDB api’et og fylle det på ny. Mer presist måtte vi gjøre en full re-indeksering av søkeindeksen. Og det tar jo noen timer!

Vi beklager på det sterkeste de ulempene dette medførte! Både internt i Vegvesenet og eksternt har vi mange brukere som ikke får gjort det de skal når Vegkart og NVDB api’et ikke er oppdatert.

I fremtiden håper vi å kunne gjøre denne typen oppdatering i bakgrunnen, uten at dere andre merker noen ulemper. Men vi kan dessverre ikke love når det kommer på plass.

Når re-indekseringen er ferdig vil vi som vanlig skru på automatisk oppdatering, slik at endringer i NVDB automatisk speiles over i søkeindeksen – og dermed i NVDB api og vegkart.

Følg oss på twitter! https://twitter.com/nvdbapi


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.

 

Bruk Vegkart for å komme i gang med NVDB api

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!

Gjør deg kjent med data i Vegkart!

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

  • Hva finnes, og hvor finnes det data? Er det forskjell i dekning mellom f.eks. de ulike delene av landet? Eller finnes data kun på hovedvegene? Har kun et fåtall av kommunene lagt inn data på det kommunale vegnettet?
  • Bruk også datakatalogen i vegkart til å lære mer om mulige egenskaper på de objektene du ønsker.
  • De egenskapene du ønsker å bruke — finnes de? Selv om din drømmeegenskap er definert i datakatalogen betyr det ikke nødvendigvis at det finnes data lagt inn i NVDB.

Et kjapt vegkart-søk lærer deg mye om hva som finnes i NVDB, hvor det finnes og hva det kan brukes til!

Vegkart gir deg et ferdig søkeobjekt!

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:

Vegkart-søk Hvor er bomstasjonene der det ikke koster mer enn 30 kr å passere?

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.

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 gratulerer Trondheim kommune – 10.000 skilt i NVDB

Vi gratulerer Trondheim kommune med å registerere mer enn 10.000 skiltplater på det kommunale vegnettet i Nasjonal Vegdatabank!

For eksempel er det nå 1.173 skiltplater med «Parkering forbudt» (per 8.1.2015). Vegkart-søk

Vi har nå 1.173  parkering forbudt-skilt på kommunale veger i Trondheim (per 8.1.2014)

Vi har nå 1.173 parkering forbudt-skilt på kommunale veger i Trondheim (per 8.1.2014)

Hva henger under brua over E16 på Sollihøgda?

Rar dings merket "Kapsch" henger under brua over E16 på Sollihøgda.

Rar dings merket «Kapsch» henger under brua over E16 på Sollihøgda. Foto: Petter Reinholdtsen, Creative Commons.

Jeg fikk spørsmål fra Petter Reinholdtsen, en gammel venn og studiekamerat om hva i all verden den rare boksen kunne være for noe. Siden han besitter programmeringskunnskaper ut over gjennomsnittet var det litt for fristende å svare med en utfordring:

Kanskje du kan bruke NVDB api’et til å finne ut hva dette er?

Løsningen — publisert her — ble et linux shellscript som intererer over alle objekttyper og spør NVDB api’et om det finnes noe innenfor en knøttliten søkeradius (boundingbox) på Sollihøgda.

#!/bin/sh
urlmap() {
    sed \
    -e 's/  / /g'   -e 's/{/%7B/g'  \
    -e 's/}/%7D/g'  -e 's/\[/%5B/g' \
    -e 's/\]/%5D/g' -e 's/ /%20/g'  \
    -e 's/,/%2C/g'  -e 's/\"/%22/g' \
    -e 's/:/%3A/g'
}

lookup() {
    url="$1"
    curl -s -H 'Accept: application/vnd.vegvesen.nvdb-v1+xml' \
       "https://www.vegvesen.no/nvdb/api$url" | xmllint --format -
}

for id in $(seq 1 874) ; do
    search="{
  lokasjon: {
    bbox: \"10.34425,59.96386,10.34458,59.96409\",
    srid: \"WGS84\"
  },
   objektTyper: [{
     id: $id, antall: 10
   }]
}"

    query=/sok?kriterie=$(echo $search | urlmap)
    if lookup "$query" |
    grep -q '<totaltAntallReturnert>0<'
    then
    :
    else
    echo $id
    lookup "/datakatalog/objekttyper/$id" |grep '^  <navn>'
    fi
done

exit 0

Vi som er vant med å holde datakatalogen hellig gråter litt innvendig når vi ser slik «brute force» tilnærming (iterer over alle mulige ID’er mellom 0 og 874, hvorav litt over halvparten ikke eksisterer). Samtidig kan vi ikke nekte for at løsningen har en viss eleganse.

Resten er eliminasjonsmetoden og ørlite grann detektivarbeid. Reisetidsregistreringspunkt peker seg ut som den mest sannsynlige objekttypen. Per september 2014 var det 53 slike målere (58 per 4 nov-14). Litt kreativ søking gir hint om at man er på rett spor – sitat Petter Reinholdtsen

[Datakatalogdefinisjonen] nevner «AutoPASS», og hvis en slår opp oppføringen på Sollihøgda nevner den «Ciber AS» som ID for eksternt system. (Kan det være snakk om Ciber Norge AS, et selskap eid av Ciber Europe Bv?) Et nettsøk på «Ciber AS autopass» fører meg til en artikkel fra NRK Trøndelag i 2013 med tittel «Sjekk dette hvis du vil unngå kø». Artikkelen henviser til vegvesenets nettside reisetider.no som har en kartside for Østlandet som viser at det måles mellom Sandvika og Sollihøgda. Det kan dermed se ut til at jeg har funnet ut hva boksene gjør.

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.