Gå til hovedinnhold

Jeg har brukt gamle datafangst (DF10) – hva bør jeg vite?

Etter filopplasting så er det nå et nytt steg for godkjenning og konvertering av filer. Data vil ikke komme fram i vegobjekttabell før du (eller en forvalter) har godkjent (konvertert) filene.

Arbeidsflyten for stedfesting og sammenkobling er kraftig revidert.

Rollestyringen er ulik, se rollebeskrivelse

Hva bør jeg vite som systemutvikler av integrasjoner mot gamle datafangst?​

Nye datafangst har en åpen arkitektur med veldig rik funksjonalitet – men dokumentasjonen blir tilsvarende tyngre å orientere seg i, med forvirrende mange endepunkt. Selve logikken for opplasting av flere filer ligner jo på DF10, med en http POST operasjon mot endepunkt der kontraktId inngår, og der man angir parameter destination=NVDB eller FKB. Responsen inneholder ID til den opplastede filen – men har ingen informasjon om validering av filen.

Godkjenning og konvertering av filer​

Nytt i DF20 er at alle filer må godkjennes og konverteres før data blir lest inn i kontrakten (og blir synlige i databehandling-fanen). Hver systemleverandør må avklare med sine oppdragsgivere om det er mest hensiktsmessig at dette steget gjøres manuelt av bruker i GUI, eller om klienten gjør dette maskinelt - i så fall er det en http PATCH operasjon mot endepunktet /api/v2/kontrakter/{kontraktid}/filer/godkjenn der man sender inn en liste med ID til de filene som skal godkjennes. For å kunne godkjenne og konvertere så må man ha forvalter-rettigheter (eller høyere) på den kontrakten. Rettighetene for innlogget bruker på de ulike kontraktene kan man hente i endepunktet /api/v2/brukere/meg, alternativt så får man jo veldig brutalt en 401 unauthorized hvis innlogget bruker ikke har lov til å konvertere.

Systemleverandører må være forberedt på at ønsket om godkjenning/konvertering – og rettighet til å gjøre det – vil variere fra kontrakt til kontrakt. Noen ganger er det gunstig at konverteringen av NVDB-data skjer raskest mulig og maskinelt fra klient, slik at kvalitetskontroll og feilretting kan gjøres i databehandlingfanen i GUI. I andre kontrakter er det ønske om en manuell kontroll før manuell godkjenning.

For dataleveranser til FKB (destination=FKB) så er det normalt foretrukket at filene godkjennes manuelt av forvalter i løsningen.

Filer med blokkerende feil kan ikke godkjennes og konverteres til vegobjekter. Responsen blir da http 400 med feilmelding.

FKB filer skal normalt valideres av forvalter

Filer som skal til Kartverkets database Felles Kartbase (FKB) skal normalt godkjennes manuelt av forvalter med verktøy som Sosi kontroll før godkjenning og konvertering.

Validering av filer​

http GET mot endepunktet kontrakter/{kontraktId}/fil-metadata gir deg en liste med status for alle filer levert på kontrakt. Det essensielle her er elementet valideringsStatus, der vi i en normal arbeidsflyt har verdiene OK, ADVARSEL eller FEIL. Ønskesituasjonen er jo selvsagt OK. En feil betyr blokkerende feil, normal flyt er da å sjekke valideringsinformasjon, slette filen og laste opp på ny en feilrettet versjon. Ved ADVARSEL oppfordrer vi alle klienter til å sjekke hva advarselen består i, og aller helst tilby funksjoner for å rette opp forholdet.

http GET mot endepunktet kontrakter/{kontraktId}/filer/{filId} gir deg en respons med detaljert valideringsinformasjon.

Filformater​

Filformatene er slik som i gamle datafangst: Enten SOSI i henhold til objektliste og leveransekrav, se veiledningsdokument på denne siden.

NVDB-data kan også leveres som geojson, og her refererer vi til formatspesifikasjonen i gamle Datafangst DF10 formatdokumentasjon, med disse tilføyelsene:

  • Alle geojson features må ha en id på rotnivå. Dette er i tillegg til evt nvdbid under properties. Vi bruker ikke denne ID'en til noe spesielt, og vurderer å fjerne dette kravet - men i dag er det påkrevd.

  • tag under properties er påkrevd. Per i dag brukes denne ikke til noe som helst. På litt lengre sikt er dette informasjon vi ønsker å vise til brukeren, slik at det blir enklere for brukeren å spore enkeltobjekter mellom systemene.

Autentisering​

For alle kall må det følge med en header Authorization: Bearer {token}, hvor token er et gyldig id_token fra OpenId Connect.

Tilgang for eksterne utviklere

Eksterne brukere logger inn manuelt via ID porten, men vi må jobbe videre med en strømlinjeformet oppskrift for maskinell innlogging for eksterne. Swagger-trickset under burde imidlertid fungere hvis du har en personlig bruker med tilgang til Datafangst.

Tips og tricks til effektiv bruk av Swagger​

Gyldig autentiseringstoken fra endepunktet autentiser i nvdb-auth tjenesten. Dette kan du også gjøre manuelt i denne tjenestens swagger-dokumentasjon.

Hvis du henter manuelt så kan du lime tokenet inn i authorize-menyen på Datafangst Swagger-dokumentasjon (hengelås-symbol)

Hengelåssymbol for å autentisere deg i Swagger

Datafangst sin swagger-dokumentasjonen får du ved å gå til relevant miljø https://nvdb.atlas.vegvesen.no/docs/produkter/datafang/df2/systemdokumentasjon/Miljoer. I swagger må du først velge riktig definition i nedtrekksmeny i øvre høyre hjørne

Brukerdialog for å velge riktig definisjon i swagger

Valget Basis tar deg til grunnleggende funksjoner for filopplasting samt administrasjon av filer, brukere, kontrakter, kontraktgruppe og objektliste. Det er her, under overskriften Filer, du finner metodene for å laste opp filer, sjekke om de passerer validering og så eventuelt gjennomføre godkjenning og konvertering. Merk at konvertering skjer i et endepunkt kalt godkjenning, og at det kan variere fra kontrakt til kontrakt om det er rett at systemklienten gjør godkjenning. Det varierer med foretrukket (avtalt) arbeidsflyt på den kontrakten, men også med hvilke tilganger som innlogget bruker har på den kontrakten.

Valget Vegobjekter gir deg raffinerte metoder for å manipulere hvert enkelt vegobjekt. Et vegobjekt oppstår først når filen blir godkjent og konvertert. En innlogget bruker med rettighet deltaker på kontrakt kan manipulere vegobjekt, også når brukeren mangler rettighetene til å godkjenne fil-leveranse.

Datafangst GUI mangler ganske mye på geometriredigering og kvalitetskontroll. Her oppfordrer vi alle systemutviklere til å utvikle integrasjoner der man kan utnytte eksisterende GIS verktøy til å kontrollere og redigere vegobjekters geometri. Merk at oppdatering av et vegobjekt sin geometri også må ha med metadata for geometri.