Hvordan får jeg NVDB-data inn i kartsystemet mitt?

Dette innlegget er flyttet under «Ofte stilte spørsmål» https://www.vegdata.no/ofte-stilte-sporsmal/hvordan-far-jeg-nvdb-data-inn-i-kartsystemet-mitt/

 

Hvordan kan jeg få NVDB-data inn i kartsystemet mitt? Enten som ferdige kartlag (f.eks. WMS), eller som redigerbare data.

https://www.vegdata.no/ofte-stilte-sporsmal/hvordan-far-jeg-nvdb-data-inn-i-kartsystemet-mitt/

Visveginfo har gamle data – hva betyr det?

Fiksa 30.august 2018

 

Er det viktig for meg?

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.

Hva var problemet?

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:

  • Visveginfo oppdateres en gang i døgnet i en (litt gammal) løype som er til dels sårbar.
    • Vi leser transaksjonsloggen fra NVDB databasen, og det går veldig bra så lenge den har «normal» drift med mange relativt små endringer.
    • Men av og til får vi en gigantisk transaksjon der svært mange objekter i NVDB er endret samtidig.Da stopper alt opp.
    • Vi får det i gang igjen ved å dele opp en gigant-transaksjon i mindre biter, men det er plundrete og tar tid.
  • NVDB api oppdateres fortløpende. Gigant-transaksjonslogger har vært et problem her også, men dette er blitt løst.

Nå – 29. august – plundrer vi ennå med en gigantisk transaksjon fra slutten av juli. Dette blir ble løst 30. august.

Stedfesting i datafangst blir vanskelig uten Visveginfo

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.

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:

Skjermdump datafangst-verktyøyet, der gangstien mangler. Da blir det litt vanskelig å stedfeste nye belysningspunkt på gangstien

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.

Hvordan sjekker jeg om mine data er berørt?

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.

Skjermdump som viser kartløsning der NVDB api tilbyr gangstien som nærmeste vegnett, mens Visveginfo har kun hovedvegen

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.

Skjermbilde som viser at Visveginfo har høyere meterverdier enn NVDB api på Fv390, Vestfold

Eiendomssøk – alternativer til søk i NVDB123

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.

FME eksempel for segmenterte data

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

Med NVDB api V2 kan man velge å få lange objekter delt opp i segmenter med unike vegreferanseverdier og veglenkeposisjoner. Dokumentasjon

Det vil si at i stedet for:

  • en geometri for hele objektet
  • en liste med vegreferanser
  • en annen liste med veglenker
  • og plunder med å koble en veglenke-bit til riktig vegreferanse + riktig bit av geometri

Så får vi

  • Ett eller flere segmenter
  • Hvert segment har sin egen «bit» av objektet med
    • En enkel vegreferanseverd  (med unike  vegnummer hp, frameter og tilmeter)
    • En bit av en enkelt veglenke (ID, fraposisjon, tilposisjon)
    • Geometrien som hører til.

https://github.com/LtGlahn/Nvdbapi_v2_FME#nvdbapi_v2_bruksklassefmw

Historiske data, trafikkmengde

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 2017 2018?– 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).

Egenskapsnavn og verdier

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.

Mer teknisk

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.

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