Hvordan får jeg NVDB-data inn i kartsystemet mitt?

Publisert av

Hvordan kan jeg få NVDB-data inn i kartsystemet mitt? Enten som ferdige kartlag (f.eks. WMS), eller som redigerbare data.

Beklager – ingen WMS kartlag (foreløbig)

WMS – tjenester med de mest brukte kartlagene vil komme, vi finpusser på geoserver-oppsettet og dataflyten internt, men her er det et par snublefeller vi må fikse. Vi oppdaterer artikkelen med detaljer så snart vi har det tilgjengelig.

 

Løsning for Arc Map

For Arc Map har vi en add-in som leser data direkte fra NVDB api, hent den her.

Løsning for QGIS

Gjør Vegkart-søket ditt, klikk der det står «treff» og last ned CSV-fil. Denne kan du legge til QGIS med et par museklikk.

  1. Lag -> Legg til Lag -> Legg til skilletegn tekstlag
  2. Velg filnavn og juster et par innstillinger, ref liste og skjermdump nedenfor. QGIS husker hva du gjorde forrige gang, så du trenger stort sett kun fikle med dette én gang.
  3. Klikk «Legg til».

Innstillinger:

  • Filnavn
  • Tegnsett: latin1 (eller hvis du har norsk PC-oppsett så pleier «system» funke bra)
  • Under filformat: semikolon som separator
  • Brukerdefinerte skilletegn: » (dobbelt anførselstegn) i boksene Sitat og Avbryt
  • Geometry definition: Well known text (WKT)
  • Gemetrifelt: geometri
    • Les nederst i artikkelen om snublefeller mhp geometrityper og hva du evt oppnår med å velge kolonnen «Geometri, Punkt», «Linje» eller «Flate» når de finnes
  • Geometritype: Oppdag
  • Geometry CRS: EPSG:25833 – ETRS89 / UTM sone 33N

 

Typiske QGIS-innnstillinger for å lese inn vegkart CSV-dump

Typiske QGIS-innnstillinger for å lese inn vegkart CSV-dump

Python

 

Minst to vegvesen-kolleger har laget egne bibliotek for å søke mot NVDB api og håndtere svarene derfra. Samt litt anna snacks:

import pandas as pd
pd.DataFrame.from_csv( 'datadump-fra-vegkart.csv', encoding='latin1', sep=';')

FME

https://github.com/LtGlahn/Nvdbapi_v2_FME

Geometri er snublefelle for import av NVDB data

Alle NVDB-data er knyttet til vegnettet. Noen objekttyper – f.eks. bomstasjon, skiltplater og belysningspunkt – er knyttet til vegnettet i et punkt på vegens senterlinje. Dette sklir rett inn i alle kartsystem vi har prøvd til nå.

Andre datatyper, for eksempel fartsgrenser, er knyttet til vegnettet på en eller flere strekninger langs senterlinja. Ikke alle kartsystem er like glade for å møte en slik blanding av enkle linjer (LinesString) og grupper av linjer (MultiLineString) i samme datasett. Se definisjonen av Well Known Text, den gir en god innføring.

Hvis det er kronglete at datasettet har en blanding av enkle- og multilinjer så kan man gå rundt problemet ved å erklære at alle linjer er MultiLineString. Mange av «Multi»-gruppene vil da kun har ett eneste medlem, men det er greit.

Alternativet er å splitte datasettet to, en tabell med enkle linjer og en med multi-linjer. Mange kartsystem gjør en av delene automatisk når det trengs.

Egengeometri eller ei?

Men det meste av vegustyr blir aldri montert på noen senterlinje – det står på siden av vegen (evt over eller under). Derfor har vi innført såkalt egengeometri, det vil si koordinatene for den fysiske plasseringen. Eldre data er gjerne registrert uten egengeometri (f.eks. mye holdeplassutrustning), mens nyere vegutstyr som regel har egengeometri.

  • Egengeometri er en egenskap med ett av disse navnene:
    • Geometri, Punkt
    • Geometri, Linje
    • Geometri, Flate.
  • Eller hvorfor ikke alle 3 på en gang? Trær i NVDB har denne valgfriheten
  • Hvis du vil skille objekter med og uten egengeometri fra hverandre kan du bruke filtre som Geometri, Punkt har verdi

Selv synes vi at NVDB sin modell er genial og fleksibel, men dette skaper en del kluss for dem som skal håndtere data.

Presentasjoner fra utviklerdagen 2018

Publisert av

Alle presentasjonene fra utviklerdagen 2018 er nå tilgjengelige her.

Minner om:

 

Vegbilder

Publisert av

Personvernombud Annegret Andersen har gitt oss råd og anbefaling om hvordan vi skal håndtere vegbildene som i dag er tilgjengelige via applikasjonene NVDB123, GisLine og ViaPhoto. Vi går ikke til det drastiske skrittet å slette bildene, men iverksetter strakstiltak som i første omgang begrenser tilgangen til eksisterende bilder. I tillegg vil vi jobbe med tiltak som sørger for at vi ikke lagrer personsensitiv informasjon i bildende i framtida. Retningslinjer for tildeling av tilgang til bildene vil bli utarbeidet slik at de som har bruk for bildene i jobben sin vil få tilgang. Les videre →

Visveginfo har gamle data – hva betyr det?

Publisert av

Fiksa 30.august 2018

 

Er det viktig for meg?

Neppe, med mindre du jobber med stedfesting og lagring av nye data til NVDB, eller har et system som bruker Visveginfo direkte.

Har du et system som baserer seg på Visveginfo så er det helt klart en ulempe at du ikke har med vegnettsendringer etter juli 2018.

Vegkart er ikke berørt, heller ikke når du ber om strekninger.

Hva var problemet?

Visveginfo er et system for vegnettspørringer fra 2011. Visveginfo utfyller NVDB api’et på et veldig god måte, for eksempel med topologi- og strekningsspørringer. Men én av utfordringene er at vi har to parallelle dataflyt-løyper til NVDB api og Visveginfo:

  • Visveginfo oppdateres en gang i døgnet i en (litt gammal) løype som er til dels sårbar.
    • Vi leser transaksjonsloggen fra NVDB databasen, og det går veldig bra så lenge den har «normal» drift med mange relativt små endringer.
    • Men av og til får vi en gigantisk transaksjon der svært mange objekter i NVDB er endret samtidig.Da stopper alt opp.
    • Vi får det i gang igjen ved å dele opp en gigant-transaksjon i mindre biter, men det er plundrete og tar tid.
  • NVDB api oppdateres fortløpende. Gigant-transaksjonslogger har vært et problem her også, men dette er blitt løst.

Nå – 29. august – plundrer vi ennå med en gigantisk transaksjon fra slutten av juli. Dette blir ble løst 30. august.

Stedfesting i datafangst blir vanskelig uten Visveginfo

Datafangst er Vegvesenets nye verktøy for mottak, kvalitetskontroll og beriking av data entreprenørene sender oss om det de har bygget. Før data kan lagres i NVDB må de knyttes til riktig vegnett. Og det blir jo litt vanskelig når den nye vegen ligger i kø bak en gigantisk transaksjonslogg.

Her er f.eks en ganske fersk gangsti på Tjøme, Vestfold

Ny gangsti langs Fv390, Vestfold.

Ny gangsti langs Fv390, Vestfold.

Men datafangst viser frem vegnett fra Visveginfo, og har derfor ikke den nye gangstien som alternativ. Da er det jo vanskelig å stedfeste belysning på gangstien, der det hører hjemme:

Skjermdump datafangst-verktyøyet, der gangstien mangler. Da blir det litt vanskelig å stedfeste nye belysningspunkt på gangstien

Datafangst henter vegnett fra Visveginfo, og der er ikke gangstien kommet med ennå. Merk at gangstien er synlig som en grå strek i bakgrunnskartet, men IKKE tilgjengelig som gyldig vegnett du kan stedfeste på i Datafangst.

Hvordan sjekker jeg om mine data er berørt?

Du kan bruke denne kartløsningen. Den henter data både fra Visveginfo og NVDB api. Da ser du fort om de er enige, eller om det er avvik. Mer om dette kartet.

Skjermdump som viser kartløsning der NVDB api tilbyr gangstien som nærmeste vegnett, mens Visveginfo har kun hovedvegen

NVDB api tilbyr gangstien som nærmeste vegnett, mens Visveginfo har kun hovedvegen

Nedenfor ser du at Fv390 har fått nye meterverdier. Nvdb API gir ca 7 meter lavere tall enn Visveginfo.

Skjermbilde som viser at Visveginfo har høyere meterverdier enn NVDB api på Fv390, Vestfold

Hvor finner jeg kollektivfelt?

Publisert av

Hvordan kan jeg finne kollektivfelt eller andre typer kjørefelt i NVDB?

Informasjon om kjørefelt er i NVDB lagret på de enkelte veglenke-delene. Den som liker å programmere kan lese mer om datastrukturen her: http://api.vegdata.no/endepunkt/vegnett.html

For resten av oss er 616 Feltstrekning til stor hjelp. Inntil relativt nylig var det på denne objekttypen vi lagret oversikt over kjørefeltene. Denne blir fremdeles holdt a jour: Ved vegnettsredigering kopieres kjørefelt-informasjon fra veglenkene over på 616-objektet, mer presist som tekst i egenskapsverdien feltoversikt.

Fiffige vegkart-søk med stjernefilter

Kollektivfelt har koden «K», og vi finner dem med filteret «feltoversikt = *K*. De to stjernene (*) betyr at du kan ha hvilken som helst tekst foran og bak bokstaven K.

Søk etter kollektivfelt med objekttypen 616 feltstrekning og filteret feltoversikt = *K*

Lenke til dette vegkart-søket

Hva betyr tallene og kodene?

Feltene er numerert i stigende rekkefølge fra senterlinja og utover, oddetall til høyre og partall til venstre, sett fra starten på veglenka.

Oversikt over hvordan vi teller kjørefelt i NVDB

Felt uten bokstaver er helt vanlige kjørefelt, mens spesialfelt som sykkelfelt (S), kollektivfelt (K), ferjeoppstillingsplass (O) og svingefelt (H eller V) har egne bokstavkoder i tillegg til nummerering.

Den fulle oversikten finnes i den utmerkede håndbok v830 Nasjonalt vegreferansesystem, der figuren er hentet fra.

Hashtag # som skilletegn!

Vi bruker hashtag – # – for å skille kjørefeltene fra hverandre.

Hashtag er skilletegn mellom kjørefeltene

API LES 2018-1 og 2018-2 er nå i PROD

Publisert av

Vi har fått ut to nye leveranser på NVDB API LES hittil i 2018:

Nytt

Datoformat:

  • [NVDB-2376] – Ny reponsrevisjon med ISO-dato: Se http://api.vegdata.no/responsrevisjoner.html

Vegnett:

  • [NVDB-2512] – Foreldrelenkeid er nå tilgjengelig i API-responsen for lenker på detaljert nivå
  • [NVDB-2022] – Korrekt angivelse av typeVeg

Geometri:

  • [NVDB-2654] – Ekstra queryparameter for å droppe overflødig geometri: Vi leverer i noen tilfeller 3 geometrier for et objekt. Geometri kan ta stor plass i en respons, spesielt for lange strekningsobjekter. Vi har nå lagt til en query-parameter som gjør at man kan velge hvilke(n) geometri man vil ha. Parameteren heter inkludergeometri og kan ha fire verdier; egenskap, lokasjon, utledet, og ingen

Rettet

  • [NVDB-1658] – Områdenefiltre og avanserte filtre kan ikke kombineres. Man vil nå få en feilmelding: [{«code»: 4009,»message»: «Lokasjonsfiltre og avanserte filtre kan ikke kombineres.»,»help_url»: «http://api.vegdata.no/endepunkt/vegobjekter.html«}]
  • [NVDB-2245] – Geometri veksler mellom to og tre koordinater: I slike tilfeller fyller vi nå ut de manglende høydeverdiene med den fiktive høyden «-999999»
  • [NVDB-2284] – Filtrering på shortdatetype egenskaper gir NPE. Vi støtter nå Egenskapsdatatypen shortDateType
  • [NVDB-2297] – Forbedret håndtering av feil spørringer mot API’et.
  • [NVDB-2299] – For lang request-URI: Lange spørringer, f.eks. Spørringer med mange vegreferanse-filtre resulterte i feilmelding fra søkeindeksen. Dette skal vi nå tåle.
  • [NVDB-2321] – Feilmelding når noen prøver laste ned blobs. Vi støtter ikke nedlasting av binærobjekter fra NVDB. Før kræsjet vi, nå gir vi feilmelding.
  • [NVDB-2354] – Vi håndterer ikke StructAttributeType. Men vi kræsjer heller ikke lengre. Dokumentasjonen er oppdatert, se: http://api.vegdata.no/parameter/egenskapsfilter
  • [NVDB-2398] – Vegreferanse-endepunktet (v2) gir en lenkeposisjon. I tilfeller der angitt vegreferansefilter treffer akkurat på et skille mellom to vegreferanseobjekter, returnerer vi nå konsistent det objektet som starter på posisjonen skal returneres, i tråd med lokasjonslogikken i NVDB [fra og med, til> . Vi har også rettet et grensetilfelle der den utregnede stedfestinga kan i slike tilfeller ha flere desimaler enn stedfestinga i NVDB, og hvis man da skyter over vil man ikke finne riktig lenkekomponent (0,026341528989496002 > 0,026341528989496).
  • [NVDB-2506] – Bedre sjekk av datatype på egenskapsfiltre i spørring
  • [NVDB-2520] – Endepunktet for /vegnett/lenker/ID støtter nå parameteren SRID og gir koordinater i det angitte koordinatsystemet.
  • [NVDB-2547] – kombinasjon av != filtre fungerte feil.
  • [NVDB-2551] – Bedre håndtering av spesialtegn i spørring: Tegnene ( ) [ ] : – + ^ | & ; / ~ og mellrom har spesiell betydning i søkemaskineriet vårt. Disse tegnene vil nå bli behandlet før spørringen utføres..
  • [NVDB-2591] – Oppslag på vegref på med fylke og kommune mangler geometri og lokasjon. Dersom vegreferanse-filter er oppgitt med kommunenummer = 0 så blir det ikke filtrert på kommunenummer. Vi får da ut geomtri og lokasjon slik vi ønsker.
  • [NVDB-2627] – Bedre håndtering av ufullstendige vegreferanse-filtre
  • [NVDB-2749] – Sidepos må snus ved stedfesting mot metrering: I NVDB 123 brukes metreringsretningen for å angi hvilke side av vegen et objekt ligger på.I Vegkart brukes lenkeretningen for å angi hvilke side av vegen et objekt ligger på. I de tilfeller hvor lenkeretning og metreringsretning er forskjellig blir hvilke side av vegen objektene ligger på også forskjellig. Dette er noe de fleste ikke bør måtte forholde seg til og et problem/utfordring for vegkart. Vi prøver å nå å tolke sideposisjonen riktig.
  • [NVDB-2830] – Ikke mulig å bruke egenskapsfilter på kontraktsområde og riksvegrute:Spørringer med områdefilter og vanlig egenskapsfilter er mulig og gir responser med lokasjon. Spørringer med områdefilter og egenskapsfilter med link eller relasjon gir samme melding som nå, «Lokasjonsfiltre og avanserte filtre kan ikke kombineres.»
  • [NVDB-2688] – Vi kræsjet med NPE ved overlappsspørringer der overlapps-objekttypen ikke eksisterte.
  • [NVDB-2764] – Kartutsnitt-søk returnerer punkter utenfor angitt kartutsnitt. Dette er nå rettet for UTM33, der vi har øket presisjonen i spørringene.
  • [NVDB-2915] – Rettet en feil med vegreferanseoppslag som skyldtes tull med sorteringen av resultater fra søkeindeksen.
  • [NVDB-2952] – Kan ikke søke og filtrere på negative tall. Strengere input-kontroll førte til at vi ignorerte søk på negative tall. Det har vi nå lagt tilbake.