Alle presentasjonene fra utviklerdagen 2018 er nå tilgjengelige her.
Minner om:
Her følger et lite innblikk i noe av det vi jobber med på NVDB og Geodata nå for tiden.
Personvernombud Annegret Andersen har gitt oss råd og anbefaling om hvordan vi skal håndtere vegbildene som i dag er tilgjengelige via applikasjonene NVDB123, GisLine og ViaPhoto. Vi går ikke til det drastiske 
skrittet å slette bildene, men iverksetter strakstiltak som i første omgang begrenser tilgangen til eksisterende bilder. I tillegg vil vi jobbe med tiltak som sørger for at vi ikke lagrer personsensitiv informasjon i bildende i framtida. Retningslinjer for tildeling av tilgang til bildene vil bli utarbeidet slik at de som har bruk for bildene i jobben sin vil få tilgang. Les videre
Neppe, med mindre du jobber med stedfesting og lagring av nye data til NVDB, eller har et system som bruker Visveginfo direkte.
Har du et system som baserer seg på Visveginfo så er det helt klart en ulempe at du ikke har med vegnettsendringer etter juli 2018.
Vegkart er ikke berørt, heller ikke når du ber om strekninger.
Visveginfo er et system for vegnettspørringer fra 2011. Visveginfo utfyller NVDB api’et på et veldig god måte, for eksempel med topologi- og strekningsspørringer. Men én av utfordringene er at vi har to parallelle dataflyt-løyper til NVDB api og Visveginfo:
Nå – 29. august – plundrer vi ennå med en gigantisk transaksjon fra slutten av juli. Dette blir ble løst 30. august.
Datafangst er Vegvesenets nye verktøy for mottak, kvalitetskontroll og beriking av data entreprenørene sender oss om det de har bygget. Før data kan lagres i NVDB må de knyttes til riktig vegnett. Og det blir jo litt vanskelig når den nye vegen ligger i kø bak en gigantisk transaksjonslogg.
Her er f.eks en ganske fersk gangsti på Tjøme, Vestfold
Ny gangsti langs Fv390, Vestfold.
Men datafangst viser frem vegnett fra Visveginfo, og har derfor ikke den nye gangstien som alternativ. Da er det jo vanskelig å stedfeste belysning på gangstien, der det hører hjemme:
Datafangst henter vegnett fra Visveginfo, og der er ikke gangstien kommet med ennå. Merk at gangstien er synlig som en grå strek i bakgrunnskartet, men IKKE tilgjengelig som gyldig vegnett du kan stedfeste på i Datafangst.
Du kan bruke denne kartløsningen. Den henter data både fra Visveginfo og NVDB api. Da ser du fort om de er enige, eller om det er avvik. Mer om dette kartet.
NVDB api tilbyr gangstien som nærmeste vegnett, mens Visveginfo har kun hovedvegen
Nedenfor ser du at Fv390 har fått nye meterverdier. Nvdb API gir ca 7 meter lavere tall enn Visveginfo.
Kartverket har endret sine tjenester som har fått konsekvenser for NVDB123 funksjonalitet.
NVDB har besluttet at vi ikke ønsker å benytte midler på å reetablere denne funksjonen i NVDB123, da det er en programvare som skal fases ut. Det finnes andre tjenester som kan gjøre eiendomssøk som Seeiendom og VisVeg, alternativt finnes det også i GisLine.
Før Norge begynner å falle inn i sommerferiemodus, her kommer en status fra oss på NVDB og Geodata! Les videre
Hvordan kan jeg finne kollektivfelt eller andre typer kjørefelt i NVDB?
Informasjon om kjørefelt er i NVDB lagret på de enkelte veglenke-delene. Den som liker å programmere kan lese mer om datastrukturen her: http://api.vegdata.no/endepunkt/vegnett.html
For resten av oss er 616 Feltstrekning til stor hjelp. Inntil relativt nylig var det på denne objekttypen vi lagret oversikt over kjørefeltene. Denne blir fremdeles holdt a jour: Ved vegnettsredigering kopieres kjørefelt-informasjon fra veglenkene over på 616-objektet, mer presist som tekst i egenskapsverdien feltoversikt.
Kollektivfelt har koden «K», og vi finner dem med filteret «feltoversikt = *K*. De to stjernene (*) betyr at du kan ha hvilken som helst tekst foran og bak bokstaven K.
Lenke til dette vegkart-søket
Feltene er numerert i stigende rekkefølge fra senterlinja og utover, oddetall til høyre og partall til venstre, sett fra starten på veglenka.
Felt uten bokstaver er helt vanlige kjørefelt, mens spesialfelt som sykkelfelt (S), kollektivfelt (K), ferjeoppstillingsplass (O) og svingefelt (H eller V) har egne bokstavkoder i tillegg til nummerering.
Den fulle oversikten finnes i den utmerkede håndbok v830 Nasjonalt vegreferansesystem, der figuren er hentet fra.
Vi bruker hashtag – # – for å skille kjørefeltene fra hverandre.
Vi har fått ut to nye leveranser på NVDB API LES hittil i 2018:
Datoformat:
Vegnett:
Geometri:
Vi har idag fått ut en feilrettingsleveranse for NVDB APISKRIV APISKRIV 2018-1. Leveransen inneholder en rekke feilrettinger som har kommet inn det siste halve året.
Det har virket som om det ikke er lov å kombinere referanse til nye og gamle objekter i en assosiasjon. Det er det, men alle relasjonene til eksisterende objekter må komme før relasjonene til nye objekter, altså:
<assosiasjoner> <assosiasjon typeId="220373"> <nvdbId>459899</nvdbId> <tempId>Datter#1</tempId> </assosiasjon> </assosiasjoner>
For eksempel: <verdi>%P</verdi> Vi har rettet en feil og sørger nå for å automatisk “escape” prosent-tegnet med et ekstra prosent-tegn (%%P) – slik at verdien blir riktig satt i NVDB.
Dersom et endringssett havner i status VENTER_PÅ_LÅS, så skal man fra kontrollpanelet kunne se hvilken lås man har en konflikt med. Det har vært vanskelig til nå, siden vi har listet opp alle låser. Det gjør vi ikke lengre.
Ved validering berikes et endringssett med eksisterende data fra NVDB. I de tilfellene man forsøkte å flytte mor og datter samtidig, fikk man tidligere feil dersom objekttypen krever at datter skal være stedfestet innenfor mor. Feilen skyldtes at vi sammenliknet den gamle stedfestingen til moren med den nye stedfestingen til datteren. Nå sammenlikner vi de nye stedfestingene og da skal dette gå bra. Så lenge mor og datter flytter til samme sted.
I de tilfellene man har lov til å flytte en mor og det ikke er noe krav om at de må bo på samme sted, har man også fått feil dersom man ikke også har rettigheter til å flytte på datterobjektet. Flere av dere syntes det var noe strengt ettersom dere ikke forsøkte å flytte på datteren i det hele tatt. Nå skal dette la seg gjøre.
Det hender at døtre flytter hjemmefra. I noen tilfeller slettes objekter i NVDB mens relasjonen består. Siden vi validerer mot et beriket endringssett har dette ført til avvisning av endringssettet ettersom objektet ikke regnes som et gyldig objekt. Det er fremdeles ikke et gyldig objekt, men det er litt strengt at du da heller ikke får lov til å endre på det. Nå får du endret på det, men får også en advarsel.
Alle objekter i NVDB må være stedfestet til vegnettet. Noen har derfor stusset over at man får lov til å registrere endringssett med nye objekter uten lokasjon. Man fikk ikke lov til å starte dem dog. Nå blir de AVVIST tvert.
Logikk for utstrekning av stedfestinger i NDVB er fra og med, til. Vi har vært litt for rause og tillat til og med. Det er uheldig når en stedfesting slutter an mot en konnekteringslenke, ettersom endringssettet da blir avvist. Fra nå av er det fra og med, til. Ikke til og med.
Tidligere har vi litt lettsindig godtatt geometrier som har en blanding av 2D og 3D koordinater. Dette har ført til systemfeil i behandlingen. Nå har vi fått på plass en validering og avviser geometrier som ikke blir enige med seg selv om de skal være i 2 eller 3 dimensjoner..
Strekningslokasjoner kan settes sammen av flere elementer, f.eks.
<linje lenkeId=«7657» fra=«0.5» til=«0.6000000000001»/>
<linje lenkeId=«7657» fra=«0.6» til=«0.6000000000001»/>
Disse to delene overlapper og det er ikke lov. Nå blir de også AVVIST
API SKRIV har hatt en strengere tolkning av låse-reglene i NVDB en det som har vært vanlig i andre verktøy. Nå har vi akkurat samme tolkning. Vi bruker faktisk akkurat samme prosedyre i databasen for å avdekke konflikter.
Det er er ikke lov å korrigere et objekt to ganger i samme endringsett. Hvis man prøver seg på dette nå, vil endringssettet bli AVVIST med meldingen «Må være unik: nvdbId».
I tillegg har vi gjort en del forbedringer i kontrollpanelet og litt genrell opprydding på bakrommet.