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.

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.

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!

Har kun halvparten av ulykkene geometri?

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?)

Cycling in Norwegian Tunnels

Where I can find the map with norway tunnels where cyclists are not allowed to travel?

We strongly encourage you also to investigate other sources of information that are more tailored to the needs of cyclists, but we will of course do what we can with the tools we have. The Norwegian Public Road Administration (NPRA) are rather proud of our efforts toward an open government / open data policy.

The rerverse question is much easier to answer: In which tunnels is it legal to bicycle?  Tunnels registered in Norwegian Road data base should have the attribute sykkelforbud (=cycle restriction), with one of the two values Either Ja ( = sorry, no biking allowed) or Nei ( = No cycling restriction). Finding those tunnels is pretty straight forward in our web application vegkart:

Map screenshot from our web application Vegkart showing cycling is allowed along this part county road 50 in Aurland

Cycling in tunnels along this part county road 50 in Aurland is allowed.

There is one little snag: A tunnel in our road database is defined as a point object. What you and I think of as a tunnel — a man-made pipe caved through rock — is called tunnelløp. We define tunnels this way because a modern tunnel can be a very complicated high-tech construction with any number of pipes.

But what about finding the tunnels I can’t ride a bike in? Is that simply the reverse, i.e. sykkelforbud = Ja. 

Sykkelforbud = Ja (sorry, no biking here)

In a perfect world it would be that simple. But there are plenty of tunnels built long before anyone in the NPRA gave any thought to the idea that someone would actually want to ride a bike through a road tunnel. It is a fairly new concept that biking should be allowed in some tunnels, but not in others. So, we have plenty of tunnels where the property sykkelforbud is not defined. Can you legally ride a bike in those tunnels? Hard to say from my position at the keyboard. But here’s a map showing all combinations:

Sykkelforbud = Har ikke verdi (Undefined)
Sykkelforbud = Ja (explisitely forbidden) 
Sykkelforbud = Nei (Cycling allowed)
Biking restriction undefined (har ikke verdi), not allowed (sykkelforbud=Ja) and allowed (sykkelforbud=nei).

Biking restriction undefined (har ikke verdi), not allowed (sykkelforbud=Ja) and allowed (sykkelforbud=nei).

Link to this vegkart-query.

And yes, you may find this map a bit messy. Please bear in mind that our web application Vegkart is not made for tourists – it is a general tool to find and show any kind of road related object, developed for and by the NPRA.

One last note: Traffic signs take precedence over our road data base, so please respect any «No cycling» — sign.

No cycling allowed.

No cycling allowed.

No cycling or walking

No cycling or walking

Hvorfor krasjer så mange i Nordmarka?

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

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

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