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.

Vegkart og nvdb api blir ikke oppdatert 

Oppdatering torsdag 3.11.2016: Alle systemer går som normalt. 

Vegkart og NVDB ​api vil være tilgjengelig, men data vil være ufullstendige inntil indekseringen er fullført – sannsynligvis i løpet av dagen/ettermiddagen. Deretter bør alt fungere som vanlig…

Oppfriskningen av vegkart og lese-apiet stoppet som følge av ny datakatalogoppdatering kl0800 i dag tidlig (mandag 31.10) – denne vil tidligst komme i gang igjen i løpet av morgendagen (01.11). Feilretting pågår.

Vi har satt igang full reindeksering tirsdag ettermiddag (1.nov 2016). Alt burde fungere normalt neste arbeidsdag . 

Status NVDB og Geodata oktober 2016

Her følger en liten oppdatering fra NVDB og Geodata på tampen av oktober!

Ny versjon av Datakatalogen

datakatalog-tabellside

Det legges ut ny versjon av Datakatalogen 31/10. Samtidig blir det også ny versjon av Objektlista.

Teknologiforum Norge Digitalt og uttak av data

Teknologiforum

Jan holder 3 innlegg på Teknologiforum Norge Digitalt. Som medlem av programkomitéen synes han årets teknologiforum har mye spennende å by på.

I tillegg har Jan jobbet med å lese data fra NVDB api til diverse formål med Python og FME, kode her og her. Han anbefaler også interesserte i å titte på Knut Jetlunds arbeid med GML-skriving.

Han har brukt mye tid det siste halvåret på uttak av historiske data fra NVDB. Dette har vært fra interne systemer «på bakrommet» til blant annet forskning på vegdekke og ulykkesanalyse. Som kjent har vi ikke ennå tilgjengelig historikk i NVDB api og Vegkart. Denne typen datauttak er både kompetansebyggende og gir verdifulle erfaringer når vi får på plass historikk i våre åpne tjenester.

Studentoppgaver

18336

Trond Arve Haakonsen, sammen med Asbjørn Eilefsen, har ansvar for fire studentoppgaver hos Norges miljø- og biovitenskapelige universitet, her følger en beskrivelse av oppgavene:

 

  • Vurdere ulike målemetoder og plattformer for innsamling av georeferert 3D-punktsky (anvendelighet, fullstendighet, nøyaktighet, kostnad). Punktskyene skal benyttes for produksjon av digitale terrengmodeller.
  • Hvordan utnytte «spor og jevnhetsdata» fra SVVs bilbårne laserskannere for å registrere eller modellere vektorobjekt til NVDB og FKB?
  • Sammenligne dagens sanntidsposisjoneringstjenester: Cpos, Smartnet og Topnet. Er måleresultat uavhengig av utstyrstype og valgt nettverksløsning?
  • Hva blir behovet for nøyaktig posisjonering innenfor ITS? Designe et forsøk for å undersøkelse av nøyaktigheten til dagens bilnavigasjonsløsninger med kodebasert GPS.

GisLine Oppmålingsforretning (GOF) og digital utsendelse av brev

gof

I forbindelse med at vår seksjon v/Trond Arve Haakonsen er systemeier for GOF fikk vi oppdraget med å tilpasse GOF slik at vi kan gå over til digital utsendelse av brev. Prosjektet ledes av Siv Løes mens Øyvind Bratne er vår tekniske mann og bindeleddet mellom IKT-drift og de tekniske ressursene hos leverandøren Norkart. May Britt Hanstad er testleder og landmålerne Svein Rosland, David Hosen og Elen Smaadal er med som fagpersoner og testere.

For å muliggjøre utsendelse av digital post til personer og organisasjoner som blir berørt av oppmålingsforretninger har vi hatt behov for å tilpasse modulen oppmålingsforretning i Gisline og få denne til spille sammen med Mime 360. Mime 360 er vårt bindeledd ut mot de digitale postkassene, DigiPost, eBoks og Altinn.

Innbyggere i Norge som har opprettet digital postkasse enten hos DigiPost eller eBoks vil få sine brev sendt dit, mens alle andre som ikke har reservert seg i det offentlige Kontakt og Reservasjonsregistrert vil få sin post til Altinn meldingsboks. Når det gjelder organisasjoner så vil disse også få sin post til Altinn da Mime har ferdigstilt sin løsning.

Prosjektet er en del av digitaliseringen i offentlig sektor. I forbindelse med oppmålingsforretninger sendes det årlig ut ca 15000 brev pr år. Prosjektet Digital kommunikasjon som hovedregel har anslått at utsendelse av et digitalt brev vil koste oss 1 krone med denne løsningen, mens porto for ett brev i dag koster 11 kroner.

Den største gevinsten oppnås ved innspart arbeidstid. I dag skriver eiendomslandmålerne først ut et stort dokument som inneholder alle brev. Brevene sorteres og legges i konvolutter. Deretter må hvert enkelt brevs spesifikke vedlegg skrives ut, sorteres og legges i riktig konvolutt. Tidsbesparelsen er kostnadsberegnet til ca. kr 3 millioner per år. Utskrifter, pakking og utsendelse er likevel ikke den største tidstyven. Framtidig god integrasjon mellom GOF-MIME forventes å gi størst utbytte i form av mindre tidsforbruk til arkivering.

Prosjektet gjennomfører i disse dager systemtest, mens akseptansetest og produksjonssetting vil skje i første tertial 2017.

 

Hvorfor tar vi ned vegkart og NVDB api?

Vegkart og NVDB api var nede i helga 7-10 oktober 2016. Vi er veldig lei oss for at dette skjedde – og spesielt at det skjedde uten noen form for informasjon.

Vi var nødt til å ta vegkart og NVDB api ned for å gjøre en total re-indeksering. Dessverre klarer vi ikke gjøre re-indeksering uten ulemper for brukerne. (Vi jobber med en løsning på dette også, men det ligger lengre frem).

NVDB api’et bruker to søkeindekser:

  • En søkeindeks for fagdata (fartsgrenser, bomstasjoner og alle de andre nesten 400 objekttypene vi har definert i datakatalogen.  Denne komponenten har fungert svært bra.
  • En søkeindeks for vegnettsinformasjon. Denne ble innført våren 2016, dog med litt innkjøringsproblemer

I prinsippet enkelt: Vegnettsendringer gjør at noe må oppdateres i indeksen for vegnett. Oppdaterte fagdata gjør at indeksen for fagdata endres. Men så har vi et viktig unntak:

I indeksen for vegnett har vi også lagt inn data om vegreferanse: Vegnummer, vegkategori, meterverdi og så videre. Når Vegnettsgruppa endrer vegreferanse-informasjon så må dette også endres i vegnett-endepunktet – selv om vegreferanse strengt tatt er fagdata.

Sa noen re-klassifisering av veger? Selve vegnettet i NVDB er uendret, men viktig informasjon om vegen blir endret: Vi har fått oppdatert vegreferanse.

For eksempel at vegen endrer status fra anleggsveg (A) til Eksisterende veg (V). Eller at fylket overtar vegen (F) fra staten (E eller R). Eller at meterverdiene regnes ut på ny. Eller et nytt vegnummer.

Hver gang det skjer slike endringer blir data om selve vegreferanse-objektet oppdatert i fagdata-indeksen – men ikke i indeksen for vegnett. Det betyr at når du klikker i vegkart får du data om vegen før re-klassifisering. For å sjekke den nye klassifiseringen må du gå inn på selve vegreferanse-objektet. Ikke spesielt brukervennlig.

Eksempel på feil i vegnettsfunksjonene: Deler av Strandvegen i GJøvik er omklassifisert fra kommual veg til fylkesveg (Fv33) , men den gamle verdien (Kv 4600) henger fremdeles igjen.

Deler av Strandvegen i GJøvik er omklassifisert fra kommual veg til fylkesveg (Fv33) , men den gamle verdien (Kv 4600) hang fremdeles igjen i vegnettsfunksjonene inntil vi fikk re-indeksert.

Om du er i tvil – så har vi en kartklient du kan bruke til å sjekke om vegen er omklassifisert, eller har andre endringer.

Vi er godt i gang med å løse problemet, og vil ha en fiks klar ganske snart, men kan ikke love noe om når dette kommer i produksjon.

Dessverre må vi nok også de neste månedene ta ned NVDB api og Vegkart innimellom: Når det blir for mange re-klassifiseringer vil vi måtte ta en full re-indeksering. Det tar ca 12-18 timer, med påfølgende omstart.

Vi lover å bli bedre på å informere i forkant av slike omstarter. Ikke etterpå.

Status september 2016

Vi på NVDB og Geodata vil gjerne begynne å legge ut litt statusinformasjon for å gi innblikk i hva vi jobber med og dele noen tips når det dukker opp. Håper dere synes det er interessant å lese litt om hva vi gjør!

 

FOSS4G

http://foss4g.no/ hadde Jan Kristian Jensen gleden av å snakke om programmering mot NVDB api: Hvordan er NVDB strukturert, hvilke kodebibliotek finnes, et par av snublefellene, og lignende ting av interesse. Foss4g er en konferanse for fri og åpen programvare, med spesiell vekt på «Geo» – fagfeltet. Video finnes her, og presentasjon med klikkbare lenker til eksempler m.m. finner du via http://foss4g.no

foss4g

Ny brukerveiledning

Elin Leikvang er nyeste tilskudd på teamet til NVDB og Geodata, hun er utdannet dataingeniør, har jobba med brukervennlighet og blir nå systemeier på datafangst. I sommer har hun lagt ut en ny versjon av brukerveiledningen til Vegkart, formålet er å hjelpe de som ikke kan noe om systemene til å komme i gang med å bruke Vegkart. Ta gjerne en titt her.

brukerveiledning

 Datainnsamling med Vionice og Volvo

Elin Leikvang og Per Andersen har vært på testkjøringer fra Trondheim til Oslo og Stavern og hjem igjen for å samle inn data til et prosjekt de jobber på sammen med Tomas Levin og Ane Dalsnes Storsæter på ITS. Det går ut på å kartlegge nøyaktigheten på innlesning av skilt via Volvo sitt innebygde sensorsystem og en mobilapp laget at Finske Vionice. Ta en titt på Vionice sine sider for å lese litt mer om teknologien deres.

img_4413img_2971

img_2969 img_2992

Formålet med dette prosjektet er å se om vi kan finne mer kostnadseffektive måter å samle inn noen datatyper på, i denne omgang tester vi for skilt. Prosjektet fortsetter nå med kvalitets- og nøyaktighetsvurderinger.

Samarbeidsavtale innenfor NVDB-fagområdet mellom SVV og Nye Veier AS

b240d2a0-83f5-4e76-83ac-0ab48e2f4d22

Per Roald Andersen jobber for tiden med Nye Veier AS om en samarbeidsavtale og har skrevet litt om det her:

Det er etablert en felles arbeidsgruppe som skal utarbeide forslag til samarbeidsavtale mellom SVV og Nye veier AS på NVDB- fagområdet.

Arbeidsgruppen ledes av leder for NVDB og geodataseksjonen, Per Andersen, John Mikalsen representerer regionene i arbeidsgruppen og Jacob Trondsen fra TRAFF skal ivareta fagsiden, Espen Sveen er med som gruppas sekretær og skal føre selve avtaleutkastet i pennen.

Forslag til avtale skal være på plass innen 10.10.2016. Gruppa vil støtte seg på fagmiljøene og dra inn ekstra ressurser ved behov. Nye veier AS er representert med fire deltakere i gruppa.

Avtalen skal beskrive rutiner for samhandling mellom SVV og NV, ikke detaljer på leveranse av data.

Avtalen skal i hovedsak dekke tre områder:
  1. NVs tilgang til data fra NVDB med tilliggende fagregistre inkludert ev. programvare for effektiv tilgang til data.
  2. Rutiner, programvare mm for å etablere og oppdatere vegreferansesystemet i NVDB og ev. referansesystemer i tilliggende fagregistre, for veg NV har ansvar for.
  3. Rutiner, programvare mm for å etablere og oppdatere andre data og opplysninger i NVDB med tilliggende fagregistre om veg, vegobjekter, trafikken, miljøet, vedtak mm for veg NV har ansvar for Statens Vegvesen legger to viktige prinsipp til grunn for avtalen:
  • Leveranser fra Nye veier AS skal skje fra selskapet ikke selskapets entreprenører og konsulenter, dvs. SVV ønsker en ansvarlig i selskapet
  • SVV skal ikke utføre arbeid for selskapet. Selskapet har hele ansvaret og arbeidet med å levere de data, med den kvalitet, på det format, til den tid og på den måte vi fastsetter for det enkelte prosjekt. Forvaltning av nasjonalt vegreferanssystem skal SVV utføre.

Ansvaret knyttet til NVDB med tilliggende fagregistre vil naturlig fordele seg slik:

  • SVV har ansvar for å gi NV god tilgang til data fra NVDB med tilliggende fagregistre, samt tilrettelegge for at selskapet tidsriktig kan levere de data og andre opplysninger, på den måten, med den kvalitet og det format som SVV fastsetter for det enkelte veganlegg.
  • NV skal ved utbygging, vedlikehold og drift av det enkelte veganlegg som de har ansvar for, levere data og andre opplysninger til NVDB med tilliggende fagregistre som fastsatt av SVV. Utgangspunktet er at NV ved utbygging, vedlikehold og drift til enhver tid skal levere tilsvarende data og andre opplysninger til NVDB med tilliggende fagregistre som SVV skal levere for sammenlignbare veganlegg.

Første møte i arbeidsgruppa er gjennomført, her var temaet leveranse av vegnett og teknisk grensesnitt som tilbys fra SVV. Videre arbeidsplan er lagt opp med oppfølgingsmøte i forhold til vegnett, to møter vedr leveranse i henhold til objektlista og et avsluttende møte for å lande avtaleutkastet.

 

Kommune og regionreformen, Konsekvenser for NVDB

Vi i avdelinga jobber også med konsekvensutredning knytta til kommunereformen, her følger en status på den jobben:

Endringer i de nasjonale administrative nivåene vil få konsekvenser for NVDB, uavhengig av valgt modell for ny nummerering av fylker/ kommuner. En slik endring i de nasjonale administrative nivåene vil også berøre omkringliggende fagsystemer til NVDB, systemer som vegloggen, bru- og tunellregistre, dekkeregistre mm. Systemer som nytter vegreferansen til stedfesting av informasjon på og langs veg vil bli berørt.

Figur 1. Vegreferansens oppbygging

kommune

Det er gjennomført en miniutredning som er en beskrivelse av hvilke utfordringer en kommunereform gir for NVDB systemet. Utredningen er på et helt overordnet nivå og vil gi oss informasjon til å gå videre med saken.

Rapporten peker bl.a. på behovet for at vegreferansesystemet må løsrive seg fra den administrative inndeling i landet. Konsekvenser av dette må kartlegges i den videre utredning. Rapporten belyser utfordringene ved ulike typer sammenslåinger; Fylkessammenslåing, Kommuner som slås sammen over fylkesgrenser, Kommunesammenslåing innenfor et fylke og Kommunesammenslåing med splitting av kommune. Videre prøver rapporten å si noe om mulige tiltak på kort sikt og mulig langsiktig løsning. I mulighetsstudiene belyses konsekvenser for ER- vegene, F- vegene og KPS- vegene.

Utredningen er kun en grov analyse av konsekvenser. Den ser ikke på et ev. økonomisk omfang og konsekvenser dette vil ha på omkringliggende komponenter.

Utredningen skal ta høyde for at det kan komme ytterligere sammenslåinger i framtiden utover det som er kjent nå. Slik at løsningen som blir valgt er robust nok til å håndtere ev. framtidige endringer i kommunegrenser og regionsgrenser.

Vi tar sikte på å ha en endelig rapport klar innen utgangen av uke 37, den vil da bli tilgjengelig.

NVDB åpne vegdata utviklerkonferanse 2016

Edit 6.9.2016programmet er nå klart

Tid: Fredag 23. September kl 10-15

Sted: Clarion Hotel & Congress, Trondheim

Påmelding

Program

Vi vil i år – som i fjor – avholde en utviklerkonferanse for dere som jobber med utvikling rundt våre åpne data og apier.

Vi driver i disse dager og setter sammen programmet for dagen og ønsker oss at dere som har interesse av å komme svarer på en superkort spørreundersøkelse:

https://no.surveymonkey.com/r/VDH83P8

Det er 3 avkrysningsspørsmål og 2 kommentarfelt – vi setter stor pris på tilbakemelding! Endelig program for utviklerdagen blir sendt ut i løpet av de nærmeste ukene.

Grensesnittene utviklet i åpne vegdata prosjektet:

I 2016 har vi lansert versjon 2 av NVDB lese-api og en utviklerutgave av NVDB skrive-api. Til konferansen håper vi også å kunne presentere en første versjon av et datafangst-api.

Ressurser for utviklere

Følg oss også på twitter @nvdbapi


Kjør java-datakatalogen uten nettleser

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.

Skjermdump, javaprogram for å vise datakatalogen. Trafikkulykke.
Det gode, gamle javaprogrammet for å vise datakatalogen har MYE god funksjonalitet og mange ivrige brukere.

En del har problemer med å starte datakatalog-viseren fra denne siden:

Tabell med de ulike versjonene av datakatalogen.
De ulike datakatalog-versjonene vises ved å klikke på versjonsnummeret. I dette tilfellet er 2.06 den nyeste.

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:

  1. Nettleseren din laster ned en såkalt jnpl-fil. Dette er en tekstfil med nødvendig informasjon, først og fremst lenker til selve programmet (jar-filer).
  2. jnpl-fil åpnes i java web start. De nøvendige komponentene lastes ned.
  3. Java web start fyrer i gang selve javaprogrammet.

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.

Eksempel på feilmelding som du kan få fra sikkerhetsmekanismene på maskinen din når nettleseren prøver å kjøre .jnlp-filer "Denne filtypen kan skade datamaskinen. Ønsker du å beholde objektliste-218.jnlp likevel?"
Eksempel på feilmelding man får fordi jnlp-filene stoppes av sikkerhetsmekanismene på maskinen din.

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.

Ett-klikk start av datakatalogen

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.

Må jeg ha java?

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)

Fremtidige versjoner

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

Sjekk vegreferanser i kartet

Eksempel på feil i vegreferanseoppslag fra NVDB api'et, Risør Havn.

Dobbeltsjekk vegreferanser med to kilder til NVDB-data! Den blå linja viser avstanden fra kartklikk til vegreferansen fra NVDB api’et. Her i Risør Havn er det åpenbare feil i data fra NVDB api’et

For å bøte på problemet med feil vegreferanser i vegkart har vi laget dette kartet. Klikk i kartbildet, så hentes vegreferanse fra to uavhengige kilder:

Begge kildene har NVDB data, men sommeren 2016 er vegnettsfunksjonene i NVDB api’et ustabile.

Eksempel på feil vegreferanse i vegkart, Risør havn.

I Risør havn får du feil vegreferanse for deler av Fv416. Klikker du nær «g»‘en i Strandgata får du data for en av kommunalvegene lengre sør.

Enda et eksempel fra Risør havn. Jeg klikket litt til side for senterlinja. Blå linje viser avstand fra klikkpunkt til NVDB api, rød linje fra klikkpunkt til visveginfo-tjensten. Det er helt klart noe galt med vegnettet fra NVDB api’et i dette området, mens jeg har full tiltro til data fra Visveginfo-tjenesten.

Enda et eksempel på feil i vegreferanse-oppslag mot NVDB api.

Når du klikker skal du få data for nærmeste veg. Dette ser bra ut for visveginfo-tjenesten (rød linje), men ikke for NVDB api (blå linje).

Slik skal det se ut!

Vegreferanse-oppslag mot NVDB api og visveginfo-tjenesten gir her samme resultat.

Slik ser det ut når det er 100% samsvar i de to tjenestene! Vegreferanse-verdiene er identiske, og rød og blå linje tegnes oppå hverandre, og tilsammen blir en fiolett strek.

Kartet finner du her: http://labs.vegdata.no/vegreferanse/