Gå til hovedinnhold

Kjente mangler og brukerønsker

Denne oversikten er todelt:

  • Først en rekke småfeil vi regner med å fikse relativt raskt.
  • Dernest en liste med brukerbehov der vi ikke har noen konkret tidsplan ennå (per november 2024).

Mangler vi har fikset

I pilotperioden publiserer vi også en liste over mangler som nylig er rettet.


Sjekk versjonsloggen i Datafangst

Vi minner om bjellesymbolet i øvre høyre hjørne, som gir deg tilgang til de nyeste og kommende forbedringene i Datafangst – populært kalt versjonslogg. Her vil det nok komme gode nyheter litt raskere enn vi klarer oppdatere dette dokumentet. Rød prikk ved bjellesymbolet i øvre høyre hjørne betyr at det er kommet til ny informasjon siden sist gang du sjekket. Klikk på bjella for å få fram versjonsloggen.

Trykk på bjellesymbolet for å se versjonslogg

Nyeste endringer vises i verjonsloggen

Kan ikke redigere kjørefelt eller sideposisjon

Foreløpig er det ikke mulig å endre sideposisjon eller kjørefelt for objektenes stedfesting.

Feil på innlesing av SOSI flate når flateavgrensning er eget SOSI-objekt

Når et flateobjekt i SOSI filen refererer til et kurveobjekt (såkalt Flateavgrensning) så klarer ikke DF20 lese inn SOSI filen riktig. I noen tilfeller står et rødt kryss ved siden av filen, og hvis du klikker på filen så er det en rødmarkering på linjen med ..OBJTYPE Flateavgrensning. I andre tilfeller så blir filen lest, men kurve-delen kommer som et separat objekt i tillegg til flate-objektet.

Sletting av konverterte filer fjerner ikke vegobjekter

Når du sletter en konvertert fil (typisk fordi du ønsker å laste opp en ny og feilrettet versjon av filen) så skal vegobjektene i den filen fjernes fra kontrakten. Dette skjer ikke. Workaround er å fjerne berørte vegobjekter manuelt.

Lagre store relasjonstrær til NVDB feiler

Eksempel på datasett der det oppstår feil ved lagring til NVDB:

  • 1 belysningsstrekning + 660 belysningspunkt + 660 lysarmaturer.

Vår anbefaling er at pilotbrukere utforsker arbeidsflyt der man låser og sender mindre deler av datasettet, for eksempel ved å ta objekter innenfor en liten del av kartet av gangen.

Stedfesting kan ikke garantere at sideposisjon for barn blir lik forelder sin sideposisjon

En av de virkelig fine tingene med den nye stedfestingfunskjonen er at vi kan sikre at barnas stedfesting blir i henhold til innenfor forelder – regelverket. Her gjenstår det litt arbeid med sideposisjon før vi kan garantere at sideposisjon blir i henhold til regelverk.

Vise geometritypen i tabell

En objekttype kan ha ulike geometrityper i en tabell, for eksempel kan objekttypen 199 Trær ha både punkt, linje og flategeometri. Dette blir enklere å håndtere hvis hvert objekts geometritype vises med tekst eller symbol i tabellen.

Bedre redigering av metadata geometri (geometrikvalitet)

Selv om du kan redigere metadata geometri for ett objekt av gangen så savner vi to funksjoner:

  • Du kan ikke «viske ut» (nullstille) en metadata-egenskap. For eksempel viske ut oppføringen for DatafangstMetodeHøyde når objektet har 2D geometri.
  • Du kan ikke kopiere en metadata-egenskap til mange andre objekt samtidig.

Opprette strekningsobjekt basert på vegsystemreferanse

I gamle datafangst kan du opprette et nytt objekt med linjegeometri der linja blir konstruert ved å vegsystemreferanse for start- og sluttpunkt.

Alternativ løsning 1: Konstruer ny geometri i GIS verktøy, konverter til SOSI eller geojson og last opp i Datafangst.

Alternativ løsning 2: Opprett nytt objekt i gamle datafangst (DF1.0), last ned som SOSI og last opp i nye Datafangst.

Visuelt skille mellom nye og eksisterende NVDB-egenskaper

Etter import og konvertering av filer med eksisterende NVDB objekt (operasjon oppdater eller korriger) forventer brukerne våre at vegobjekttabellen (i databehandling-fanen) visuelt skiller mellom nye egenskapsverdier og de egenskapene som er uendret.

Barn-objekt får ikke status sendt når foreldreobjekt er sendt til NVDB

Når man sender et foreldreobjekt til NVDB så følger alle barn-objekt med automatisk – men barnobjektet blir ikke markert med status sendt i databehandling-tabellen. Merk at logikken med at både foreldre og barn skal låses samtidig og sendes samlet til NVDB fungerer, det er kun sendt-markering i tabell som er mangelfull.

Alternativ løsning 1: I stedet for å sende foreldre-objektet så kan man sende barn-objektet til NVDB. Da blir sendt-status satt riktig for både foreldre og barn. Eksempel: I stedet for å sende skiltpunkt til NVDB så sender man skiltplate.

Alternativ løsning 2: Ignorer problemet, det blir riktig i NVDB selv om Datafangst ikke viser riktig Sendt-status. Ulempen er at det blir vanskelig å skille mellom barneobjekt som er lagret til NVDB, men mangler «sendt»-status, og barn som ikke er lagret til NDVB ennå.

ENUM-egenskaper i geojson blir ikke lest inn

Ved konvertering av innsendt geojson så blir ikke ENUM-verdier lest inn i systemet. Dette er altså de egenskapene der man har en forhåndsdefinert liste med valgbare verdier, for eksempel Bruksområde.

Advarselen «stedfestet utenfor mor» forsvinner ikke

Hvis man får feilmeldingen Stedfestet utenfor mor», men retter opp feilen (gir objektet ny stedfesting som er innafor forelder) så forsvinner ikke feilmeldingen.

Må ignorere feilmeldinger for FKB filer

I dagens implementasjon så får man en del feilmeldinger ved konvertering av FKB filer. Disse feilmeldingene er ikke relevante og må ignoreres.

Deltaker kan melde fra om at nå ligger det filer til kontroll

Deltaker på kontrakt har ikke rettighet til å konvertere filer, derfor trenger vi god kommunikasjon mellom deltaker og forvalter (evt eier). I første omgang løser vi dette ved å tilby funksjon der deltaker kan markere at en kontrakt er klar til kontroll og konvertering.

Tydelig visuell forskjell på stedfestingens trafikantgruppe

Når du har stedfestet objektene så hadde det vært lurt at objekter som er stedfestet på gang/sykkelveg (trafikantgruppe G) vises ulikt fra dem som er stedfestet på vanlig bilveg.

Fritekstsøk i kontraktliste er litt mangelfullt

Søk etter kontrakt i listen over tilgjengelige kontrakter er litt mangelfullt, og noen ganger får du færre treff enn det som er riktig.

Et par småfeil på administrasjon

  • Per i dag må man gjøre full refresh av siden når man endrer på rollene i en kontrakt eller kontraktgruppe
  • Endring av objektlistetype når det er levert data på kontrakten medfører at statistikk over leverte objekter (på objektliste-siden) blir nullstilt
  • Mangler litt på flyten for milepæler og milepælsplan

Kjente ønsker med lang tidshorisont

Dette er et lite utdrag av de mest etterspurte sakene fra backloggen for nye Datafangst. Vi jobber fremdeles med prioritering av disse sakene, og kommer tilbake med fremdriftsplan for de sakene som gis prioritet.

Opprette strekningsobjekt basert på punktobjekter

I gamle datafangst kan du opprette et nytt objekt med linjegeometri der linja blir konstruert ut fra de valgte punktobjektene. For eksempel kan du velge alle belysningspunkt på høyre side av vegen og opprette en belysningsstrekning som dekker de valgte belysningspunktene.

SOSI numerering vises ikke i databehandling

Etter innlesing og konvertering av SOSI så vises vegobjektene med et løpenummer i databehandling-fanen. Dette løpenummeret har ingen sammenheng med den numereringen som er brukt i SOSI filen, men er et løpenummer uten informasjonsinnhold. For eksempel nummeret Gjerde 4 kan være navngitt som .KURVE 1 i SOSI. Vi kommer ikke til å implementere samme løsning som i gamle datafangst (der objektene beholdt navnet fra SOSI eller geojson-filen, f.eks Kurve 1), men vi ønsker å tilby sporbarhet tilbake til rett objekt i riktig SOSI- eller geojson fil.

Vise koblinger (relasjoner) i kart

En kartbasert visning av relasjoner ville utvilsomt gitt bedre arbeidsflyt og oversikt, men er krevende å få til.

Opprette objekt ved å tegne punkt, linje eller flate i kartet

I gamle datafangst kan du opprette et nytt objekt med punkt- eller linjegeometri ved å tegne i kartet.

Vise andre NVDB-data sammen med kontraktens data

Et brukerønske er muligheten til å vise NVDB-data sammen med de dataene som er i Datafangst kontrakten. Dette er ikke mulig per i dag. I stedet kan du bruke vegkart eller et GIS-verktøy som støtteverktøy ved siden av.

Mangler automatisk kvalitetskontroll av FKB filer

Per i dag fungerer nye datafangst som et passivt fillager for data som skal til Kartverkets system «Felles kartbase» (FKB). Dataforvaltere må laste ned filene og kontrollere manuelt på egen PC. Her er det stor potensiale for å effektivisere dataflyten ved å la systemet finne typiske feil, for eksempel enkle geometrifeil, manglende egenskapsverdier eller inkonsistens mellom geometri og metadata geometri.

Duplikatsjekk

Et stort og komplisert tema, det er mange typer duplikater

  • Det kan finnes duplikater blant eksisterende NVDB objekt.
  • Det kan komme duplikater blant data levert på en Datafangst kontrakt.
  • Samme objekt kan også bli levert flere ganger, men på ulike Datafangst kontrakter.
  • Vi kan også introdusere nye duplikater hvis man leverer nye opprett-objekter til Datafangst når man heller burde oppdatert eksisterende NVDB objekt.
  • I noen tilfeller er det er rett å opprette nye objekt selv om vi har eksisterende data i NVDB, men det er fort gjort å overse at da må man lukke de eksisterende NVDB-objekt.

I alle disse tilfellene bør Datafangst tilby brukerne verktøy for å finne og rydde opp i duplikater, samt hindre at nye duplikater oppstår.

Laste opp bilder og andre typer vedlegg

Flere fagmiljø etterspør mulighet for å laste opp bildefiler som kan lagres til NVDB tilknyttet objekttypen 446 Dokumentasjon. I tillegg er det noen ønsker om at Datafangst kan bli mottak for andre typer dokumentasjon som ikke skal til NVDB.

Vegbilder

Slik som i vegkart så er det ønske om vegbilde-integrasjon i Datafangst.

Dronebilde (ortofoto) som bakgrunnskart

Så å si all byggevirksomhet over en viss størrelse bruker systematisk droner til kartlegging og kontroll før, under og etter anleggsperioden. Ferske ortofoto fra droneflyging er utvilsomt svært nyttig ved objektregistrering, men disse dataene er p.t. ikke tilgjengelig i en felles tjeneste som Datafangst kan hente fra.

Smertefri datakatalogendring

I dag er det en viss risiko for at data produsert og levert i henhold til en datakatalogversjon blir delvis ugyldige i det den neste datakatalogversjonen settes i produksjon. Datafangst bør tilby bedre verktøy for automatisk å oversette mellom datakatalogversjoner, for eksempel ved bytte av egenskapsnavn. I tillegg bør systemet tilby verktøystøtte for å håndtere endringer der vi ikke kan oversette automatisk.