APISKRIV 2018-1: Ny versjon av APISKRIV i PROD

Publisert av

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.  

  • [NVDB-2155] – Kan ikke kombinere tempId og nvdbId i en assosiasjon

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>
  • [NVDB-2162] – Kan ikke ta imot % tegn i egenskapsverdier:

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. 

  • [NVDB-2168] – Viser flere enn blokkerende låser

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.

  • [NVDB-2169] – Kan ikke flytte mor og datter samtidig

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.

  • [NVDB-2266] – Får ikke lov til å flytte moren når man ikke har lov til å flytte datteren.

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.  

  • [NVDB-2750] – Feilmelding på innlest assosiasjon mot ikke-eksisterende datter

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.

  • [NVDB-2270] – Vegobjekt med tom lokasjon avvises ikke

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.

  • [NVDB-2290] – Avvist når stedfesting toucher konnekteringslenke

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.

  • [NVDB-2317] – AVVIS geometrier som er en blanding av 2D og 3D.

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..

  • [NVDB-2327] – Burde avvise overlappende stedfestinger

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

  • [NVDB-2364] – Unødvendig streng låse-blokkering?

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.

  • [NVDB-2792] – Sjekker ikke duplikate nvdbId i delvisKorriger

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.