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 . 

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


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.