423 millioner oppslag er jo en del. Klientapplikasjonen «Ukjent» står for mesteparten, med vegkart som god nummer 2.
For din egen del er det lurt om du angir X-Client og X-Kontaktperson i headeren på kallet, slik som beskrevet her:
"X-Client": "NVDB Rapporter"
"X-Kontaktperson": "ola@nordmann.no"
Da får vi muligheten til å kontakte deg om noe er galt, og din applikasjon kommer med i statistikken.
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
Oppdatering 2.1.2016 23:12: Jobben er fullført og alt ser greit ut (så langt). Kontraktsområder krever dog en restart av vegkart; dette gjøres 3.1
På grunn av kommunesammenslåing må vi gjøre full re-indeksering av NVDB api’et. Dette gjøres om ettermiddagen 2. januar 2017, mot slutten av arbeidsdagen/etter arbeidstid. Følg med NVDBapi på twitter for oppdateringer.
Når re-indekseringen starter vil Vegkart og NVDB ha mangelfulle data i opptil et par timer. Dernest er en periode der de fleste objektene er på plass, men uten data om vegtilknytning (vegreferanse, veglenke), samt øvrig informasjon som avledes fra vegnettet (koordinater for senterlinje, kommune, fylke m.m.). Søk på riksvegruter, vegnummer etc vil heller ikke gi korrekte resultat.
Cirka ved midnatt natt til 3. januar regner vi med at alt er ferdig og på plass!
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.
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.
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.
Vi jobber med en løsning for re-indeksering uten driftsavbrudd eller andre ulemper. Denne skal på plass i løpet av 2017.
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.
Noen av oss har vært taleføre den senere tid.
Her er for eksempel Jan sine foredrag på Teknologiforum Norge Digitalt, og samt Martin og Jans innlegg på ITS arena.
NVDB utviklerkonferanse – om skriveAPI, datafangst og veien videre for NVDB api.
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 .
Her følger en liten oppdatering fra NVDB og Geodata på tampen av oktober!
Ny versjon av Datakatalogen
Det legges ut ny versjon av Datakatalogen 31/10. Samtidig blir det også ny versjon av Objektlista.
Teknologiforum Norge Digitalt og uttak av data
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
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:
GisLine Oppmålingsforretning (GOF) og digital utsendelse av brev
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.
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:
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.
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å.