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.

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.

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/

Krøll med vegnett i NVDB api

Dessverre har det vært mye problemer med NVDB api’et i produksjon. Stabiliteten har vært alt for dårlig. I tillegg viser det seg at vi har rot og krøll med deler av datainnholdet.

I NVDB api’et bruker vi p.t. to separate indekser.

  • Fagdata (fartsgrenser, trafikkmengde, vegreferanse, skiltplate …) Alle NVDB objekter definert i datakatalogen. Alt tyder på at delen av systemet virker som den skal.
  • Vegnettsdata: Vi har en egen indeks for vegnettsfunksjoner. Det er her vi har krøll, datacrash og avvik i for eksempel meterverdier.

Feil i meterverdier i vegkart

Vegkart gjør koordinatoppslag mot NVDB api'et. Fylke 05 blir vist som 50.

Fylke 05 blir her vist som 50. Dette er en irriterende, men ufarlig feil. Verre er det at vi finner tilfeller med feil meterverdi.

Vegnettsfunksjoner omfatter også oppslag fra koordinat til vegreferanse. Noen ganger gir dette feil meterverdi. Denne funksjonen brukes av vegkart; Hver gang du klikker i vegkart så gjøres det oppslag mot denne funksjonen. (eksempel)

Du kan altså ikke stole 100% på den meterverdien du får når du klikker i «vegkart». 

Vegkart har også feil visning av fylkesnummer lavere enn 10: For eksempel blir fylke  5 (Oppland) vist som 50, ikke 05. Akkurat denne feilen er kun irriterende, men totalt ufarlig: Data på fylkesnummer _*er*_ riktig, de blir bare vist litt dumt.

Kan jeg bruke data fra Vegkart / NVDB api?

Ja, vi er ganske trygge på at alle fagdata er korrekte.

Men ikke stol 100% på den meterverdien du får opp når du klikker i kartet.

Hva gjør vi videre?

Akkurat nå er alle fagpersoner på ferie. Vi får ikke gjort noe som helst de neste par ukene. Etter feriedvalen har feilretting høyeste prioritet.