ÅpentGeosynkAPI i sentral forvaltning av FKB Innspill til viktige avklaringer
Bakgrunn Basert på dokumentet/rapporten «Innspill om bruk av ÅpentGeosynkAPI mot sentral FKB-forvaltning» Rapporten beskriver områder som må på plass før sentral drift med ÅpentGeosynkAPI kan bli en realitet. Dette dreier seg om felt som av ulike årsaker er holdt utenfor standarden, men også om presiseringer og endringer som Norkart ønsker i standarden.
Hovedpunkter GML applikasjonsskjema GML formatering Håndtering av delt geometri Sikkerhet Porsjonering 64 bit heltall Felleskomponenten Bedre feilhåndtering Filtersynkronisering Changelogid bør være uuid Felles diskusjon og avklaringer underveis
GML applikasjonsskjema Skjema som dekker ulike GML-problemstillinger må tidlig på plass F.eks delt geometri og relasjoner Skjemaene må også ha INSPIREID
GML-formatering Tror alle parter i hovedsak er enige om formatet? Siste store hindring var forhåpentligvis Representasjon av delt og heleid geometri All geometri lagres fullstendig inline, uten bruk av referanser All geometri og features skal ha en gml:id som er unik innenfor dokumentet. Denne brukes til å lenke sammen delt geometri for implementasjoner som støtter delt geometri Resultat Tilbyder kan levere en GML-fil som alle abonnenter kan bruke uavhengig av om de støtter delt geometri eller ikke
GML- Delt geometri beskrivelse Gml:id er av typen streng og skal være unik over hele dokumentet Det tilføres ekstra mening til gml::id sånn at den kan brukes til å formidle informasjon som er nødvendig for å bygge opp delt geometri Formatet <QMSqgrug> QMS = Statisk streng som identifiserer at dette er en ID som er generert etter spesielle regler fra QMS qg = QMS intern globalid (uuid, fast størrelse: 36 characters (heksadesimalt format) med bindestreker) r = retning + eller ug = unik globalid Denne innføres for å tilfredstille at Gml:id skal være unik over hele dokumentet
Sikkerhet Standarden definerer ikke hvordan sikkerhet skal håndteres Det er fullt mulig å bygge en god sikkerhetsløsning utenpå standarden Kjapt om foreløpig forslag til sikkerhet All kommunikasjon med https og sftp. Dette er viktig. Bruker henter token med et kall til ekstern autentiseringsløsning Abonnent utfører alle kall med token lagt på i et POST-parameter Tilbyder sjekker gyldighet til token ved hvert kall Token har en gyldighetstid som blir forlenget ved hvert kall Oppnår at aktive kall ikke blir avvist
Sikkerhet Ikke legg for mye i denne figuren! Bare ment som et lite eksempel på hvordan autentisering kan gjøres.
Porsjonering Tilbyderen (for sentraldrift) kan ikke la abonnenten bestemme hvor mange objekt som skal sendes tilbake til abonnenten Standarden tillater å la abonnenten bestemme porsjonstørrelse Dette fungerer dårlig sammen med QMS sin transaksjonsmodell QMS har ett endringsnr per transaksjon Veldig komplisert å returnere deler av en transaksjon Vanskeligjør cache-løsningen (StoredChangeLogs) Porsjonering må skje på abonnenten Abonnenten mottar stor fil fra tilbyder med alle transaksjoner Gunstig for StoredChangelogs Abonnenten velger selv hvilken porsjonstørrelse som leses fra fila
64-bit unsigned heltall I standarden er heltall kun betegnet som integer Dette gjelder f.eks transaksjonsnummeret Vi ønsker at standarden beskriver at heltall skal vare av type 64-bit unsigned integer
Felleskomponenten Felleskomponenten har vært viktig for å «teste» standarden Vi ser på felleskomponenten som en eksempelimplementasjon Felleskomponenten passer ikke inn i arkitekturen til QMS Det er derfor vanskelig for oss å bygge videre på komponenten
Changelogid bør være uuid Changelogid er integer Medfører at vi må hente id er fra sekvens for å oppnå unike id er Bedre med uuid
Bedre feilhåndtering Eksempler Mangler status som indikerer feil, f.eks ved generering av endringsdata Abonnent må få mulighet til å hente ut informasjon om feil Standarden bør utvides med bedre feilhåndtering Ønsker diskusjon med leverandører og Kartverket for å finne god løsning
Filtersynkronisering Ikke fullstendig beskrevet i standarden og det er greit Løses sånn for sentral forvaltning Portal i QMS har en oppgave for hvert kommunepolygon for hvert datasett F.eks 0219Bygg Kommunepolygonet ligger lagret på oppgaven i en komprimert form GetCapabilities returnerer ett datasett for hver oppgave Tilbyder henter polygonfilter ut fra portal Abonnenter har ikke noe forhold til filter
Felles diskusjon og avklaring underveis i prosjektet Problemer vil oppstå som krever diskusjon og avklaring Må ha mulighet til å kalle sammen nødvendige folk fort