Søk etter historiske data

Det vi trenger er en oversikt for hva som er nytt per år. Altså hvis en veg får flere gatelys, fortau osv.

Dette er et behov som mange vegeiere og -driftspersonale har. Akkurat denne gangen kom spørsmålet fra Trondheim kommune, men det samme behovet har fylkeskommunene, entreprenører, Nye Veier A/S og Statens Vegvesen.

Vår anbefaling: Ta differansen mellom to datasett for ulike tidspunkt

NVDB api LES støtter datauttak på angitt tidspunkt (dato), med et par forbehold om at det ikke har vært gjort endringer på områdegrenser fra det første tidspunktet til i dag. Her er status på historisk søk i ulike verktøy per oktober-2019:

Vi har noen forbehold! Hvis det har vært gjort justeringer på kontraktsområder og/eller vegnett kan du få litt … lite intuitive resultater, se under. I tillegg får du litt merarbeid om du ønsker å sammenligne data før og etter en kommunesammenslåing.

NVDB bruker kun de nyeste kommunegrensene!

I NVDB bruker vi kun ferske data for fylker og kommuner – med tilbakevirkende kraft. Så i 2021 finner du for eksempel ingen spor etter gamle Klæbu kommune.

Dette betyr at når du søker etter belysningspunkt i Trondheim for en tidligere dato, for eksempel 1. februar 2017, så får du treff på dagens Trondheim kommune. Mer presist 10625 objekter, hvorav 927 er i gamle Klæbu kommune.

Skjermdump av kart som viser hvordan et søk etter belysningspunkt i Trondheim kommune per 2017 gir 927 treff i gamle Klæbu kommune.
Selv om Trondheim og Klæbu først slo seg sammen i 2020 så gir søket etter belysningspunkt per 2017 deg 927 treff i gamle Klæbu kommune,

Selve søket mot NVDB api ser slik ut:

https://nvdbapiles-v3.atlas.vegvesen.no/vegobjekter/87?kommune=5001&tidspunkt=2019-02-01&inkluder=alle

Men hva med endret – funksjonen i NVDB api? Hvorfor ikke bruke den?

NVDB api LES tilbyr parameteren endret_etter, og den har sin anvendelse – men for akkurat dette behovet blir det for mange snublefeller. Resultatene fra denne spørringen:

https://nvdbapiles-v3.atlas.vegvesen.no/vegobjekter/87?kommune=5001&endret_etter=2021-09-22T00:00:00 

må suppleres med en hel del datamassasje: Du må skille endret fra nye objekter, evt om det er nye versjoner av gamle objekt – og du må sjekke om noen objekter kan være slettet. Etter vårt syn er det bedre å ta differansen mellom to ulike datoer.

Historiske data per Kontraktsområde – brukes på egen risiko

Hvis du henter ut historiske data for et kontraktsområde og enten vegnettet eller kontraktsområdet (eller begge deler!) har vært endret så må vi ta forbehold om at du kan få færre vegobjekter enn det riktige.

Hvis du vet at vegnettet og ditt kontraktsområde har ligget i ro i tiden mellom i dag og bakover til det eldste tidspunkt du trenger data for – så kan du helt fint ta ut historiske data på dette kontraktsområdet.

Forklaringen er komplisert: Når kontraktsomrdet skal brukes som søkefilter i NVDB api les så klarer vi ikke gjenskape området slik det så ut før endringen, men bruker området slik det ser ut i dag – også for historiske søk.

Hvis en bit av vegnettet var i k.området i 2019, men ble satt historisk i 2020 – så vil du ikke klare finne den når du søker på k.området i dag med tidspunkt=2019.

Tilsvarende hvis k.området har vært justert i 2020: Du klarer ikke få frem riktige 2019-data ved å bruke k.området som søkefilter.

Det finnes krokveier om dette problemet, men det er komplekst (hent ut historisk 538-objekt per tidspunkt, finn dette objektet stedfesting og hent ut vegobjekter som hadde overlappende stedfesting på det tidspunktet.) Vi ønsker å tilby ferdige rapporter basert på denne logikken, men det ligger noe fram i tid.

Hvor mangler vi kontraktsområde?

Fra våre venner hos fylkeskommunen fikk vi denne utfordringen:

Det fylkeskommunen ønsker, er å finne ut om det er noen deler av fylkesvegnettet som ikke har knyttet et kontraktsområde til seg. Slik det er i dag, må man sammenligne to rapporter og finne forskjellen

Dette er et flott eksempel på noe som ikke er ferdig støttet i våre produksjons- og rapporteringsystemer, men som fint lar seg løse med ørlite grann koding, for eksempel i FME eller python.

Kontraktsområder er såpass viktige at vi i NVDB api segmenterer alle andre data med informasjon hentet fra objekttype 580 kontraktsområde. Dermed kan du bruke navnet på kontraktsområde som søkefilter i Vegkart og NVDB api. I vegkart-veiledningen har vi et eksempel på hvordan du kan vise vegnettet for et kontraktsområde i Vegkart.

Skjermdump som viser vegkart-søk etter utstrekningen til kontraktsområde 1202 Stor-Bergen 2015-2020

Men hvordan finner vi det vegnettet som mangler kontraktsområde?

Ta en litt grundigere titt på en bit av segmentert vegnett: https://nvdbapiles-v3.atlas.vegvesen.no/vegnett/veglenkesekvenser/segmentert/804767 . På JSON-format ser det noenlunde slik ut (forkortet for lesbarhet):

{
  "href": "https://nvdbapiles-v3.atlas.vegvesen.no/vegnett/veglenkesekvenser/segmentert/804767",

  8< --- forkortet for lesbarhet 
  
  "kontraktsområder": [
    {
      "id": 1013305686,
      "nummer": 9304,
      "navn": "9304 Bergen 2021-2026"
    },
    {
      "id": 1010943925,
      "nummer": 1202,
      "navn": "1202 Stor-Bergen 2020-2021"
    }
  ]
  
  8< ---- forkortet for lesbarhet 
}

For hvert eneste vegsegment har vi altså en liste med de kontraktsområdene som gjelder for dette vegsegmentet. Hvis det ikke er registrert noe kontraktsområde for et segment så er denne listen enten tom (for JSON-formatet) eller mangler (XML-formatet). For eksempel https://nvdbapiles-v3.atlas.vegvesen.no/vegnett/veglenkesekvenser/segmentert/2720672

{
  "href": "https://nvdbapiles-v3.atlas.vegvesen.no/vegnett/veglenkesekvenser/segmentert/2720672",
  
  8< --- forkortet for lesbarhet 
  
  "kontraktsområder": [],
  
  8< --- forkortet for lesbarhet 

}

Løsningen for å finne veger uten kontraktsområde blir da å lage litt kode som henter data fra NVDB api:

Har du kodeeksempler?

Klart det – her er et enkelt python kodeeksempel

Et mer komplett python-kodeeksemplet gjør bruk av Pandas Dataframes og Geopandas Geodataframes, samt mitt eget python-bibliotek for å lese data fra NVDB api. Installasjon av disse komponentene kan gi høy brukerterskel for uøvde brukere.

Vi kan helt sikkert lage et FME-kodeeksempel hvis det er interessant.

Hvordan vise skjermede data

Visning av skjerma data i Vegkart er det mange som etterlyser, men dette ligger nok et stykke frem i tid. Derfor må vi utforske andre løsninger.

Suverent enklest: Bruk QGIS

Innstaller QGIS, og følg oppskriften her for å installere pythonkode for å lese data fra NVDB via pythonkonsollet i QGIS. Deretter er det kun et par linjer for f.eks. å lese ut Vegros-data for Innlandet kommune

vegros=nvdbFagdata(895)
vegros.filter( { 'fylke' : 34, 'vegsystemreferanse' : 'Fv' } )
vegros.forbindelse.login( username='jajens', miljo='prodles', pw='***' )
nvdbsok2qgis( vegros) 
Skjermdump fra QGIS som viser hvordan du leser inn data fra NVDB api LES med et par kjappe kommandoer i python-konsollet
Skjermdump fra QGIS, 895 Vegros lest inn til QGIS.

Når data er inne i QGIS kan man lagre til populære og moderne kartformater, eller eksportere til for eksempel Excel.

Alternativ løsning: Python, FME eller din egen løsning

De samme python-funksjonene som QGIS bruker er selvsagt tilgjengelig for en python-installasjon som står alene. (Vår anbefaling: Installer python distribusjon fra anaconda ). Vår anbefalte arbeidsflyt er å lese data inn i Pandas Dataframe, og eventuelt gjøre om denne til en GeoDataFrame. Derfra har du mange eksportmuligheter. I tillegg er (geo)dataframes i seg selv veldig kraftige analyseverktøy.

Akkurat i dag (14.04.2021) har vi ingen ferdige FME-workspace der påloggingsritualene er implementert, men det vil være en smal sak å implementere.

De samme påloggingsritualene kan du som utvikler også implementere i ditt favoritt programmeringsspråk. Enten for å lage din egen eksportrutine, eller for integrasjon i ditt favorittsystem.

Betingelser – hvilke rettigheter må man ha?

Tilgang til skjerma data i NVDB reguleres to – 2 – steder. (Jada, det er ett for mye, og vi jobber med det):

  • Du må ha definert riktige roller og tilganger i NVDB databasen
  • NVDB api LES har et eget system for hvilke skjerma data som blir tilgjengelig når du logger inn.

Rettighetene disse to stedene (NVDB databasen og i NVDB api LES) må selvsagt stemme overens.

Utfasing av gamle NVDB-systemer

Som konsekvens av kommune- og regionreformen har det vært nødvendig å gjøre større grep i og rundt NVDB. Samtidig har vi også benyttet sjansen til å modernisere og fase ut løsninger som i nær framtid uansett måtte erstattes. Endringene omfatter vegreferansesystem, vegnettsmodell, programmeringsgrensesnitt (API) og verktøy/klienter rundt NVDB. Dette arbeidet har pågått over flere år. I “anleggsperioden” har vi kjørt parallelle løp der både eksisterende og nye løsninger har vært tilgjengelig. Nå nærmer det seg tidspunkt for å fase helt ut de løsningene som ikke skal videreføres.


Planen er som følger:

1. juni 2021: Nedstenging av «NVDB Klassisk» – verktøy for alle som ikke spesifikt ber om tilgang fram til 1.8. Alle «NVDB Klassisk» – brukere kontaktes direkte via epost.

NVDB klassisk omfatter verktøy som NVDB 123, Funkra, NVDB studio, Vegreg og noen flere.

1. august 2021: Full nedstenging av gamle systemer. Det gamle api’et fases fullstendig ut, og de gamle verktøyene kan ikke lengre brukes mot NVDB.

I dette notatet er det beskrevet mer i detalj hva som videreføres og hva som ikke lenger blir tilgjengelig for vegnett, programmeringsgrensesnitt og NVDB-verktøy / NVDB-klienter.

Ruteplandatasett fra geonorge

Det er visst litt i overkant kronglete å pakke ut ruteplan-datasettet lastet ned fra geonorge på esri fil-geodatabase (FGDB) formatHer er par tricks som gjør livet enklere.

ALLER FØRST: Vis filtype (fil-etternavn) når du jobber skal håndtere dette datasettet! Standard i windows er å skjule filtypene. Det er sikkert fint i andre sammenhenger, men her skaper det problemer.

  • Det du laster ned fra geonorge er en zip-fil med fil-etternavnet .zip, for eksempel Samferdsel_0000_Norge_25833_NVDBRuteplanNettverksdatasett_FGDB.zip
  • En Esri fil-geodatabase er ei mappe (katalog) som inneholder .gdb i navnet – altså et fil-etternavn (.gdb) på ei mappe, for eksempel Samferdsel_0000_Norge_25833_NVDBRuteplanNettverksdatasett_FGDB.gdb
  • Etter å ha «pakket ut» zip-fila så vil du ha en fil og en mappe med samme navn (f.eks Samferdsel_0000_Norge_25833_NVDBRuteplanNettverksdatasett_FGDB), kun fil-etternavnet skiller dem (.zip eller .gdb)
  • Hvis du ikke har aktivert visning av filtyper (fil-etternavn) så har du ingen som helst mulighet til å skille zip-fil fra FGDB-mappen.

I filutforskeren viser du filtype ved å velge «Visning» og huke av for «Filtyper»

Skjermdump som viser hvordan du kan vise filtyper i filutforsker.
I filutforskeren kan du vise filtyper (fil-etternavn) ved å velge fanen «Visning» og huke av for «Filtyper».

Derifra og ut er det vanlig utpakking av zip-fil, men med større kontroll.

I siste datasett (Samferdsel_0000_Norge_25833_NVDBRuteplanNettverksdatasett_FGDB) ser vi at mappen mangler fil-etternavnet .gdb. Dette er enkelt å fikse: Bare døp om mappen og føy til .gdb på slutten av filnavnet. Vi skal prøve å sikre at det blir riktig fil-etternavn på neste nettverksdatasett.

Hvor finner jeg vegnettsrapport?

Såkalte «Vegnettsrapporter» er blant de tingene våre flinkeste og ivrigste brukere er vant med å kunne ta ut via NVDB Studio eller NVDB 123, som jo termineres 1. august 2021.

Vi har laget en ny vegnettsrapport i systemet «NVDB rapporter«, i den modulen som er skreddersydd for drift og vedlikehold av vegene (såkalte «driftskontrakter»). Den er ikke identisk med de gamle vegnettsrapportene, men den er såpass lik at de fleste kjenner seg igjen.

Bruksanvisning – last ned vegnettsrapport.

Gå til https://nvdb-vegnett-og-objektdata.atlas.vegvesen.no/generisk/

Velg Vegnettsrapport (V1)

Velg geografisk område: fylke eller kommune – minst én, men gjerne flere. Eventuelt kontraktsområde, hvis det er riktig for deg

Du kan også filtrere på vegkategori (eksempel: E) og vegnummer (eksempel: Ev39) i boksen vegfilter.

Skjermdump av meny for uthenting av vegnettsrapport.
Søkeinnstillinger for vegnettsrapport

Når du har valgt rapporttype og geografisk område skifter «Hent data» – knappen farge fra grå til blå og lar seg trykke på.

Skjermbilde av knapp for å starte produksjon av vegnettsrapport.

Når du trykker på «Hent data» får du ei stoppeklokke som viser at systemet setter sammen en rapport til deg. Når rapporten er ferdig byttes stoppeklokka ut med teksten «Rapporten er klar til nedlasting» og en knapp for å laste ned rapporten.

Skjermdump som viser hvordan det vises når rapporten er ferdig. Vi viser teksten "Rapporten er klar til nedlasting" og en knapp for nedlasting og en knapp for nytt søk.
Slik ser det ut når vegnettsrapporten er klar!

Friskmelding vinterdriftsklasse og ÅDT i NVDB rapporter

I NVDB rapporter for driftskontrakter har vi et par måneder slitt med feil i lengdeberegning av vinterdriftsklasse og ÅDT. Våre utviklere er nå sikre på at de har løst problemene og at systemet nå regner riktig – men at noen av testene feiler.

Hva mener du, feil i testene våre?

Våre tester – fasiten, om du vil – er ingen ferdiglaget fasit, men en separat opptelling hvor vi ut fra V4-rapporten (detaljert mengdeoversikt) regner ut antall, lengde og areal som sammenlignes med tallverdiene i V2- og V3-rapportene (aggregert mengdeoversikt, sum per vegkategori eller per vegnummer) . Det er i denne opptellingen utviklerne nå påpeker en svakhet som gjør at testopptellingen vår blir for upresis for noen av verdiene.

For kontraktsområdet 9305 Sunnfjord er utviklerne for eksempel skråsikre på at opptellingen av ÅDT-verdier mellom 0 og 500 kjøretøy per døgn nå er riktig i produksjonssystemet – men for upresis i vår testopptelling.

Utdrag fra testrapport for 9305 Sunnfjord. Vi har 15% skyldes feil i testopptellingen vår, mens systemet nå gir riktige tall for ÅDT og vinterdriftsklasse i V2 og V3-rapportene.

Hva kan vi gjøre?

P.t. ser vi disse to alternativene:

  • Stole på utviklerne når de sier at de går god for de nye beregningene, men at «fasiten vår» ikke er perfekt, og at vi derfor kan begynne å bruke systemet
  • Avvente til vi har finregnet på ny fasit og forbedret testene våre

Å forbedre testene tar tid, trolig minst en uke eller to. Vi har derfor valgt å produksjonssette og gå ut med denne informasjonen. Dermed kan du selv best vurdere om avvikene som gjenstår er til å leve med – eller om du heller venter en stund til.

Kan jeg se testrapportene?

Selvsagt! De ligger her! En fil per kontraktsområde som er testet (p.t. 6 stykker), samt en felles testrapport som oppsummerer de verste resultatene fra alle kontraktsområdene.

Hva betyr fargeverdiene?

  • Grønt betyr identisk antall eller mindre enn 0.5 prosent avvik på lengde og areal.
  • Gult betyr inntil 1 stykk avvik på antall eller mellom 0.5 og 2 prosent avvik på lengde og areal
  • Rødt betyr mer enn 1 stykk feil på antall eller mer enn 2 prosent avvik på lengde og areal

Hvordan beregne veglengder i en kommune?

Tidligere har vi publisert oppskrifter på hvordan du kan bruke vegkart til å finne lengder av veg til KOSTRA-rapportering. Disse oppskriftene er fremdeles gyldige, men nå er det kommet flere muligheter.

Bruk «NVDB rapporterut vegnettsrapport for valgfritt område.

Fra systemet «NVDB rapporter» for driftskontrakter , under fanen for «Egendefinerte rapporter kan du ta ut «vegnettsrapport» for en kommune. Denne løsningen finner du her: https://nvdb-vegnett-og-objektdata.atlas.vegvesen.no/generisk/

Skjermdump fra https://nvdb-vegnett-og-objektdata.atlas.vegvesen.no/generisk/ . Velg "Vegnettsrapport (V1)" og angi kommune og eventuell dato før knappen "Hent data" blir aktiv.
Skjermdump fra https://nvdb-vegnett-og-objektdata.atlas.vegvesen.no/generisk/ . Velg «Vegnettsrapport (V1)» og angi kommune og eventuell dato før knappen «Hent data» blir aktiv.

Velg «Vegnettsrapport (V1)» og angi kommune og eventuell dato før knappen «Hent data» blir aktiv.Valgene for Kontraktsområde og Fylke lar du stå tomme.

Skjermdump fra https://nvdb-vegnett-og-objektdata.atlas.vegvesen.no/generisk/ . Vi har valgt "Vegnettsrapport (V1)" og latt alternativene for Kontraktsområde og Fylke være tomme, men har valgt Holmestrand kommune og datoen 2020-12-31. Knappen "Hent data" er nå aktiv, og kan brukes til å laste ned vegnettsrapporten.
Ferdig utfylt skjema for Holmestrand kommune per nyttår 2020, du er nå klar til å laste ned vegnettrapporten.

Last ned ved å klikke den blå knappen «Hent data». Hvis knappen er grå (dvs inaktiv) betyr det at du må se over valgene en gang til. Knappen byttes ut med beskjeden «kjører» og hvor lang tid det har gått til nå. Etter et par minutters venting er rapporten klar, og telleverket byttes ut med dialog for nedlasting:

Skjermdump, slik det ser ut når rapporten er klar til nedlasting. Telleverk byttes ut med overskriften "Rapporten er klart til nedlasting" og en blå knapp for å laste ned. En rød knapp tilbyr alternativet "nytt søk".
Slik ser det ut når rapporten er ferdig beregnet og klar til nedlasting.

Last ned rapporten ved å klikke på den blå knappen.

Filtrering av vegnettsrapport

Vegnettsrapporten (excel) må filtreres før den gir riktige verdier. Den har fanene «Samlet, alt vegnett» som inneholder alle vegkategorier, for både gående og syklende. I tillegg har vi egne faner for kjørende og gående for hhv «riksveg» (vegkategori E og R), fylkesveg og «andre» (vegkategoriene K, P og S). Stort sett må du alltid filtrere regnearket for å få fornuftige tall.

Her er oppskriften på «Kostra»-rapportering med utgangspunkt i fanen «Samlet, alt vegnett»

  • Kolonne E «Trafikkantgruppe»: Velg «G» (gående og syklende) eller «K), alt etter hva som passer best.
  • Filtrer vekk sideanlegg – kolonne N: KS/SA
    • Fjern verdien SA (sideanlegg), behold Blanks (vanlig veg) og KS (kryssdel).
  • Filtrer kolonnen Y «typeVeg»
    • Du skal ha med Blanks, rampe, rundkjøring, gatetun
    • TypeVeg kan ha flere verdier samtidig, for eksempel konnektering, rampe. Ta vekk de verdiene der noen av de ikke-gyldige begrepene inngår. For eksempel skal du velge vekk alternativet «rampe, Konnektering»
  • Filtrer W «adskilte løp»
    • Verdien «Mot» skal velges bort. Du skal ha med verdiene ‘Ukjent», «Nei» og «Med».
  • B «Vegkategori «Til sist filtrerer du på den vegkategorien du ønsker,

Etter filtrering summeres lengden med kolonne V «Lengde veg (m)»

Skjermdump, eksempel på filterfunksjon i Excel. TypeVeg filtreres slik at vi kun teller de riktige vegtypene.
Eksempel på hvordan «typeVeg» – filteret (kolonne Y) kan se ut. Her har vi filtrert vekk Konnektering, kombinasjonen rampe, Konnektering og Serviceveg.
Filtreringsvalg for kolonne "
Velg vekk SA fra kolonne N: KS/SA, dvs du skal ikke ha med sideanlegg. Kun kryssdel (KS) og vanlig veg (Blanks).

NVDB rapporter: Feil mengdeberegning V2/V3

Denne feilen er løst, men noen problemer gjenstår

Vi har avdekket en alvorlig feil i mengdeberegning til driftskontrakt-rapporter. Det er de såkalte «Aggregerte mengdeoversikter», sum per vegkategori eller sum per veg. (Populært kalt V2 og V3 – rapportene). Feilen består i at vi summerer samme objekt flere ganger, slik at totalsummen blir for høy.

Vi kommer tilbake med mer informasjon i denne kanalen snarest mulig.

Info tirsdag 2 mars: Riktig beregning ÅDT og vinterdriftsklasse

Utviklerne våre går nå god for at oppgitt lengde for vinterdriftsklasse og ÅDT stemmer i den versjonen produksjonsatt 2.3.2021, men at testberegningen vår er for upresis og feiler for noen av oppføringene. Mer detaljer

Siste gjenstående feil skal da være spesialberegning «Kantklippareal, årlig anbefalt areal».

Info onsdag 10 februar: Ny versjon er satt i produksjon, Hva fungerer og hva feiler?

Ny og forbedret versjon EDIT er satt i produksjon, her er oversikt over kjente feil og hva som nå fungerer per 10. februar 2021 testsammendrag 10.feb 2021 basert på data for 6 kontraktsområder.

  • Beregning av antall, lengde og areal for fysiske objekter (vegutstyr, vegetasjon m.m.) fungerer, med unntak spesialberegning «Kantklippareal, årlig anbefalt areal»
    • Vi sjekker denne nærmere.
  • Beregning av lengde for vinterdriftsklasse og ÅDT fungerer fremdeles ikke
  • Datakatalogjustering for 838 vegbredde og 241 vegbredde fungerer (Dekke Grus, Stein og Betong), og opptellingen av disse ser riktig ut (antall og lengde).

Info mandag 1.februar: Hva fungerer og hva feiler?

Vi har laget denne oversikten over kjente feil og hva som nå fungerer (per 1.2.2021) oppsummering_test9305_2020-01-29. Kortversjon:

  • 10 oppføringer har arealberegning som feiler (spesialregel areal = Lengde x bredde)
  • Lengdeberegning for vinterdiftsklasse og ÅDT feiler
  • Datakatalogjustering: : 838 Vegbredde og 3 oppføringer for 241 Vegdekke (Betong, Grus, Stein).

De 10 radene (for 8 objekttyper) der arealberegning feiler:

3 Skjerm
   7 Gjerde 
  47 Busslomme
  47 Trafikklomme u/busslommme
  62 Mur
  48 Fortau 
 301 Kantklippareal
 301 Kantklippareal, årlig anbefalt areal
 845 Fanggjerde
 859 Taktile indikatorer 

Vi jobber videre med å få rettet disse feilene. På grunn av leverandørbytte tar dette mere tid enn det burde, men det kommer!

Info fredag 29.1 Fiks produksjonssatt. Mange alvorlige avvik er lukket, men en del gjenstår, se under.

Dette gir et rotete og krevende bilde som er vanskelig å forholde seg til, hvor rapportgeneratoren gir en blanding av gode og dårlige data. Vi jobber videre med disse sporene:

  • Rette opp utestående feil
  • En mer lettlest oversikt over hva som er riktig og feil i de ferdige rapportene
  • Informasjon om hvordan vi tester for riktig og feil i de ferdige rapportene

Info onsdag 27.1 Ny versjon er rullet ut i TESTPROD, forventet produksjonssetting er i morra torsdag eller senest fredag. Så krysser vi fingrene for at det ikke er noen ekstra snubletråder for å rulle ut fra TEST (atm) => produksjon.

Vi har også nyskrevne testrutiner som gir oss god oversikt over summeringer som er OK og hvem som feiler. Oppsummert så vil disse oppføringene fremdeles feile i den nye versjonen:

EDIT: Noen objekttyper føyd til et par timer etter opprinnelig publisering.

objtype Beskrivelse                     Problem
    3    Skjerm                             Store arealavvik fordi spesialregel areal = Lengde x Bredde feiler
    7    Gjerde                            Undersøker, finner arealavvik 4% eller lavere
   37    Kanalisering primærrveg         Telling av vegkryss og avledede      37    Kanalisering sekundærveg         Telling av vegkryss og avledede    37    Vegkryss                         Telling av vegkryss og avledede verdier (primærveg, sekundærveg) feiler
   47    Busslomme                         Spesialregel areal = Lengde x    47    Trafikklomme som ikke er busslomme   Spesialregel areal = Lengde x Bredde feiler
   62    Mur                             Store arealavvik fordi spesialregel areal = Lengde x Bredde feiler
   80    Grøft åpen (ulike typer)         Usikker, må ettergå
   83    Kum (ulike typer)                Usikker, må ettergå 
   96    Skiltplate (ulike typer)         Usikker, må ettergå 
  241    Dekke, Betong                    Regeldefinisjon utdatert ift datakatalogen
  301    Kantklippareal                     Store arealavvik fordi spesialregel areal = Lengde x Bredde feiler
  301    Kantklippareal, årig anbefalt    Store arealavvik fordi spesialregel areal = Lengde x Bredde feiler
  845    Fanggjerde                         Spesialregel areal = Lengde x Bredde feiler
  859    Taktile Indikatorer             Spesialregel areal = Lengde x Bredde feiler
  540    ÅDT per intervall                Telling av ÅDT og vinterdriftsklasse feiler
  810    Vinterdriftsklasse                Telling av ÅDT og vinterdriftsklasse feiler 

Detaljert oversikt over hvilke avvik vi fant når vi sammenlignet data fra detaljert objektoversikt (V4) med aggregert mengdeoversikt per veg (V3). SammenlignV2ogV3_2021_01_27.xlsx

Info fredag 22.1 Vi tør ikke love produksjonssetting i dag, men gjør så godt vi kan. Vi fant også en snublefeil i gårsdagens testing. Detaljert testrapport postes her så fort den er klar.

Info torsdag 21.1 Feilen er retta, vi håper å få produksjonssatt snarest – men noen feil vil fremdeles gjenstå: Etter produksjonssetting så vil arealberegning for disse objektene fremdeles feile:

Skjerm (3 Skjerm)
Busslomme (47 Trafikklomme)
Trafikklomme u/busslomme (47 Trafikklomme)
Mur (62 Mur)
Kantklippareal (301 Kantklippareal)
Kantklippareal, årlig anbefalt areal (301 Kantklippareal)

Her er testrapport utført 20.1

Noen pussigheter oppstår også fordi samme objekt kan «regnes med» i flere av kolonnene i V2-rapporten (f.eks både i E+R og G/S – kolonnen). Dette er ikke feil – tallet i hver av kolonnene er korrekt, men det blir for høyt hvis du summerer alle kolonnene. Ett eksempel er oppføringene for «Alle NVDB-data av typen «Bru» (dvs fra fagsystem Brutus)«.

Info onsdag 20.1 Feilen i antall objekt er fikset, men ikke satt i produksjon. Vi har fremdeles feil lengdeberegning for ÅDT og vinterdriftsklasser i V2/V3.

Info tirsdag 19.1: Utviklerne har skrevet kode med fiks, testing gjenstår. Pga leverandørbytte går det tregere med utrulling til testmiljøet vårt.

Info mandag 18.1: Utviklerne har en teori om hva bug’en består i og regner med de kan fikse ila av uka (men vi lover ingenting før det er klart). Vi er dessverre tregere enn vanlig pga leverandørbytte.

Åh nei – excel tror tall betyr dato

Excel har en logikk som gjetter hva tall og tekst betyr når du importerer dato. Dessverre er funksjonen som gjetter på hva som er dato litt i overkant ivrig.

At excel tipper noe er en dato har skapt flere frustrerende problemer og blant annet medført at adskillige årsverk med forskning har gått i vasken. Genforskere bytter nå navn på gensekvenser for å omgå problemet, og adskillige forskningsartikler har måttet trekkes tilbake fordi dataene ble korrupte etter at excel hadde mistolket dem.

Dessverre er også csv-eksporten fra Vegkart til tider rammet – ikke ofte, men noen ganger. For eksempel sliter vi med at excel leser tallene våre for lengde og tolker dem som dato. F.eks dataverdier som SEPT-1, eller visse tallkombinasjoner.

Workaround – importer data manuelt til excel-arbeidsbok

Du skal IKKE åpne filen med excel, men importere den til en ny fane i excel:

  1. Laste ned CSV-filen uten å åpne den.
  2. Åpne Excel på normalt vis med en tom arbeidsbok.
  3. Gå til Data-fanen, klikk på «Fra tekst/csv». Hvis denne knappen er «grået ut» så åpner du en ny fane i excel med pluss-knappen nederst.
  4. Finn CSV-filen du lastet ned og importer denne.
  5. Se over at alt ser riktig ut i preview-vinduet.
  6. Trykk «Last inn».
  7. Du vil få CSV-data inn i et nytt ark. Du kan slette det tomme arket du startet med. .

Dataverdiene skal nå være riktige. I tillegg får en pen formattering

Med bilder:

Steg 1: Last ned data (vegkart-brukerveiledning)

Steg 2: En tom arbeidsbok i Excel

Skjermdump, en tom fane (tomt regneark) i Excel

Steg 3: Gå til «Data» – fanen, klikk «Fra tekst/CSV» Hvis denne knappen er «grået ut» (inaktiv) så åpner du en ny fane i excel med pluss-symbolet nederst.

Skjermdump, importer data til excel via fanen "Data" og valget "From text / CSV"
Fanen data, knappen «From Text/CSV». Hvis denne knappen er inaktiv (grået u) så åpner du bare en ny fane med pluss-knappen nederst, så pleier det virke.

Steg 4: I vinduet «import data» velger du CSV-filen du nettopp lastet ned.

Skjermdump, menyen "Import data" hvor du velger den CSV-filen du lastet ned fra vegkart.

Steg 5 og 6: Se over «data preview»- vinduet, sjekk at alt ser greit ut. Vanligvis går det helt fint med standardvalgene. Klikk «Load» for å laste inn

Skjermdump, data preview vindu i excel.

Steg 7: Suksess!

Skjermdump som viser hvordan data er pent formattert av excel etter dataimport.