Utviklingplanar er lagt ut

Utviklingsplanar med liste over alle saker vi har registrert for utvikling er no lagt ut under dei ulike produkta Statens vegvesen leverer i NVDB-portefølgen. Ei ovrsikt over alle planane Utviklingsplaner NVDB produktportefølje.

«Kjente feil»-posten er samstundes fjerne då feil er registrert som saker og plassert inn i utviklingsplanane våre. Eventuelle nye kritiske feil vil vi poste som eigne innlegg eller på Twitter dersom vi ser behov.

Registrering av Vegdekke

241-Vegdekke er en objekttype mange har utfordringer med å registrere i NVDB i nye løsninger. Datakatalogen og regelsettet generelt er uendret i forhold til NVDB-123, men mange hadde nok utarbeidet en rutine for å få gjennomført oppgaven i klassisk løsning.

Det er funksjonalitet for å gjøre det samme i nye løsninger, men det krever ofte en del manuelle rutiner.

Her er noen retningslinjer og tips for å få utføre arbeidsoppgaver med registrering av 241-Vegdekke.

Bindelag og Slitelag

Binde- og Slitelag må registreres i to omganger med ulik dato i NVDB.
Årsaken til dette er at det er to objekter av samme type og de kan ikke ha overlapp. Bindelag må derfor settes historisk for at slitelaget kan registreres. NVDB krever at et objekt er gyldig minimum 1 dag. Et objekt med lik start og slutt-dato vil i NVDB-verden tolkes som ikke å ha eksistert.

Fortrinnsvis bør da data leveres i separate leveranser fra entreprenør og behandles/leveres til NVDB separat i registreringsverktøy. Det kan for eksempel gjøres ved å levere data for Bindelag til NVDB før Slitelag leveres til dataløsningen, eler at det leveres til ulike «prosjekter/kontrakter» dersom løsningen ikke har støtte for utvalg ved innsending.

Fremgangsmåte ved samlet leveranse/fil

  1. Leveransen eksporteres til fil (eller lignende) for senere arbeid
  2. Alle data som omhandler slitelag fjernes fra prosjektet/kontrakten
  3. Data for bindelag kontrolleres og klargjøres for innsending
  4. Datasettet sendes til NVDB med dato tilbake i tid
    • fortrinnsvis med dato for faktisk dekkelegging
    • alternativt dagen før slitelagdato dersom det er samme dato
  5. Datasett leses inn på nytt fra backup-fil (punkt 1)
  6. Alle data som omhandler bindelag (allerede registrerte data) fjernes fra prosjektet/kontrakten
  7. Data for slitelag kontrolleres og klargjøres for innsending
  8. Objekter opprette ti NVDB i punkt 4 hentes inn i prosjektet/kontrakten for lukking
  9. Datasett sendes til NVDB med dato minimum 1 dag etter startdato for objekter som skal lukkes
    • fortrinnsvis med dato for faktisk dekkelegging

Ved registrering av flere dekkelag deles datasettet opp i flere delsett og punkt 5-9 repeteres til alle lag er registrert.

Registrering av flere objekter på samme strekning

241-Vegdekke kan tillater i følge Datakatalogen ikke overlapp. Dersom dekke måles inn i flere objekter på samme strekning, f.eks. et objekt pr. retning/felt, sykkelfelt, avkjøringsfelt osv. må disse skilles ved å sette feltkode på objektene. Det er tillatt med et objekt pr. felt pr. punkt i vegnettet.

gang-/sykkelveg

Gangveg, gang-/sykkelveg og sykkelveg er egne vegsystemer som kan ha vegdekke. Vegdekke på disse vegene skal ikke stedfestes på hovedvegen men på sine respektive vegstrekninger.

Fortau

Fortau er ikke definert som felt i dagens vegnett. Dekke på fortau anbefales ikke å registreres som egne vegdekkeobjekter. Dette ivaretas i dag som egenskap på objektet 48-Fortau.

Dekker som ikke er del av vegen

Dekker på områder som ikke er en del av vegen skal ikke registreres som vegdekke i NVDB selv om det er vegeier som forvalter dekket. Dette kan være gangstier på/rundt kollektivpunkter, turistattraksjoner, holdeplasser osv.

Utvikling fremover

  • Vi håper på at utviklingen av registreringsklienter på sikt vil automatisere mye av problematikken rundt dekkelegging. Vi ser for eksempel for oss at klienten kan skille på om det er bindelag/slitelag og ta inn be om dato for legging av de ulike lagene og på den måten håndtere alt med deling, lukking og oppdatering.
  • Fortau og gangstier vil på sikt få vegsystemreferanser i NVDB. Når det skjer vil det være mulig å legge vegdekke på disse objektene likt med gan-/sykkelveg.
  • Vi vurderer innføring av et nytt objekt «Dekke» som kan benyttes til dekkeobjekter som ikke er del av vegen, men likevel har en tilhørighet.
  • Vi vurdere endring av Vegdekkeobjektet fra dagens utforming som tillater egengeometri til å være et «abstrakt» objekt som bare forholder seg til stedfesting (og feltvalg) på vegnettet.

NVDB-Skriv URL uten «atlas» legges snart ned

NVDB API Skriv har blitt etablert i nye driftsmiljøer på Atlas-plattformen hos Statens vegvesen. Vi har hatt begge miljøene opperative i en god periode nå og regner med mange har byttet til nye URLer. Vi vil nå starte prosessen med å stenge av de gamle URLene, og ber nå alle brukere om å se over at alle system er oppdatere med nye URLer.

Planlagt stenging av gamle URLer er 1. juli 2021.

På grunn av tilbakemeldinger om at ikke alle systemer har oppdatert URL-ene til de nye utsettes stenging av gamle adresser til August 2021. Vi kommer tilbake med ny dato etter hver som vi får tidsplan fra de systemene som ikke er klare.

Siden dette kom nært opp til ferie for mange og at informasjonen ikke ser ut til å ha nådd frem til alle i tidligere faser er vi litt fleksible med nedstengingsdato her.

Systemtestmiljø:
https://www.utv.vegvesen.no/nvdb/apiskriv/* => https://nvdbapiskriv-stm.utv.atlas.vegvesen.no/*

Akseptansetestmiljø:
https://www.test.vegvesen.no/nvdb/apiskriv/* => https://nvdbapiskriv.test.atlas.vegvesen.no/*

Produksjonsmiljø:
https://www.vegvesen.no/nvdb/apiskriv/* => https://nvdbapiskriv.atlas.vegvesen.no/*

I Atlas-miljøet brukes en ny autentiseringsmekanisme, basert på OAuth2 (OpenId Connect). Når klienter skifter over til nye URLer må derfor også autentiseringlogikken omprogrammeres. Hvordan dette kan gjøres er forklart på https://apiskriv.vegdata.no/autentisering.

Dersom det er spørsmål rundt dette, ta kontakt med nvdb@vegvesen.no.

Dersom det er behov for å holde det gamle miljøet oppe en stund til fremover må vi ha tilbakemelding om dette snarest med begrunnelse og dato for når det ikke er nødvendig lenger.

Ny Datafangst ute

Datafangst versjon 3.1.0 er ut. Her er endringane som er gjort:

Datafangst 2021-3.1.0 (12. april)

  • Gruppe-admin og kontraktgruppe-admin skal også kunne legge til brukere på kontrakt
  • Mulig å endre navn på kontraktgruppe og å slette kontraktgruppe
  • Ingen error-melding skal dukke opp ved navigasjon ut fra innstillings-fanen

Nedetid for VisVegInfo

Det er nødvendig med oppdatering og påfølgande restart av server som køyrer VisVegInfo. Tenesten og alle produkt og tenestar som brukar VisVegInfo er vena å vere ustabile og utilgjengelege i periodar i kved og i natt.

Vi ber om årsaking for kort varsel her. Det kjem som ei følge av ei uventa hending som er årsak til ei rekke interne feil i våre tenestar, og oppdatering er nødvendig for å rette opp dette.

Feil i Datafangst

Feilen med stedfesting i Datafangst er nå rettet og alle funksjoner skal fungere som normalt igjen. Dersom du fortsatt opplever problemer, forøk å lukke nettleseren og starte datafangst på nytt.

Vi opplever nå feil i et baksystem Datafangst er avhengig av for enkelte operasjoner knyttet til stedfesting av vegobjekt. Vi arbeider med feilsøking av problemet.

Det er også problemer med flere funksjoner i våre testmiljø for de som benytter disse.

Kontrakter manglar i lista etter bytte til ny Datafangst-adresse

Vi har registrert at mange opplever at kontraker manglar etter å ha bytta til ny adresse for Datfangst.

Det er ingen endring i Datafangst i samband med adresse-ending, og alle tilganger er som før.

Den vanlegaste årsaka til manglande kontrakter er at brukaren har fleire brukarnamn. Det kan vere fleire ulike e-post-adresser (privat og jobb) eller e-postbrukar og SVV-identitet. Undersøk difor at det er samsvar mellom brukar-ID som kontraktansvarleg eller forvaltar har lagt til i kontrakta og den brukar-iden det vert logga inn med.