Feilretting Datafangst kurve-alias

Vi rettet nettopp to feil knyttet til vegobjekt-alias i Datafangst. Feilen rammet noen av brukerne våre hardt, mens andre ikke opplevde problemer. Vi beklager ulempene!

Et alias er et midlertidig navn vi bruker for å skille objekter fra hverandre i tabell, for eksempel «Kurve 1» eller «skiltpunkt:85397901». I størst mulig grad prøver vi å gjenbruke SOSI-numerereringen, slik at når det står «Kurve 1» i SOSI så bruker vi også «Kurve 1» i Datafangst. For Geojson prøver vi også så langt det går prøver å tolke tagger for å finne passende kurvenummer. Hvis vi ikke klarer finne noe passende informasjon så genererer vi et tall.

Feil nummer 1 var at innlesning til Datafangst feilet hvis det sto andre ting, for eksempel datoer, i den taggen der vi forventet å finne et heltall. Da fikk du feilmeldingen «kan ikke lese vegobjekter for visning» når du trykker på en vegobjekt-type.

Feil nummer to var knyttet til kopiering, der et objekt med en alias («Kurve 1») blir til to objekter med samme alias. Når du prøver å endre disse to så ga det kun effekt på den ene av dem, noe som var både forvirrende og frustrerende.

Begge disse feilene ble retta og rullet ut i produksjon i løpet av torsdag og fredag, ref driftsmeldingene på twitterkontoen vår NVDB åpne vegdata (@NVDBapi) / Twitter

Vi prøver ut import av GML i Datafangst

Som vist på BA-nettverkstreff 20. januar så har vi nå lansert en prototype for import av GML til datafangst. Dette gjør du manuelt via menyen for filopplasting, som nå støtter filtypene .SOS og .GML. Direktelenke til presentasjonen BA-nettverkstreff 20.1.

Vi understreker at dette er en prototype som gjør det lettere å prøve ut de ulike GML-variantene som finnes i markedet og avdekke styrker og svakheter.

GML-en min virker ikke, kan dere fikse?

Vi vil svært gjerne kartlegge hvilke problemer som evt dukker opp, så den GML-filen som feiler kan du sende til Datafangst-support krøllalfa vegvesen punkt no. Sammen med Vegvesenets standardiseringseksperter vil vi sjekke om problemet er i GML-filen, i datafangst import – og eventuelt om applikasjonsskjemaet bør videreutvikles for å støtte det du prøver å få til. Dine feilmeldinger inngår i kunnskapsgrunnlaget når vi videreutvikler støtte for GML.

Det vi IKKE kommer til å gjøre – er å fikse feilen raskt. Akkurat nå, vinteren og våren 2022, må vi prioritere ny datafangst-løsning samtidig som vi sikrer stabil drift av nåværende løsning.

Datafangst ønsker til fremtidig GML-funksjonalitet

Sett fra Datafangst sin side så ønsker vi at det blir mulig å beskrive følgende i fremtidige GML-dokument

  • Flere objekttyper i samme GML-dokument (dette tror vi er fullt mulig i dag, men vi må få erfaring med «beste praksis» og eventuelle snublefeller)
  • Angi hvilke NVDB skriveoperasjoner som ønskes for de eksisterende NVDB-objektene (registrer, oppdater, korriger m.m.)
  • Angi relasjoner mellom objekter: Internt i GML-dokumentet, mellom objekter i GML og eksisterende NVDB-objekter og mellom eksisterende NVDB-objekter.

Denne funksjonaliteten kan ikke løses av Datafangst alene, men krever et samarbeid om hvordan vi videreutvikler GML «Beste praksis» i markedet. Men vi på Datafangst er veldig gjerne med på å prøve ut disse mulighetene.

Demo NVDB Rapporter og Datafangst 2. mars 2022

Her er opptak fra demo

NVDB rapporter:

  • Kan laste ned zip-fil med de 5 mest relevante rapporttypene (V1,V2,V3,V4 og tilstand/skade).
  • Vegnettslengde – har ny rad med summen av gang/sykkelveg og kjøreveg.
  • Veglisteproduksjon: Komma som desimaltegn, bruke lang tankestrek, ikke kort bindestrek i strekningsbeskrivelse; fjerne mellomrom før og etter tankestrek. Dette er i hht klage fra Språkrådet

Datafangst:

Ikke så mye ny funksjonalitet å vise fram, fokus har vært på stabilitet (og dermed også ytelse). Datafangst har crashet pga minneforbruk. Årsaken har vært at Datafangst ikke har hatt noen form for begrensning ved «vis eksisterende objekter». Det var veldig enkelt å laste inn f.eks. skiltplater for hele Norge. Nå har vi satt begrensning slik at du kun laster inn «eksisterende objekt» for små områder, dvs at du må zoome inn.

  • Begrensning ved innlasting «eksisterende objekt», du må zoome ganske langt inn før systemet tillater deg å hente objekter. (Workaround de gangene dette blir plundrete: Importer data fra vegkart API-lenke).
  • Sammenkoblingsfanen – hadde samme problem ved søk etter NVDB-objekter, fikk crash pga minneproblemer. Har satt en begrensning, søkeradius er redusert til 1000 meter. (Workaround de gangene dette blir plundrete: Importer data fra vegkart API-lenke).
  • GML på vei mot produksjon
  • Last opp fil med eksisterende objekt: Datafangst har tidligere lest inn ett objekt av gangen. Nå leser vi 200 av gangen. Ved vår test prøvde vi innlesning av 1000 objekter og tiden for innlasting ble redusert fra flere minutter til en håndfull sekunder.
  • Maks størrelse SOSI fil: Har satt en begrensning på 3000 objekter.
  • Opplasting med sensitive egenskaper: Kunne ta veldig lang til hvis man ikke hadde rettighet til å lese sensitive egenskaper, fiksa.
  • Sjekker at relasjon er reell før vi endrer på relasjonen. (dvs sjekke at mor-objekt finnes og det finnes en eksisterende relasjon til datterobjekt før vi sletter eller endrer mor->datter relasjonen). Vi har hatt en del supportsaker der brukerne våre står fast med avviste endringssett fordi enten mor-objekt eller relasjonen mor->datter er historiske.

Tilbakemeldinger

Hva hvis vi skal koble mor-objekter som ligger langt unna, kan vi bruke vegkart søkelenke for å hente inn objekter som ligger lengre unna enn 1000 m? F.eks. tunnelløp->skiltplate relasjon kan være i stor avstand. Ja – og dette er en veldig god workaround for de tilfellene der våre nye begrensninger gir plunder.

Får ikke lese hendelsesloggen lenger? Forslag om å kun vise siste del av hendelsesloggen? Godt forslag, notert!

Legge inn vegreferanser? Pass på at det ikke blir multiple stedfestinger. Enig, notert!

Problemer med å opprette belysningsstrekning. Gjelder alle brukere, ser det ut til. Even G tror han vet hvor problemet ligger, og at han klarer løse det greit og raskt..

Norge i bilder (flybilder bakgrunnskart) – visning funker ikke for brukere utenfor SVV-nettet. Takk for feilmelding! Her kom Kartverket forleden med ny tjeneste som Vegkart allerede har tatt i bruk. Vi tar i bruk samme løsning som Vegkart bruker, så blir dette problemet løst. (Dette vil også gi bedre ytelse på flyfoto).

Bugfix release datafangst

Vi fjernet to bugs, en i sammenkoblingsfanen og søk i datafanen skal nå fungere

I tillegg har vi tatt vekk Rød prikk som symboliserer hvilke kontrakter det er endringer på. Vi jobber med å få tilbake denne funksjonen. Dette var en altfor treg databasespørring. Når vi har mange brukere samtidig så får vi da altfor mange trege spørringer som kverner og kverner og spiser opp systemressurser – og på et punkt går alt i stå, vi kan ikke ha ubegrenset med trege spørringer samtidig.

Vi har funnet flere tricks som fjerner denne tregheten. For det første har vi fått spørringene til å gå radikalt raskere. Videre er det noen tricks knyttet til at vi ikke spør om alt på en gang, kun de kontraktene du har synlige i skjermbilde, og litt tilsvarende tricks. Dette blir produksjonssatt så snart det er klart.

Demo datafangst 2. februar 2022

Vi pleier ikke poste oppsummering fra demo, men på grunn av situasjonen med dårlig stabilitet i Datafangst så kom det fram ting på demo vi mener bør nå fram til flere.

NVDB Rapporter:

Kan bestille zip-fil med V1,V2,V3,V4 og tilstand/skade. Sum veglengder: Ny rad med summen av kjøreveg og gang/sykkelsti.

Datafangst – ytelse og stabilitet

Ytelse og stabilitet henger sammen – hvis en type spørring går tregt så vil det bli en lang «kø» med disse trege spørringene, og i verste fall blir det så mange samtidige trege spørringer samtidig at alt sammen stopper opp.

Vi har tatt vekk «røde prikken» som viser hvilke kontrakter som er endret. Dette var en av de trege spørringene som ga oss utfordringer. Vi skal gjøre denne databasespørringen raskere og når den blir rask nok så kommer prikken tilbake.

Brukerønske ang den røde prikken: Vi har behov for denne typen «Vis at her er det skjedd endringer» på alle GUI-elementer, fra den overordnede listen med kontrakter helt ned til visning av enkeltobjekter.

Ekstremt tydelig og klar tilbakemelding på at vi må bli flinkere til å publisere driftsmeldinger fortløpende på twitter, og dernest bli flinkere til å skrive oppsummeringer om arbeidet med problemløsning (og øvrige planer) på vegdata.no.

Ny funksjonalitet i datafangst: «Opprett nytt strekningsobjekt»

Vist på forrige demo, men måtte gå en runde til fordi brukertesten avdekket mangler. I denne testprosessen fått gode innspill og idéer fra testerne våre, og ut fra det har vi laget flere løsningsforslag som vi mener tilsammen skal gi knallbra funksjonalitet. Men disse må prioriteres bak arbeidet med ytelse og stabilitet. Vi vil prøve å snurpe sammen en minimumsløsning som ikke vil være så brukervennlig som vi ønsker, men som fungerer godt nok til at den kan tas i bruk. Så får den knallgode implementasjonen komme senere, når vi har mer overskudd.

Balansering – arbeidet med ny versus gammel datafangst-løsning

Vi kommer ikke til å offisielt «fryse» videreutvikling av gammel datafangst-løsning selv om vi lager en ny. Verden endrer seg, og det kan dukke opp behov som er for viktige til at de kan vente på den nye løsningen. Vi nekter derfor å sette opp harde regler for hva vi gjør og ikke gjør av forbedringer i gammel løsning.

Aller høyest prioriterer vi at Datafangst virker! Ytelse og stabilitet henger sammen, og dette prioriterer vi høyt. Ref oversikten over arbeidet med å forbedre brukeropplevelse

Bortsett fra den nye funksjonen «Opprett nytt strekningsobjekt» vil det ikke bli tilført noe særlig nytt i eksisterende datafangst.

Vi vil også prøve å gjeninnføre del av de tingene vi måtte deaktivere på grunn av ytelsesproblemer, for eksempel «rød prikk» ved de kontraktene der det har skjedd endringer. Og det er ett og annet småtteri og bugs som ikke lenger fungerer like godt som før, det prøver vi å fikse. Og så er det slik at hvis vi med liten innsats kan gjøre en fiks eller forbedring som gir brukerne våre en bedre arbeidshverdag så prøver vi jo å klemme det inn. Men ikke forvent for mye.

Hvorfor bygger vi splitter ny Datafangst?

Kortversjon: På fem år har Datafangst vokst fra en enkel prototype til en kompleks applikasjon. I dag håndterer DF større datavolum enn den ble bygget for, og vi har en veldig uheldig blanding av gammel kode skrevet i ett rammeverk (Angular, som ikke blir videreutviklet) og ny kode skrevet i et annet rammeverk (React). Brukerne våre opplever treghet, og utviklernes jobb er unødig plundrete.

Den aller første versjonen kommer våren eller sommeren 2022. Denne versjonen vil kun ha det minimumet av funksjoner som trengs for å levere data til NVDB, men da kun for et snevert utvalg av data, med et minimum av de aller mest nødvendige funksjonene. Nye releaser vil komme i form av hyppige, men små forbedringer. Slik vil vi gradvis føye til mer avansert funksjonalitet. Gradvis vil den nye løsningen kunne overta stadig flere arbeidsoppgaver fra den gamle løsningen.

Presentasjon og stikkord fra møte 25.1.2022 om ny datafangst:

Vi må ta ned Datafangst for vedlikehold i helga!

EDIT Mandag 24.1: Suksess, nå har vi fått metreringsretning inn i datafangst!

Vi beklager kort varsel – men fra fredag 21.1 kl 17 så blir Datafangst utilgjengelig på grunn av database vedlikehold.

Bonus er jo at vi kommer tilbake mandag morgen med metreringsretning på stedfesting!

I løpet av helga vil vi legge informasjon om metreringsretning på all vegnettsinformasjon, dvs stedfestingen for samtlige objekter i databasen til Datafangst. Denne informasjonen hentes fra leseapi, og det er en tidkrevende prosess. Vi antar kjøretida blir rundt ett døgn, men foretrekker å sette av hele helga til oppdatering, for sikkerhets skyld.

Planen var jo at denne oppdateringen skulle kjøre i bakgrunnen mens dere brukte Datafangst som vanglig, men som vi så i går – det fungerte ikke spesielt bra. Det kunne kanskje fungert i helga, når det er færre brukere, men vi har valgt å gjøre det trygt og sikkert denne gangen.

Datafangst driftsproblemer 20. januar – LØST

LØST klokka 11:00: Problemet er LØST.

Årsaken var knyttet til oppdatering av metreringsretning på alle vegene som manglet denne informasjonen. Denne engangs-operasjonen belaster systemet såpass mye at vi må utsette denne jobben til helga, når det er færre brukere på systemet. Vi siterer fra gårsdagens informasjon om ny release:

Vi har et script som kjører og fyller inn metreringsretning på alle veger det er stedfestet på. Dette tar ca. et døgn å kjøre. Det betyr at vi har ikke metreringsretning på alle veger enda.

Om man har et objekt som er stedfestet på veg uten metreringsretning vil sideposisjon og felt være grået ut i vegobjekter-fanen og hvis man hovrer på dette feltet vil det stå «Objektet er stedfestet på veg uten metreringsretning og sideposisjon/felt kan ikke oppgis.». Hvis objektet har sideposisjon eller felt vil det dukke opp så snart metreringsretningen har blitt hentet inn. Hvis man vil se sideposisjon og felt med en gang kan man stedfeste på nytt og vi vil da hente inn metreringsretningen på veglenka. Alle veglenker forventes å ha fått metreringsretning innen fredag morgen i løpet av helga.

Det er driftsproblemer med Datafangst, ser ut som om forbindelsen med databasen vår hikker. Utviklerteamet er i gang med feilsøking og -retting, dette innlegget oppdateres med mere info.

Ny datafangst-versjon satt i produksjon

Datafangst 2022-2.0.1 er ute i PROD

  • Mulighet til å vise kommentarer for flere objekter og objekttyper gjennom verktøymenyen i datafanen.
  • Mulighet til å fjerne flere kommentarer gjennom filtrering og markering.
  • Nye, mer beskrivende farger på kommentarboblene.
  • Vegsystemreferansen kan nå sees i datafanen for objekter som er registrert i NVDB eller er stedfestet.
  • Metreringsretning er nå standard retning i datafangst.
  • Man kan nå se retningen på veglenker i kartet, både i datafanen og stedfestingsfanen.
  • Sideposisjon og felt kan nå sees og redigeres selv om det er flere av disse for et vegobjekt.
  • Sideposisjon og felt vises i forhold til metreringsretning i motsetning til før da de vistes i forhold til geometriretning.
  • Sideposisjon og felt er nå markert gult om det er endret ifht NVDB.
  • Ved stedfesting kan du nå sende med vegkategori for å spesifisere stedfestingen mer nøyaktig.
  • Den gamle stedfestingstypen ble visualisert bedre når det kom til krappe svinger som nærmet seg sirkler. Dette er nå fikset.
  • Ved import av SOSI kan man nå velge operasjon, som betyr at man kan importere eksisterende NVDB-objekter som SOSI.
  • Endring av enkeltattributter i datafanen har blitt raskere.
  • Når det dukker opp en feilmelding får du oppgitt en lenke til ofte stilte spørsmål for mer informasjon.
  • Andre mindre feilrettinger og forbedringer.

Obs! Vi har et script som kjører og fyller inn metreringsretning på alle veger det er stedfestet på. Dette tar ca. et døgn å kjøre. Det betyr at vi har ikke metreringsretning på alle veger enda.

Om man har et objekt som er stedfestet på veg uten metreringsretning vil sideposisjon og felt være grået ut i vegobjekter-fanen og hvis man hovrer på dette feltet vil det stå «Objektet er stedfestet på veg uten metreringsretning og sideposisjon/felt kan ikke oppgis.». Hvis objektet har sideposisjon eller felt vil det dukke opp så snart metreringsretningen har blitt hentet inn. Hvis man vil se sideposisjon og felt med en gang kan man stedfeste på nytt og vi vil da hente inn metreringsretningen på veglenka. Alle veglenker forventes å ha fått metreringsretning innen fredag morgen. I løpet av helga. EDIT: Dette scriptet gir såpass stor belastning at vi må kjøre det i helga, når det er færre brukere.