Oppsummering fra arbeidet med tekniske avklaringer for implementering av GeoSynkronisering Nils Ivar Nes

Transkript

1 Oppsummering fra arbeidet med tekniske avklaringer for implementering av GeoSynkronisering Nils Ivar Nes

2 På skuldrene til Geosynkroniseringsstandarden v1.0 GML-veileder i Norge digitalt ny versjon juni 2015 WFS-veileder i Norge digitalt GML arbeidsgruppe i Geosynkroniseringsprosjektet 2014 Arbeidet med ny SOSI 5.0 (UMLmodellering og GML)

3 Rapporter på web

4 GML 1: ID-er 1. Alle objekter skal ha egenskapen Identifikasjon (Inspire-Id) Som Lokal-Id skal UUID benyttes Utforming av navnerom kan justeres ut fra vedtak i SOSI Lokal-Id skal inngå som del av GML-ID for features (objekter) slik at det kan refereres med xlink til objekter som ikke inngår i GMLfila

5 GML 2: Assosiasjoner -Prinsippet i Geosynkronisering skal være at det er tilbyder som sørger for konsistens på begge sider av assosiasjonen. Tilbyder kan sende over objekter som peker på objekter som allerede finnes hos abonnenten, eller sendes med i samme transaksjon. -Assosierte features (objekter) sendes som referanser (ikke inline). -Kun endrede objekter sendes over ved synkronisering (dvs. refererte objekter trenger ikke å sendes med så lenge de ikke er endret, og det finnes en unik lokal-id som xlink kan referere til).

6 GML 3: Topoassosiasjoner I GML har slike assosiasjoner ingen tradisjon eller klar mening. Hovedregel: Topo-assosiasjoner skal som hovedregel ikke representeres i GML. Slike assosiasjoner merkes med tagged value «xsdencodingrule:notencoded» i UML. Dataeier må ev. bevisst omgjøre topo-assosiasjoner til vanlige assosisasjoner om disse ønskes representert i GML

7 GML 4: 3D Bruke riktige «kompositt» EPSG-koder for høydebærende data (jf: Dersom det finnes geometri uten høyde i en GML-fil med høyde angis det srsdimension=2 spesifikt for denne geometrien (ikke i tråd med GML-standarden) Dersom det finnes koordinater uten høydeverdi i 3D-geometri brukes verdien NaN (= Not a number ) som høydeverdi i GML.

8 GML 5: Geometrimodell GML-dataene vil basere seg på heleid geometri. I forbindelse med sentral forvaltning vil dataaene forvaltes med delt geometri som tidligere. Ved synkronisering av data ut fra den sentrale forvaltningsbasen vil dataene konverteres til heleid geometri der flatene holder sin egen geometri og avgrensningsobjektene i tillegg sendes med som egne kurveobjekter. For abonnenter som ønsker å gjenoppbygge den delte geometrien vil tilbyderen fra QMS i legge på referanser basert på GML-ID fra flategeometrien til avgrensningslinjene (tilsvarende..ref i SOSI-formatet). De som ikke ønsker å forholde seg til delt geometri kan se bort fra denne informasjonen i GML-fila

9 WFS-kall Insert Replace Update Delete

10 Tema Initielt datasett Filtrering Transformasjon Porsjonering Feilhåndtering Pakking Avklaring Kun opp til tilbyder. Viktig i sentral forvaltning av FKB med tanke på ytelse. Filtrering implementeres i første omgang ikke utover «stored queries» hos tilbyder. Ikke en del av Geosynkronisering, men viktig i sentral forvaltning Til sentral forvaltning legger vi i første versjon ikke opp til at abonnent styrer porsjonsstørrelse. Tilbyder vil sende over alt, men delt opp i mindre/håndterbare GML-filer. I første versjon vil feilmeldinger sendes over som standard SOAP-meldinger med en beskrivende tekst. Gzip-algoritme brukes til pakking av GML ved dataoverføring.

11 Sikkerhet Forslag om bruk av SAML 2.0 (samme som geonorge) Norkart utreder SAML 2.0 vs. andre muligheter og det reelle behovet.

12 Endringer i standarden 2 små endringer i WSDL: 1. Kodeliste for status utvides med «failed». Koden «started» byttes ut med «queued». 2. Identifikasjon av hver spørring (Changelog.ChangelogIdentification) gjøres om fra datatype integer til tekststreng og anbefales implementert som UUID.