Hjelp – det er for mange mange rader i CSV-eksporten?

Hvorfor får du 34 rader i csv-eksporten fra et vegkart-søk med 10 vegobjekter?

Dette vegkart-søket etter trafikkmengde på E39 i Stad kommune:

Skjermdump vegkart-søk etter trafikkmengde på E39 i Stad kommune. Dette søket gir treff på 10 vegobjekter.

gir 10 vegobjekter. Men tar du ut en CSV-eksport fra dette søket får du 34 rader:

Skjermdump: CSV-eksport fra vegkartsøket med 10 objekter blir fordelt utover 34 rader.

Hvordan kan dette ha seg? Hvordan blir 10 objekter til 34 rader?

Hvis vi ser nærmere på objekt ID 1015038540 i vegkart så ser vi at her har vi tre vegreferanse-oppføringer, en for strekningsnumrene 44, 45 og 46

Skjermdump. Vegkart-visning av trafikkmengde objekt med NVDB id 1015038540. Vegsystemreferansen blir presentert over tre linjer fordelt over tre strekningsnumre: Ev39s44, Ev39s45 og Ev39s46.

I CSV-eksporten er dette blitt til 6 rader:

Skjermdump, tabellvisning av CSV-eksport for trafikkmengde-objekt med ID 1015038540. Dette ene objektet er brutt opp i seks individuelle rader i CSV-eksport tabellen.

Dette er dobbelt så mange rader som i vegkart-visningen. Grunnen er at vi tar hensyn til flere andre faktorer når vi avgjør hvor mange rader som trengs i tabellen. Det blir selvsagt ny rad når vi bytter strekning- eller delstrekningsnummer (slik som vegkart). Men vi bryter også opp i ny rad der vi krysser grensene til et kontraktsområde eller en kommune, eller der vi bytter til en ny lenkesekvens på vegnettet.

En «flat tabell» har begrensninger

Når vi lager eksport til denne typen «flate tabeller» er det to ønsker som ikke lar seg forene:

  • Vi ønsker en rad per NVDB objekt
  • Vi ønsker en intuitiv presentasjon av vegsystemreferanse (per vegnummer, strekningsnummer, delstrekningsnummer og evt sideanlegg eller kryssdel).

Vi la mest vekt på det siste ønsket, der vi bryter opp hvert objekt i så mange biter som nødvendig. Dermed blir det enklere å håndtere detaljene om vegsystemreferanse (samt også informasjon om kontraktsområder, kommuner, lenkesekvens og geometri etc)

For å imøtekomme det ønsket om en ryddig presentasjon med én rad per NVDB objekt har vi innført kolonnen «Første forekomst». Filtrerer du vekk de radene der det står tallet 0 i kolonnen «Første forekomst» så får du en rad per NVDB objekt.

Skjermdump, excel filter for kolonnen "Første forekomst" som viser hvordan du kan velge å kun ta med de radene med Første forekomst lik tallet 1.

Merk at da får du ikke den fullstendige vegreferansen, kun den delen som tilfeldigvis havnet på raden med Første forekomst = 1. For å se den fullstendige utstrekningen langs vegnettet må du også vise radene med første forekomst = 0.

Skjermdump som viser den ferdige tabellen fra CSV dump fra vegkart-søket etter trafikkmengde på Ev39 i Stad kommune, der tabellen er filtrert på dataverdien "første forekomst" = 1. Vi har en rad per NVDB objekt, totalt 10 rader. Den ufiltrerte tabellen har 34 rader.

PRO-TIPS: Åpne CSV fil med Data->importer

Ett siste tips: Ikke dobbeltklikk på den ferdige CSV-filen, eller la Excel åpne den automatisk. I stedet bør du importere til et blankt regneark. Åpne et blankt regneark, velg fanen «Data» og klikke «Fra tekst/CSV»

Skjermdump som viser hvordan du kan velge importfunksjonen "Fra tekst/CSV" via "Data" fanen i et tomt Excel-regneark.

Denne importfunksjonen er langt mer robust enn Excel sin standardrutine for å åpne CSV, som noen ganger blir forvirret av eksporten vår. I eksemplet under så fikk vi feil på rad 16, 27 og 30. Disse tilhører egentlig «geometri»-kolonnen til raden over, men Excel har ikke klart å tolke det rett.

Skjermdump som viser at Excel ikke klarer å lese CSV-eksporten korrekt. I stedet bør man velge import tekst/CSV via Data-fanen i Excel.

I tillegg til mer robust datainnlesning så får du også automatisk tilrettelegging for en del fine filterfunksjoner og tabellen blir mer lettlest.