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. (En dato i excel er nemlig et flyttall, så hvis du har et passe stort tall så er du i faresonen).

Workaround

  • Laste ned CSV-filen uten å åpne den.
  • Åpne Excel på normalt vis med en tom arbeidsbok.
  • Gå til Data-fanen, klikk på «Fra tekst/csv».
  • Finn CSV-filen du lastet ned og importer denne.
  • Se over at alt ser riktig ut i preview-vinduet.
  • Trykk «Last inn».
  • Du vil få CSV-data inn i et nytt ark. Du kan slette det tomme startarket.

Lengde skal nå se riktig ut. I tillegg får man den bonusen at Excel auto-formaterer CSV-filen inn tabellformat, slik at man kan sortere på kolonner.

Feil – noen søk mangler egengeometri

FIKSA! Denne feilen er nå retta august 2020.

Vi har hadde en feil i NVDB api som gir kjipe konsekvenser for Vegkart, Sinus Infra og Datafangst – og ikke minst registrering av nye data til NVDB. Denne feilen må vi dessverre leve med gjennom sommeren.

Visse typer søk viser data plassert på senterlinja selv om de egentlig har en fysisk plassering i terreng.

Nei, egengeometrien er ikke borte – det er kun feil i kartvisningen

Data med egengeometri er ikke endret i NVDB – det er kun kartvisningen.

Mer presist så serverer vi data med en ekstra geometri-egenskap når du (og vegkart, Sinus og datafangst) henter data fra NVDB api. Normalt så sjekker vi først om det finnes gyldig egengeometri for et objekt; i så fall er det disse dataverdiene som legges på geometri-feltet. Men hvis det ikke finnes egengeometri for et objekt så henter vi koordinater for vegnettet i stedet. Det er her vi gjør feil; logikken skal selvsagt ikke påvirkes av hvilke søkefiltre som brukes – men den gjør det!

Sjekker du detaljene vil du se at egenskapen Geometri, flate, Geometri, linje og Geometri, punkt er slik de skal være.

Konsekvenser

Konsekvensene er størst for dem som driver med registrering og ajourhold av data til NVDB, i for eksempel Sinus.infra eller datafangst, eventuelt med kontroll i Vegkart. Når du registrerer vegutstyr med egengeometri, tydelig plassert til side for vegen, så er det ekstremt forvirrende at objektet ikke dukker opp der du la det.

Det er veldig fort gjort å konkludere at her gikk noe galt, og registrere samme objekt en gang til. Eller kanskje du tror det er noe galt med geometrien, og prøver rette det opp.

Hvilke typer søk har dette problemet?

Alle søk som involverer bruk av vegnettet for å finne ting ser ut til å være påvirket. Det gjelder disse filtrene, muligens flere:

  • Vegsystemreferanse (f.eks E6, slik som vist over)
  • Kommune
  • Fylke

Trolig gjelder dette også en del søk som er mulig i NVDB api, men ikke i vegkart. Slik som overlappfilter.

Hvilke søk fungerer slik de skal?

Disse søkene fungerer slik det skal, og viser objektene med egengeometri

  • Søk med kartutsnitt

VegRefHistorikk – PCprogram for å finne gamle vegnummer

Stian Søberg Johansen, Innlandet fylkeskommune (og tidligere vegvesen-kollega) har laget et PC-program som hjelper deg å finne fram i gamle og nye vegreferanser. En vegreferanse har som kjent den leie egenskapen at de går ut på dato, fordi vegnettet endrer seg. Eller så har vi administrative påfunn, som å bytte vegnummer eller hvem som har ansvaret for vegen.

Vegrefhistorikk er et fint tilskudd til verktøykassa for å oversette mellom gamle vegreferanser og nye, og mellom de to referansesystemene.

Hovedfunksjoner

  • Klikk i kart / hent fra koordinat
  • Fritekstsøk
  • Import av regneark med gamle vegreferanser og oversette dem til nye (importtrans).

Her har du lenke til brukerveiledning og her kan du laste ned applikasjonen

VegRefHistorikk-startvinduet.png
VegRefHistorikk-startvinduet-bareKart.png

Stygg vegkart-feil er fiksa

Hvis jeg i går utvidet infoboksen om dettet vegkart-søket (klikk høyrepil der det står «> 2637 vegobjekter»

Så fikk jeg denne feilmeldingen:

Ikke alle vegkart-søk fikk denne feilen, men mange av dem!

I dag fungerer det

Denne feilen har vært innmari plagsom for veldig mange vegkart-brukere og vi er veldig glad den er vekk! Feilen har vært til hinder for å bruke utlisting av vegobjekter i vegkart, og den har hindret nedlasting av datasett fra vegkart på sosi- eller csvformat.

Workarounds: Eksport av data fra vegkart

NVDB api versjon 3 er under rivende utvikling: Vi jobber kontinuerlig med ytelse og feilretting. Dessverre må vi tære enda en stund på tålmodigheten til våre brukere før vi har den stabiliteten og kvaliteten i alle ledd som vi ønsker. Men vi nærmer oss!

Ett av problemene har vært eksport av data fra Vegkart, som CSV eller SOSI prikk (kun vegkart V3). Dette har vi jobbet mye med, og vi er nesten i mål. Oppskrifter finner du i vegkart brukerveiledning eller under «ofte stilte spørsmål«.

For å bruke CSV- eller SOSI eksport må du først utvide infoboksen med søkeresultatet ditt (høyrepil ved der det står antall objekter).

Dessverre vil noen av søkene dine gi feilmeldingen «Det har skjedd en ulykke» når du prøver å utvide resultatboksen (FIKSA 5.6.2020).

Feilen med crash og feilmelding «Det har skjedd en feil» når du prøver å utvide infoboksen om søket ditt skal nå være retta. Men hvis du fremdeles opplever problemer kan du prøve Versjon 2 av Vegkart (eller vegkart-2019, som den også kalles). CSV-eksporten derfra fungerer (krysser fingre). https://www.vegdata.no/ofte-stilte-sporsmal/hvordan-far-jeg-nvdb-data-inn-i-kartsystemet-mitt/

CSV eksport har rader du må ignorere

CSV-eksporten fra vegkart V3 vil ofte, men ikke alltid ha med noen rader som mangler verdi for fylke, kommune, geometri og vegsystemreferanser. Disse må du ignorere / filtrere ut.

For eksempel CSV-dump for søk etter skiltplate i Bjerkreim inneholder 2036 rader. 40 av disse radene mangler fylke, kommune, geometri og vegsystemreferanser. Ignorer disse, og du står igjen med 1996 gyldige rader.

Mer detaljer: https://www.vegdata.no/2020/04/22/csv-dump-fra-vegkart/

CSV-dump fra Vegkart

Vi har en feil i CSV-eksporten fra versjon 2 av vegkart (V2) som gjør at CSV-dumpen ikke inneholder geometri. Fiksa!

Ved CSV nedlasting fra vegkart V3, får du med en del rader med ugyldige data.

Vegkart versjon 3 med søk på trafikkmengde langs E10 og mulighet for nedlasting av data som Sosi eller CSV.

Som nevnt får du en del rader med ugyldige data. Disse mangler blant annet data om geometri, kommune og fylke. Dette kan du trygt ignorere.

Utdrag av tabell med trafikkmengde E10 lastet ned som CSV. Vi ser at fire av radene mangler data om kommune, fylke og geometri. Disse radene kan trygt ignoreres.

Utdrag av tabell med trafikkmengde E10 lastet ned som CSV. Vi ser at fire av radene mangler data om kommune, fylke og geometri. Disse radene kan trygt ignoreres.

Lenker til vegkart V2 og V3: