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.

Reindeksering – hva betyr det?

Når du ikke kan bruke Vegkart og NVDB api så er det som regel re-indeksering på gang.

Bak NVDB api’et (som igjen står bak vegkart) har vi en søkeindeks proppfull med NVDB-data. Denne holdes fersk — alle endringer i NVDB overføres til søkeindeksen fortløpende.

Noen ganger må denne søkeindeksen tømmes helt før alt fylles inn på ny. Som regel fordi vi har laget noe nytt i NVDB api, eller fordi noe har gått galt.

Ekstra dumt er det hvis re-indeksering feiler – da må vi gjøre alt på nytt igjen, med ulempe for brukerne våre. Dette skjedde f.eks desember 2016.

Hva betyr reindeksering for meg?

Når vi starter så tømmes alt av data fra indeksen, og ingenting virker i Vegkart eller NVDB api. Etter ca en time begynner det å bli data tilgjengelig. Vi begynner med de laveste objekttypenumrene (3 – skjerm, 5 – rekkverk), og jobber oss oppover. Etter ca 6-8 timer er vi ferdige.

Som hovedregel starter re-indeksering mot slutten av arbeidsdagen/tidlig ettermiddag. Og normalt går det uker eller måneder mellom hver gang vi må re-indeksere.

Kan dere ikke re-indeksere uten ulemper for brukerne?

Vi jobber med en løsning for re-indeksering uten driftsavbrudd eller andre ulemper. Denne skal på plass i løpet av 2017.

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.

 

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 . 

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

Vi re-indekserer NVDB api (16.8.2016)

Tilføyelse 17.8.2016: Re-indekseringen er ferdig, og alt ser greit ut så langt. Vi krysser fingrene for at problemene er historie… 

Vi håper inderlig at denne re-indekseringen vil fjerne de problemene vi har hatt i vegnettsfunksjonene til NVDB api’et!

Ulempen er at NVDB api er utilgjengelig i timesvis mens re-indekseringen pågår FERDIG ca 0830 17.8.2016

Vi beklager på det sterkeste ulempene dette gir.

Vi kommer tilbake med mer informasjon så snart vi har den! I mellomtiden er det bare å være tålmodig, og krysse fingrene.

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.

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/