Re-indeksering torsdag 9.februar 2017

EDIT fredag 10.2: Vi er tilbake i normal drift, men mangler litt driftskontrakt

Kjente feil 10.2: Fiksa

  • Mangler driftskontrakt 1103 Stavanger

torsdag 9. februar skjer det to ting som går ut over alle brukere av Vegkart og NVDB api.

  • Vi skrur av oppdatering.
    • På dagtid 9.2 vil vi ikke overføre endringer fra NVDB-databasen til  NVDB api og vegkart.
    • Husk at du kan sjekke status på dataoverføring fra NVDB med «info»-knappen i vegkart og denne funksjonen.
  • Full re-indeksering.
    • Om ettermiddagen / kvelden torsdag 9.2 kjører vi full re-indeksering
    • Først blir det et par timer uten data overhodet i NVDB api og Vegkart
    • Deretter vil objekttypene gradvis komme på plass igjen (rekkefølge etter objekttypenummer, dvs først 3 Skjerm, 5 rekkverk osv).
    • Re-indeksering burde være ferdig ca midnatt natt til fredag 10.2.
  • Normal drift fra fredag morgen
    • Fredag morgen skrur vi på oppdateringen, slik at du igjen finner de ferskeste   data i  Vegkart og NVDB api

Bakgrunnen er en (liten, rent teknisk) datakatalogendring. Dette er en nødvendig forberedelse til den datakatalogendringen som kommer i slutten av februar.

Vi beklager de ulempene dette får for våre brukere!

Status NVDB og Geodata februar 2017

Nå er det en stund siden forrige statusbrev, utsender har vært litt fraværende, men nå er vi i gang igjen!

Noe av det som skjer denne måneden:

Ny versjon av datakatalogen kommer i slutten av februar.

Kodefrys på NVDB klassisk førstkommende fredag.

Systemtest for Åpne Vegdata er underveis.

Sammen med Region midt skal vi registrere skilt i Molde med Vionice sin mobilteknologi, vi vil sammen sjekke resultatene opp mot allerede registrert data med egengeometri før Region midt bestemmer registreringsmetode for sesongens registrering av fartsgrenseskilt.

Flere og bedre bomstasjoner i NVDB

Sammen med brukerfinansiering har Jan Kristian Jensen hatt en dugnad på bomstasjoner. I flere kryss manglet vi innkreving på rampene. Dette løste vi ved å legge til nye bomstasjoner på rampene i kryss ved Lysaker, Fornebu og Ekeberg, samt på Moholt og Tonstad i Trondheim. Andre bomstasjoner har fått en finpuss på innkrevingsretning. Kvalitetssikring blir vi aldri ferdig med – finner du mangler vil vi gjerne ha beskjed! Gjerne i fiksvegdata.

Færre fylker – flere problemer?

Pga regionreformen vil vi fjerne fylke- og kommunenummer fra vegreferanseobjektet. Mange NVDB-brukere sorterer data på fylke og vegnummer. Dette er neppe et problem for brukere av NVDB api, men en del systemer i NVDB klassisk–familen kan få problemer. (Mer spesifikt: Dem som leser fylkesnummer ut fra vegreferansen). Mest sannsynlig kommer det også andre endringer: Det er for mye logikk lagt inn på vegreferanse-objektet, og nå er et bra tidspunkt å løse opp i dette. Mye er uklart, Martin Fredriksen og Jan Kristian Jensen jobber med dette.

Valg av ny kartklient avgjort

Etter en lengere evalueringsperiode av løsninger fra Geodata AS og Norkart AS har valget falt på en løsning basert på ArcGis Server levert av Geodata AS.

Bakgrunnen for prosessen og valget er at Statens vegvesen har avtale om GIS-programvare fra to leverandører. Begge leverandørene leverer en såkalt etatsrammeavtale som inneholder en portefølje med moduler slik at det ikke har vært nødvendig å gå ut med ny konkurranse for å velge løsning. Vi har altså evaluert kartklienter vi allerede har tilgang til gjennom eksisterende avtaler fra Norkart AS og Geodata AS.

Viktige momenter ved valg av løsning har vært:

  • Løsning som kjører i SVV driftsmiljø
  • Rik funksjonalitet
  • Fleksibel tilgang til tjenester fra Norge digitalt og andre integrert i klienten
  • Matrikkelen
  • Norge i bilder
  • Geonorge
  • Bruker kan selv søke opp og legge til tjenester
  • Kobling mot NVDB
  • Visning og søk på vegreferanse
  • Visning og søk på fagdata
  • Fleksibelt og enkelt administrasjonsgrensesnitt
  • Kompetanse og erfaring med ArcGis Online/Geodata Online
  • Analyse- og rapporteringsfunksjonalitet
  • Bruker kan lagre egne prosjekter og dele egne prosjekter

Konklusjonen ble at løsning levert av Geodata AS vil være den beste løsningen for Statens vegvesen.

Ferdigstillelse av NVDB AddIn for ArcGis Desktop

NVDB AddIn har i lengre til eksistert som en prototype, men vi har nå bestilt ferdigstillelse av modulen slik at vi får en stabil og robust løsning. NVDB AddIn er et lite programtillegg som henter data direkte fra NVDB og inn i ArcMap. NVDB AddIn gjør data fra NVDB lett tilgjengelig for videre bearbeiding i ArcMap. Programtillegget deles fritt internt og eksternt.

NVDB AddIn versjon 1.0 ventes å bli tilgjengelig ved utgangen av mars.

 

 

Bilder lånt fra adressa.no, radioh.no, esri

I 2016 hadde vi 423 millioner oppslag mot NVDB api

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.

statistikk-forenklet-2016

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.

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.

 

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

Bruk NVDB api i PowerBI

Med forbehold om at jeg har forstått alt rett — PowerBI er (et av) Microsofts tilbud for lettvint dataanalyse. Takket være twitterbruker @Alslinet har vi nå en vel fungerende oppskrift for å anvende data rett fra NVDB api rett inn i PowerBI.

Selve appen er ikke lenger tilgjengelig  (det hadde vi heller ikke ventet, det var en kjapp test/demo som gikk på gratiskvoten til @Alslinet).

Eksempel fra hvordan man bygger visualisering / dataanalyse med NVDB data i powerBI

Eksempel fra hvordan man bygger visualisering / dataanalyse med NVDB data i powerBI. Takk til Vegard @Alslinet .

Bruksanvisning ligger her. (Evt også som word-vedlegg her: PowerBI og NVDB). Vi har standardtrickset for å laste ned større datamengder i én klump (sette antall = f.eks. 10.000). Dette trickset vil ikke fungere like bra i kommende versjoner av NVDB api – man må gå over til å bruke pagineringsfunksjoner, og det blir jo spennende å se hvor bra dette funker mot tjenester som PowerBI. Ellers må du manuelt fortelle systemet at det skal navigere nedover i JSON-strukturen, samt hvordan du konverterer listen med egenskapsverdier til tabell. En del museklikk per verdi, men i grunnen ikke avskrekkende, er mitt inntrykk.

Tusen takk til Twitter-bruker Vegard @Alslinet for at han vil dele sine erfaringer!

Undertegnede er ikke vel bevandret i PowerBI, men for et geodata-hode er inntrykket at PowerBI har de standardmetodene du forventer for å drille ned i datasettet og se på statistikk per område, fordeling av egenskverdier med mere – koblet mot kartpresentasjon slik at du ser hvilket geografisk område du forsker på.