AR5 er delt i 3 arkiver

[larsop]

Dette krever mye ekstra kode på vår server side, for at klient vi bruker skal slippe å forholde at det er 3 forskjellige

I Postgis Topology har vI et sømløst arkiv i grader for hele Norge så da slipper klienten vår å forholde seg til denne problemmet.

En annen følge av 3 separate arkiver ser vi når gjør analyser som inluderer AR5 data som er lastet ned via geosync, er at det blir mere spesial behandling.

Under ser vi er kart som viser kommuner vi endte opp med punkter og linjer når vi brukte AR5 i intersection. (Det er enkelt å løse med f.eks å bruke ST_CollectionExtract)

Når man ser på kartet under tyder det også på at det er noen marginale overlap gap også noen andre steder som forventet.

[NilsIvarNes]

Av historiske årsaker forvalter vi FKB-data i lokal UTM sone for å unngå transformasjon av data inn/ut av systemet og potensielle avvik/problemer med dette. For ikke å innføre enda mer usikkerhet i forbindelse med innføring av FKB 5.0 holder vi på denne oppdelingen også i forbindelse med overgang til FKB 5.0, selv om nye transformasjonsbiblioteker bør være så gode at dette ikke lenger er en nødvendighet.

Vi ser at dette skaper en del ekstrajobb i noen sammenhenger og er helt enig i at det på sikt bør være et mål å få til heldekkende baser der data lagres sømløst på nasjonalt nivå.

[larsop]

Av historiske årsaker forvalter vi FKB-data i lokal UTM sone for å unngå transformasjon av data inn/ut av systemet og potensielle avvik/problemer med dette. For ikke å innføre enda mer usikkerhet i forbindelse med innføring av FKB 5.0 holder vi på denne oppdelingen også i forbindelse med overgang til FKB 5.0, selv om nye transformasjonsbiblioteker bør være så gode at dette ikke lenger er en nødvendighet.

Antar at dere ikke bruker eget sktrans bibliotek lenger. Vi bruker opensource bibliteket proj og det er helt riktig det viser testene og det at vi gjør slike transformasjoner hver dag i ar5web over hele Norge. Slik har det vært de siste 2-3 årene ihvertfall.

En liten ting her, siden du nevner det med nøyaktighet. Et design problem i dagens NGIS-OpenApi løsning er vi må sende tilbake linjer som ikke har endret kordinater , men kun har fått en ny node. Det er dette som forårsaker de extreme kravene til nøyaktighet. I Ar5web der vi bruker Postgis Topology har vi ikke dette problemmet fordi vi bare sender tilbake nye linjer fra klienten når det gjøres en endring.

[meastp]

Denne diskusjonen hører hjemme et annet sted. Kanskje du kan flytte denne issue over til repoet for prod/test hos Kartverket, @NilsIvarNes ? Den som har rettigheter i to repoer (som du har?), skal kunne flytte issues fra et repo til et annet.