Geosynkronisering Geosynkronise ring Kommuner GeoNorge / andre portaler Nasjonale tjenester Metadata Visning Nedlasting Deltakende virskomhet 1
Hva er utviklet til nå? Geosynkronise ring Spesifikasjon av utvekslingsformat GML 3.2.1 benyttes som utvekslingsformat for data WFS-T 2.0 benyttes som endringslogg og transaksjons standard Testet med simple feature. Ar5 data, og det er kun simple features som virker i dag. Programvare Utviklet i.net C# Også laget en løsning i java. Koden ligger i CodePlex WebService basert på WCF Testet med Geoserver/Degree som gisserver 2 Testet med PostGreSQL PostGIS som GIS database.
Prosessbeskrivelse Klient kan be om oversikt over data som tilbys via en kjent webadresse/service Klient abonnerer på et datasett Bruker starter bestilling der siste arkiverte endringsindeks for bestillende datasett overføres Det genereres endringsdata basert på forespørsel på siste endringer. Geoserver/Degree generere WFS-T meldinger og GML lages basert på XML skjema beskrivelser. Data pakkes i porsjoner og legges ut på ftp server 3 Klient laster ned zip pakkene etter hvert som de bli klare og pakker de ut og legger data inn i sin base ved hjelp av WFS-T meldingene.
Hva kan Geodata bruke av dette i dag? Vi kan både lage en abonnent- og en tilbyderløsning. Da ArcGIS Server fra versjon 10.3 støtter WFS 2.0 GML 3.2.1 SF-0 ser vi for oss at vi kan bytte ut Geoserver/Degree slik det er satt opp i test i dag og fungere på lik linje som disse. Databasen som kan benyttes kan være en database etablert i PostgreSQL, SQL Server (Express), Oracle etc. og satt opp som Geodatabase. Håndtere endringslogg ved hjelp av triggere i Geodatabasen på lik linje med triggere som benyttes i PostGIS testdatabasen i dag. 4 Basere oss på.net C# koden, justere og optimalisere. Vi utvikler egen klasser som implementerer et interfacet i standarden. Kan trolig arve koden direkte uten store modifikasjoner da WFS-T 2.0 nå støttes.
Hva kan Geodata bruke av dette i dag? Opprette produktspesifikasjoner i som standarden krever Større jobb for en del aktører, men bruker verktøy fra Arkitektum til å bistå dette arbeidet. Kan kun håndtere enkle datamodeller da standarden kun støtter dette. 5
Behov for justeringer? Tja, kan testes i dag, men Piloter må ha enkle datamodeller Ingen assosiasjoner Kodelister håndteres uavhengig av tilbyder og abonnent, dvs. at de inntil videre må settes opp hos abonnenten på egen hånd. Dette bør gjennomføres, da dette var primærmålet i utgangspunktet. Det ekskluderer selvsagt en del aktører som har for avanserte datamodeller. Eventuelt kan disse aktørene forenkle datamodellen i en utvekslingsdatabase slik mange gjør i andre sammenhenger, Ref INSPIRE, ADQ (Aerodome), AIMX osv. 6 ADQ og INSPIRE må Kartverket forholde seg til, så hvorfor ikke se på konsepter og standarder som er definert og er tatt i bruk?
Kritisk å få på plass? Tja, for håndtering av Simple features, så virker det. Forsøk på å gjenspeile komplekse datamodeller i et utvekslingsformat fordyrer konseptet betraktelig. Kartverket som må forvalte standarden, vil risikere å tilpasse konseptet til å kunne støtte en rekke ulike komplekse datamodeller, også nye. Som nevnt tidligere forenkles utveksling av data i mange andre standarder ved å lage en felles forenklet datamodell. Ref ADQ, INSPIRE, AIMX Vinklingen i Geosynkroniseringsprosjektet har blitt å tilpasse standarden til å støtte en rekke eksisterende datamodeller for eksisterende data. Man bør istedenfor fokusere på å lage en forenklet standard datamodell for utveksling for de ulike datatasettene (AR5, Plandata, FKB osv.). 7
Kritisk å få på plass? Vil man ivareta datamodellens kompleksitet fra tilbyder til abonnent bør en lage en GML leser/skriver som håndterer dette da standardprogramvarer (Geoserver, Degree, ArcGIS, FME) ikke direkte håndterer f.eks assosiasjoner. Kartverket bør da forvalte denne «motoren» 8
Så, hva mer må på plass? Håndtering av unike ID-er (GUID) og levetid for objekter er en utfordring som ennå ikke er godt nok dokumentert. Fra kartlegging til levering. System for håndtering av kodelister Håndtere assosiasjoner. GML støtter assosiasjoner. Er dette fortsatt problematisk for WFS-T? Stabilisering Hva med å løse opp dette med ekstra tabeller (n:m) og fremmednøkler (1:1 og 1:n)? 9
Veien videre Lage forenklede datamodeller for utveksling? Da vil konseptet virke uten mer tidkrevende skruing som uansett vil sette bruken av WFS 2.0 på prøve. Utfordring er å håndtere assosiasjoner, men se på muligheten til å bryte ned dette. Lage en egen GML skriver/leser som håndterer komplekse datamodeller? Være en del av standarden tilgjengelig API. Blir et generisk nok til at leverandørene kan bruke det direkte uten mye tilleggskode? 10