Datafangst 2017-1 er produksjonssatt

Publisert av

Datafangstløsningen er nå oppdatert i produksjon. De viktigste nyhetene:

  1. Kontraktslista: Mer informasjon om hver kontrakt:
    1. Kontraktstatus (planlagt, utlyst, igangsatt, ferdig)
    2. Byggeleder/kontaktperson for en kontrakt.
    3. Fritekst kommentar-felt på Kontraktsnivå. Bare dataforvalter har tilgang til å kommentere, men kommentarene er synlige for alle på kontraktens “hjem”-fane.
  2. Forslag til standard milepæler / leveranseplan:
    1. Ved opprettelse av en kontrakt kommer det opp en standard liste av milepæler. Disse får automatisk påfølgende datoer fra dagens dato for å kunne beholde en sortering. Milepælene kan slettes og datoer kan endres. Man kan også legge inn egne/nye/andre milepæler for en kontrakt.
  3. Bedret kontraktsliste:
    1. Kontrakter kan nå sorteres på den nye informasjonen og på neste milepæl. Kontraktene blir rød dersom en frist/milepæl har passert og gul når den nærmer seg.
    2. Du kan nå arkivere kontrakter, da slettes de ikke, men de skjules fra kontraktslista. Et kryss i «Vis arkiverte kontrakter» får dem frem igjen. Arkiverte kontrakter vises som grå. Arkivering kan gjøres om.
    3. NB! Sletting av en kontrakt er fremdeles sletting, og kan ikke angres!
    4. Du kan nå duplisere en kontrakt. Hvis du har mange liknende, f.eks. en driftskontrakt som leveres hver måned, med samme objektliste, samme inviterte osv, så kan du velge å duplisere kontrakten, gi den nytt navn, og så skal alle andre innstillinger bli kopiert over.
    5. Kontraktslista viser nå alle dine kontrakter og du kan bla fra side til side. Tidligere ble lista kuttet på 100 kontrakter uansett hvor mange du hadde…
  4. Datafanen: Objektlisteegenskaper vs Alle egenskaper:
    1. Nå viser datafangst som standard kun objektlisteegenskaper (+ det som evt er levert ekstra). Hvis du vil se alle egenskaper, så er det nå en egen avkrysningsboks over tabellen.
  5. Datafanen: Du kan splitte skjermen begge veger og evt justere høyde / bredde på kart og tabell.
  6. Statusfanen: Slettemanus har fått egen kart- og liste-visning

Nye data om en kontrakt

Forslag til standard milepæler

Fargekoding i prosjektlista: Gult lys når en frist nærmer seg, Rødt når den er passert. Grått for arkiverte kontrakter.

Bytt mellom horisontal og vertikal inndeling av datafanen. Dra i skilleveggen for å utvide den ene eller den andre vegen.

Egen visning av slettemanus på statusfanen.

APISKRIV 2017-1 produksjonssatt

Publisert av

NVDB APISKRIV er nå oppdatert i produksjon. De viktigste endringene er angitt under.

Nytt/Forbedret
NVDB-1401 Validering av geometri – Vi sjekker nå om angitt geometri er innenfor Norge
NVDB-1650 Tillate korreksjon av stedfesting med «feil» lenkestartdato. Vi tillater nå korreksjoner der objektet flyttes til en lenke som er nyere enn objektet selv.
NVDB-1854 Presiser bruk av format i binaer-egenskaper: Vi presiserer at BLOB-format skal inneholde MIME-type. Dette er altså ikke en kodeendring.
NVDB-1881 Valideringsfeil som warning for leste egenskaper. Ved behandling av endringsett leses det inn objekter og egenskaper fra NVDB, f.eks døtre til objektet som skal endres. Tidligere fikk man valideringsfeil dersom det i NVDB fra før av var feil i de tilknyttede objektene. Dette gir nå bare en advarsel og man får lov til å lagre sine endringer likevel. Vi oppfordrer likevel klienter til å rette opp gamle feil.
Feilrettinger
NVDB-1733 For mange elementer i IN-klausul: Ved store endringsett kom vi over en begrensning i Oracle som ikke vil ha mer enn 1000 ledd i en “IN” klausul. Fra nå av leser vi bit for bit istedet for alt på en gang.
NVDB-1749 Avvisning uten angitt valideringsfeil. Innleste endringssett ble av og til avvist uten feilmelding. Det viste seg at vi under beriking hentet inn litt for mange versjoner av relaterte objekter.
NVDB-1839 Ikke global feil for manglende autorisasjon på assosiert vegobjekt: Dersom et endringssett også førte  til endringer i relaterte objekter som brukeren ikke har lov til å endre på, ble endringssettet avvist uten synlig feilmelding. I denne versjonen blir endringssettet fremdeles avvist, men brukeren får i det minste vite hvorfor.
NVDB-1857 Tom verdi for StringAttribute blir NULL i NVDB. Tomme strenger ble skrevet som “NULL” til NVDB. Fra nå av blir endringssett med tomme strenger avvist.
NVDB-1899 Assosiasjoner med content type id forsvinner. For assosiasjoner tillater vi nå at content-type-id og list-type-id brukes om hverandre. Vi oversetter automatisk til list-type-id der dette er forventet.
NVDB-1928 Sletting i skrive-API opptrer som virkelig sletting i lese-API. Skrive-apiet brukte feil transaksjonstype (2 istedet for 1) når et objekt ble satt historisk. For lese-apiet fremstod det derfor som om objektet var fjernet fra databasen.
NVDB-2029 Systemfeil på korreksjon: Geometrier kan lagres på litt ulike måter i NVDB. Skrive-apiet taklet ikke alle variantene, men vi har nå blitt mer fleksible.

Funksjonelle endringer og feilrettinger som inngår i 2017H1-leveransen av klassisk NVDB

Publisert av

Her er en oversikt over funksjonelle endringer og feilrettinger som inngår i 2017H1-leveransen av klassisk NVDB.

Ny tjenerversjon ble satt i drift torsdag 20. april. Nye Windows-klienter ble lagt ut for nedlasting 20. april og blir distribuert til brukere i SVV snart.

Når det gjelder informasjon om de funksjonelle endringene, kan dette også finnes i oppdatert brukerdokumentasjon, f.eks. i Hjelp-menyen i NVDB 123 og F1 i NVDB Studio.

NVDB123  v4.5.28

Funksjonelle endringer

1. Løsrive Datter fra Mor:
Nytt valg som gjør det mulig å frikoble datterobjekt fra mor.

2. Oppfrisk navn på kontraktsområder:
Kontraktsområder oppfriskes automatisk hvis NVDB123 startes med parameteren KONTRAKTER.

3. Dokumentasjon/bilder – angi bildefiler i importskjema, samt automatisk bildekomprimering generelt:
Bildefiler og annen dokumentasjon kan importeres ved å angi sti/filnavn i regnearket. Justering av bildestørrelsen samt konvertering til JPEG skjer automatisk, maks filstørrelse 200 kB.

4. Justeringer for Skredpunkt (kartvinduet og Excel-rapporter):
Mindre justeringer av kollonnenavn og kolonnebredder.

Feilrettinger

1. NVDB123 klarer ikke å laste kartet når installert på utviklings-VDI:
Bakgrunnskartet virker nå når NVDB123 kjøres i virtuell maskin.

2.  Feil i visning og valg av beredskapsveg:
Hurtigdata viser nå vegstatus-over også for vegreferanser med mer uvanlige verdier som f.eks. beredskapsveg.

3. Mor-datter kobling feiler ved import når mor og datter ikke har samme sideposisjon:
Forbedret sammenkobling av mor- og datterobjekt ved import.

4. Kobler til feil mor når det er to mødre med samme vegref. men forskjellig sidepos:
Forbedret sammenkobling av mor- og datterobjekt ved import.

5. Endre vegtilknytning finner tilknytningen 90 grader på musas posisjon og ikke 90 grader til valgt veg:
Funksjonen «Endre vegtilknytning» er forbedret.

6. Endre vegtilknytning fungerer ikke på strekningsobjekt med punktgeometri:
Funksjonen «Endre vegtilknytning» er forbedret.

7. Feiler i exceleksport av skiltplate i eit kontraktsområde:
Retting som gjør at visse datafeil – objekter som feilaktig indikerer at de har filvedlegg – håndteres riktig.

8. Mangelvisning viser ikke mangel på konnekteringslenke:
Konnekteringslenker med mangler ble ikke markert i mangelvisning.

9. Endre vegtilknytning endrer kvalitetsparameter:
Rettet slik at allerede satte kvalitetsparametre ikke endres når vegtilknytningen endre.

10. Nye objekt fra skjerm gir høyde, «hent fra kart» setter høyde lik 0, egengeometri blir referansegeometri:
Flere rettinger som gjelder posisjonering av objekter på kart.

11. For mange desimaler i egenskapsverdi for lengde og areal beregnet fra egengeometri:
Programmet vil heretter aldri lagre mer enn tillatt antall desimaler for beregnede egenskapsverdier.

12. Ved registrering av ny skiltplate får den automatisk egengeometri fra senter veg:
Programmet vil heretter ikke tildele egengeometri basert på vegen ved oppretting av nye objekter..

Klient-API, Studio, RapportStatus, v4.5.409

Funksjonelle endringer

1. NVDB Studio: Innkjøring forbudt som obligatorisk oppdaterbar objekttype i Vegnettsredigeringsoppdrag:
Innkjøring forbudt blir nå automatisk valgt og satt oppdaterbar når vegnettsredigeringsoppdrag.

2. NVDB RapportStatus: Nytt valg for omstart av statistikkoppgaver:
Statistikkoppgaver med status Startet har nå valget «Bestill ny statistikkgenerering»

Feilrettinger

1. Klient-API: Får problemer med overlapp på objekter:
Av ulike grunner kan ørsmå glipper og overlapp (mindre enn en millimeter) oppstå når man redigerer stedfestingen til objekter. Disse gjorde det umulig å sjekke inn endringer samtidig som de kunne være vanskelige om ikke umulige å rette med klientprogramvaren. Innsjekket vil nå rette slike små feil der det det lar seg gjøre. Det vises en melding i ServerAccess-loggen for hver slik retting.

2. Klient-API: Strekningsobjekter på veg hvor lenke og metreringsretning er forskjellig blir automatisk splittet i «uekte multippel» stedfesting  i visuel og rapport fremstilling.
Funksjonen som «trekker sammen» vegreferanser før de vises i oppdateringsdialogen inneholdt en feil som førte til at enkelte vegreferanser ikke ble vist som forventet:
Denne er nå rettet.

3. Klient-API: RoadRefTools.getKilometricExtent beregner ikke vegref dersom vegrefobjektets startdato er lik prosjektets vegnettsdato:
RoadRefTools tolket datoer som fra – til-og med mens systemet forøvrig tolker dem som fra-og-med – til, en kilde til misforståelser og feil som nå er rettet.

4. Klient-API: Vegdekkedatainnlesing fra PMS feiler, E18 i Telemark:
Kontroll av overlapp var for streng. Ordinære fagdataoppdrag har tradisjonelt hatt lov til å sjekke inn overlappende objekter gitt at objektene allerede overlappet da de ble hentet ut. Strengt tatt en datafeil, men eksisterende systemer gir ikke brukeren muligheten til å rydde opp.

5. Klient-API: Nedlasting av fileksport feiler pga. oppgradert SVV nettverksinfrastruktur
Nedlasting av SOSI-filer fra Fileksport-tjenesten fungerte ikke lenger.
Dette gjaldt både fra NVDB Studio (NvdbSession-dialogen) og fra NVDB RapportStatus.


NVDB Tjener

Feilrettinger

1. Sporstatistikkrapport: Uforståelig feilmelding:
Feilen skyldtes en bestilling med parametere som gjorde at spørringen på server ikke returnerte noe veinett. Bedre feilmelding lagt inn.

2. Gigantiske temp-filer på server blokkerer også annen aktivitet:
I visse tilfeller kunne serveren generere gigantiske temp-filer. Dersom dette nå skjer, vil serveren slette filene etter bruk og logge feilen.

URL’er til vegkart og NVDBAPI bør URL-Encodes

Publisert av

Applikasjonstjenerene som vegkart og NVDB-API LES kjører på ble oppgradert like før påske. Den nye versjonen av Tomcat avviser nå blankt URL/URI’er med tegn som ikke er ihht internett-standardene RCF-1738 og RFC-2396, og forespørsler med slike tegn kommer aldri frem til API’et.

Ulovlige tegn er blant annet:

 control = <US-ASCII coded characters 00-1F and 7F hexadecimal>
 space = <US-ASCII coded character 20 hexadecimal>
 delims = "<" | ">" | "#" | "%" | <">
 unwise = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`"
 reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | ","

(les mer her)

Dette gir problemer for klienter som bruker avanserte spørringer mot API LES v1 og v2, der vi benytter flere av disse tegnene. Senere versjonener av Tomcat har myket opp dette kravet, og vi venter nå på neste oppgradering av Tomcat. Oppgradering av Tomcat i Statens vegvesen er ventet i uke 23.

En umiddelbar løsning for klienter er å sørge for å URL-Encode sine forespørsler. Vi anbefaler i utgangspunktet alle å URL-Encode sine forespørsler. (https://www.w3schools.com/tags/ref_urlencode.asp)

Re-indeksering torsdag 9.februar 2017

Publisert av

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

Publisert av

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

Publisert av

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

FME eksempel for segmenterte data

Publisert av

Jeg har laget et FME workspace som utnytter muligheten til å få «delt opp» lange objekter i kortere segmenter. Hvert segment har unike vegreferanseverdier og veglenkeposisjoner. (I tillegg unngår man alle «multilinestring» – geometrier).

Trikset er nøkkeordet inkluder=vegsegmenter (evt inkluder=alle). Slik:

https://www.vegvesen.no/nvdb/api/v2/vegobjekter/616/91452898.xml?inkluder=vegsegmenter

Med NVDB api V2 kan man velge å få lange objekter delt opp i segmenter med unike vegreferanseverdier og veglenkeposisjoner

Med NVDB api V2 kan man velge å få lange objekter delt opp i segmenter med unike vegreferanseverdier og veglenkeposisjoner. Dokumentasjon

Det vil si at i stedet for:

  • en geometri for hele objektet
  • en liste med vegreferanser
  • en annen liste med veglenker
  • og plunder med å koble en veglenke-bit til riktig vegreferanse + riktig bit av geometri

Så får vi

  • Ett eller flere segmenter
  • Hvert segment har sin egen «bit» av objektet med
    • En enkel vegreferanseverd  (med unike  vegnummer hp, frameter og tilmeter)
    • En bit av en enkelt veglenke (ID, fraposisjon, tilposisjon)
    • Geometrien som hører til.

https://github.com/LtGlahn/Nvdbapi_v2_FME#nvdbapi_v2_bruksklassefmw

Re-indeksering 2.januar 2017

Publisert av

Oppdatering 2.1.2016 23:12: Jobben er fullført og alt ser greit ut (så langt). Kontraktsområder krever dog en restart av vegkart; dette gjøres 3.1 

På grunn av kommunesammenslåing må vi gjøre full re-indeksering av NVDB api’et. Dette gjøres om ettermiddagen 2. januar 2017, mot slutten av arbeidsdagen/etter arbeidstid.  Følg med NVDBapi på twitter for oppdateringer.

Når re-indekseringen starter vil Vegkart og NVDB ha mangelfulle data i opptil et par timer. Dernest er en periode der de fleste objektene er på plass, men uten data om vegtilknytning (vegreferanse, veglenke), samt øvrig informasjon som avledes fra vegnettet (koordinater for senterlinje, kommune, fylke m.m.). Søk på riksvegruter, vegnummer etc vil heller ikke gi korrekte resultat.

Cirka ved midnatt natt til 3. januar regner vi med at alt er ferdig og på plass!

Historiske data, trafikkmengde

Publisert av

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.