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

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.