Hvordan kan jeg få NVDB-data inn i kartsystemet mitt? Enten som ferdige kartlag (f.eks. WMS), eller som redigerbare data.
Neppe, med mindre du jobber med stedfesting og lagring av nye data til NVDB, eller har et system som bruker Visveginfo direkte.
Har du et system som baserer seg på Visveginfo så er det helt klart en ulempe at du ikke har med vegnettsendringer etter juli 2018.
Vegkart er ikke berørt, heller ikke når du ber om strekninger.
Visveginfo er et system for vegnettspørringer fra 2011. Visveginfo utfyller NVDB api’et på et veldig god måte, for eksempel med topologi- og strekningsspørringer. Men én av utfordringene er at vi har to parallelle dataflyt-løyper til NVDB api og Visveginfo:
Nå – 29. august – plundrer vi ennå med en gigantisk transaksjon fra slutten av juli. Dette blir ble løst 30. august.
Datafangst er Vegvesenets nye verktøy for mottak, kvalitetskontroll og beriking av data entreprenørene sender oss om det de har bygget. Før data kan lagres i NVDB må de knyttes til riktig vegnett. Og det blir jo litt vanskelig når den nye vegen ligger i kø bak en gigantisk transaksjonslogg.
Her er f.eks en ganske fersk gangsti på Tjøme, Vestfold
Ny gangsti langs Fv390, Vestfold.
Men datafangst viser frem vegnett fra Visveginfo, og har derfor ikke den nye gangstien som alternativ. Da er det jo vanskelig å stedfeste belysning på gangstien, der det hører hjemme:
Datafangst henter vegnett fra Visveginfo, og der er ikke gangstien kommet med ennå. Merk at gangstien er synlig som en grå strek i bakgrunnskartet, men IKKE tilgjengelig som gyldig vegnett du kan stedfeste på i Datafangst.
Du kan bruke denne kartløsningen. Den henter data både fra Visveginfo og NVDB api. Da ser du fort om de er enige, eller om det er avvik. Mer om dette kartet.
NVDB api tilbyr gangstien som nærmeste vegnett, mens Visveginfo har kun hovedvegen
Nedenfor ser du at Fv390 har fått nye meterverdier. Nvdb API gir ca 7 meter lavere tall enn Visveginfo.
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.
Statens vegvesen har i samarbeid med Geodata AS laget et programtillegg, NVDB Addin, som henter data direkte fra NVDB og inn i ArcMap. Verktøyet kommuniserer med NVDB API v2 og gjør data fra NVDB lett tilgjengelig for videre bearbeiding i ArcMap. Programtillegget deles fritt.
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
Flere har etterspurt historikk for trafikkmengde fra NVDB. Nå er det lagt ut her på spatiaLite (sqlite) og esri filgeodatabase (.gdb) – format.
ftp://vegvesen.hostedftp.com/~StatensVegvesen/opnevegdata/historiskedata
Historikk kan fremstilles på flere måter. Det vanligste er nok øyeblikksbilder, det vil si at vi gjengir situasjonen slik det var registrert på en gitt dato. I stedet har jeg valgt å legge ut FULL historikk på ALLE trafikkmengde-objekter i NVDB. Det gir et riktigere bilde av datasettet, og åpner for flere typer analyser. Denne presentasjonen er kanskje til hjelp, den viser i hvert fall noen av problemene grafisk.
Vi regner med å ha en form for historikk tilgjengelig i Vegkart og NVDB api i løpet av
20172018?– med forbehold om at andre oppgaver kan smyge seg foran i køen. Vi er heller ikke sikre på hvilke funksjoner dette vil inneholde – mest trolig en form for øyeblikksbilder, dvs at man kan søke per dato.
Trafikkmengde er ikke koblet mot vegreferanse. Hvis du er avhengig av å vite et spesielt vegnummer så må du koble dette mot vegreferanse-informasjon (som også er publisert, samme sted).
Jeg har valgt å bruke de samme egenskapsnavnene som arc map NVDB plugin – med noen tilpasninger. Så hvis du laster ned ferske data med Arc map vil du kjenne igjen – og forhåpentligvis kunne bruke datasettene litt om hverandre.
Rent praktisk betyr det at vi unngår slikt som komma, mellomrom og slasher, men ikke er redd for norske tegn. Underscore ( _ ) brukes i stedet for tegn vi ikke liker. Det betyr at ÅDT, total har blitt til ÅDT__total.
Dette med navngiving er en av grunnene til at det litt krevende å lage «datadumps» fra NVDB – i hvert fall hvis du ønsker å bli brukt i annen programvare. Internt i NVDB brukes kun numeriske ID’er for å holde styr på ting, men ÅDT__total er en smule mer brukervennlig enn 4623. Men ikke alle NVDB-navn er så rett fram!
Det er mye progamvare som furter litt over egenskapsnavn som Merknad Skade på erosjonssikring ved inn- og utløp.
Å oversette 4122 egenskapsnavn (datakatalog v2.07) til noe som er lesbart både for menneske og maskin er … dessverre ikke helt rett fram.
Disse dataene er ikke hentet direkte fra NVDB, men fra et søstersystem vi kaller TNE (Transport Network Engine). Her er NVDB-data tilrettelagt for GIS-formål – og dette innebærer en del kompromiss. Blant annet blir NVDB-data kappet i mindre biter hvis f.eks. de er lengre enn én veglenke eller ett vegreferanse-objekt. Bitene blir numerert med variabelen TNE_SEQ_NO. I tillegg har TNE sin egen forståelse av topologinivå: Vegtrasé, kjørebane og kjørefelt oversettes til tallkoder (0-3) i egenskapen TNE_topologylevel. For sporbarhet lar vi denne informasjonen følge med datasettet.
Dette er IKKE en komplett gjengivelse av navigerbart vegnett. Det er et utdrag av fagdata på øverste topologinivå. Man kan få en forståelse av vegnettets utbredelse og endring over tid, og det har sikkert mange anvendelser. Men ruteplanlegging er IKKE blant de tingene dette datasettet bør brukes til.
Vi har nettopp satt i produksjon en ny versjon 1 av NVDB api.
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.
Dette med rekkefølgen på koordinater for lengde- og breddegrad har gitt mye hodebry.
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.
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.
@VegvesenData NVDB API i PowerBI https://t.co/f4pKISVBuC
— Vegard (@Alslinet) April 8, 2016
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. 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å.
(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.
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.
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.
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.
– symbolet)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.