Ny korrigerflyt for retting av innsendte objekter i DF 2.0
Vi innfører en ny korrigeringsflyt for retting av objekter som allerede er sendt til NVDB i en kontrakt. Endringen tydeliggjør formålet med Datafangst 2.0 og skal bidra til bedre datakvalitet, ryddigere historikk og mindre feil bruk av kontrakter.
- Det vil kun være mulig å korrigere et sendt objekt dersom siste endring i NVDB ble registrert fra gitt datafangstkontrakt. Dersom et objekt er redigert et annet sted i etterkant, f.eks. via kontraktløs, annen datafangstkontrakt eller andre verktøy, vil det ikke være mulig å korrigere objekter i "opprinnelig" kontrakt.
- I første omgang åpnes det for korrigering av egenskaper etter innsending. På sikt vil også løsningen støtte korrigering av stedfesting og sammenkobling.
- Når man åpner et objekt for korrigering må korreksjonen utføres direkte og sendes til NVDB på nytt. Det vil ikke lenger være mulig å åpne objektene for korrigering, og samtidig interagere med andre ikke sendte objekter. Man må gjøre seg ferdig med de innsendte objektene man vil korrigere, før man fortsetter videre arbeid.
- Det vil være mulig å korrigere flere objekter av samme objektype samtidig. F.eks. hvis man ønsker å korrigere egenskap 'Eier' til 'Statens vegvesen' og egenskap 'Prosjektreferanse' til 'Testprosjekt' for 10 skiltpunkt er dette mulig å gjøre samtidig. Dersom du ønsker forskjellig verdi må dette gjøres i flere omganger.
Hvorfor endrer vi?
Datafangst 2.0 er ikke utviklet som et iterativt arbeidsverktøy der objekter sendes inn og korrigeres gjentatte ganger over tid. Likevel ser vi at løsningen i dag ofte brukes nettopp slik.
Som hovedregel skal man kun levere ferdig data til NVDB, og kun korrigere sendte objekter ved retting av eventuelle feil. Hensikten med datafangst er å justere, endre og tilpasse før innsending. Ved innsending skal data være ferdig behandlet og kvalitetsikret - man skal ikke levere mangelfull data til NVDB. Målet er derfor å unngå korrigering i etterkant.
Vi er klar over at det finnes leveranser som krever NVDB-id for enkelte vegobjekter på et tidlig tidspunkt, da bør man dele opp leveransen i to datafangstprosjekter.
Utfordringer med dagens bruk?
- Vi mister objektets historikk - hver gang vi åpner for korrigering mister man info om hva som ble registrert via kontrakten
- Gamle (ferdig behandlet) kontrakter gjenbrukes
- Versjonskonflikter
- Det blir rett og slett brukt som en "lagreknapp" undeveis i arbeidet, noe som strider i mot tiltenkt bruk.