Referat fra Workshop NGIS-API

Transkript

1 GeoSynkronisering Referat fra Workshop NGIS-API Sted: Møterom 1 ved Oslo kontoret Tid: kl , 9. desember 2014 Deltakere: Gunstein Vatnar, Norkart AS Randi Wessmann, Norkart AS Harald Lund, Geodata AS Håvard Tobiassen, Geodata AS Lars Eggan, Norconsult Tor Olav Almås, Norconsult Andreas Røstad, Kartverket Nils Ivar Nes, Kartverket Jan Stensby, Kartverket Tone Kristiansen, Kartverket Anne Guro Nøkleby, Kartverket Lars Fredrik Gyland, Kartverket Oppsummering/oppfølgningssaker: - Det er viktig at det kommer snarlig avklaring på om Del1 (tilpasninger på eksisterende løsninger) skal kjøres eller ikke. Avgjørelse på dette området vil ha betydning for om det skal startes opp aktiviteter omkring NGIS-API og QMS tilpasninger. - NGIS-API-et vurderes som egnet for bruk som grensesnitt mot nasjonal forvaltningsløsning for FKB data, forutsatt noen små forbedringer. Server må bli tolerant for null-verdier for påkrevde sammensatte egenskaper og i tillegg bør UUID innføres for objekter. Det er også ønskelig med bedre validering av objekttyper ved innsjekk. - Norkart har støtte for NGIS-API i GisLine. Norconsult har delvis implementert støtte for NGIS API i WinMap programvaren. Geodata har ikke utviklet støtte for NGIS-API i sine systemer. - API-et krever en del utvikling på klientsiden. Dette er en viktig årsak til at Geodata ikke har implementert støtte for NGIS-API i sine applikasjoner. Geodata fremholdt i møtet at GeoSynkronisering referat fra møtet 9/ Side 1 av 10

2 de i utgangspunktet ikke ønsker å implementere støtte for NGIS-API hvis grensesnittet kun skal benyttes i en kortere periode (mens miljøet venter på en fremtidig løsning basert på mer moderne teknologier). - Geodata ønsker at NGIS-API pakkes inn i et mer moderne grensesnitt (som WebService) også i den kortsiktige løsningen. Hvis API-et pakkes inn i et moderne grensesnitt (som også kan legges til grunn for fremtidig løsning i Del 2) så ønsker Geodata å implementere dette i flere produkter. Norconsult støtter dette fullt ut. - Det anbefales at det lages USE CASES for NGIS-API. Brukerbehovet knyttet til kontinuerlig ajourføring av FKB data er ikke nødvendigvis det samme som for kontroll og periodisk ajourføring av dataene. Viktig at brukerscenariene utarbeides før det startes eventuell utvikling eller forbedring av API-et. Det bør også vurderes i denne sammenheng om det er aktuelt å lage en innpakning på deler av API-et, for eksempel grensesnittet for kontinuerlig ajourføring. (Det ble påpekt at kommune også vil kunne ha behov for massiv oppdatering av FKB basert på detaljkartlegging (kan pålegges av kommunen i forbindelse med prosjekter), aktuelt som brukerscenari.)) - Det må opprettes et eget område på Internett med tekniske dokumenter, brukerveiledninger mv for NGIS-API-et Det må være en plass å laste ned alt om NGIS API Det bør sendes ut info om nyheter (tweet?) Testmiljø med alle FKB datasett + historikk - Ønske om endringer/forbedringer på NGIS-API NGIS-API-et bør kompileres for siste Visual Studio (2013) Ønsker endring på obligatoriske sammensatte egenskaper. Ønsker flere sjekker på geometri. Ønsker bedre logging av feilsituasjoner, slik at det er lettere å finne hva som skjer. - Aktiviteter fremover Møte i januar for systemleverandørene. Estimering av arbeidet med implementasjon av GeoSynkronisering mot forvaltningssystemene. Avklaringer omkring GML. GeoSynkronisering referat fra møtet 9/ Side 2 av 10

3 Innledning Lars Fredrik Gyland ønsket velkommen. Formålet med dagens møte er å få en felles teknologisk gjennomgang av NGIS API-et med tanke på eventuell bruk i nasjonal forvaltningsløsning for FKB data. Møtet legges opp som et teknisk møte mellom utviklere fra Norkart, Geodata, Kartverket og Norconsult. Møtet arrangeres i regi av GeoSynkroniseringsprosjektet. Viktige spørsmål for dagens møte er: - Er dagens NGIS - API egnet som felles oppdaterings- API mot nasjonal forvaltningsløsning for FKB? - Hva bør eventuelt forbedres/utvikles på kort sikt? Det er ønskelig med en teknisk vinkling i gjennomgangene. Eventuelle politiske, strategiske og økonomiske forhold knyttet til bruk av NGIS-API bør drøftes i andre fora. Målsetningen med møtet er å få et bedre teknologisk perspektiv (vurdering) av NGIS API-et i forhold til anvendelse som felles API mot fremtidig nasjonal forvaltningsløsning i første omgang for FKB data. Strategi for forvaltning av primærdata i GEOVEKST Anne Guro Nøkleby innledet: Bakgrunnen for at det er ønskelig å se nærmere på forvaltningsløsninger for FKB data er blant annet: Dagens kopiregime er gammeldags Geosynkronisering fra lokale originaler til nasjonal kopi er krevende og krever betydelig manuelt tilleggsarbeid En mer helhetlig og fremtidsrettet modell er diskutert i Geovekst-forum gjennom det siste halvåret Vi er enige om at følgende modell er det vi ønsker å gå for (se skisse på neste side) GeoSynkronisering referat fra møtet 9/ Side 3 av 10

4 Anne Guro presenterte følgende figur: Følgende skisse ble deretter presentert og drøftet NGIS-API benyttes uten større endringer som oppdaterings-api for tilgang til sentral QMS-løsning. Geodatamodellen beholdes uendret. (Ny datamodell som samsvarer med GML er en del av den langsiktige løsningen.) Synkronisering basert på Geosynkoniseringsstandarden benyttes til distribusjon fra sentral base og til å holde lokal kopi i kommunen oppdatert. QMS må støtte Geosynkroniseringsstandarden som tilbyder med både heleid og delt geometri. Som klienter i kommunene benyttes løsninger fra Winmap, GISLINE, ESRI og evt. andre direkte mot sentral base gjennom NGIS-API. Kartverket vil benytte Fysak for kontroller og periodisk ajourhold. Foreløpige planer for 2015 Del 1: Utvikling av første versjon i fremtidig løsning Oppstart og tilrettelegging startes umiddelbart Samarbeid med de viktigste systemleverandørene innenfor felles oppdaterings-api og Geosynkronisering Utvikling av nødvendig tilleggsfunksjonalitet i QMS GeoSynkronisering referat fra møtet 9/ Side 4 av 10

5 Del 2: Utredning av krav til fremtidig løsning Samspill mellom partene Utarbeidelse av kravspesifikasjon og konkurransegrunnlag for sentral løsning, finansiering(!) Evt. kontrakt om kjøp, utvikling etc. 2016/17 Utvikling, testing, implementering 2018/19(???) Strekpunkter fra påfølgende diskusjoner: Norconsult er ikke enig i uttalelsen fra Kartverket om at «Geosynkronisering fra lokale originaler til nasjonal kopi er krevende og krever betydelig manuelt tilleggsarbeid». Det er viktig at det kommer snarlig avklaring på om Del1 (tilpasninger på eksisterende løsninger) skal kjøres som planlagt eller ikke. Teknisk gjennomgang av NGIS API Andreas Røstad orienterte om NGIS-API-et. Foilene fra Andreas Røstad sin presentasjon legges ut på Internett sammen med referatet. For en mer fyldig og teknisk gjennomgang henvises det direkte til foilene. Det er laget følgende dokumentasjon om QMS Overordnet beskrivelse (Quadri Map Server - Overordnet beskrivelse.doc) Datamodeller (Quadri Map Server - Datamodeller.doc) Utviklerhåndbok (Quadri Map Server - Utviklerhåndbok.doc Andreas Røstad gikk først igjennom arkitekturmodell for QMS. QMS består av følgende komponenter: Navnetjeneste, Portal, Objektkatalog og Arkiv. GeoSynkronisering referat fra møtet 9/ Side 5 av 10

6 NGIS API-et består av følgende Geodatamodell (basert på general feature model) - transport av geometriske objekter og deres egenskaper Action-modell (dataoperasjonsmodell) - lagre og endre objekter Query-modell - hente lagrede objekter til geodatamodellen Tilgangs-API over query- og actionmodellene Kommunikasjonsrammeverk som innkapsler det hele Andreas nevnte at geodatamodellen var basert på general feature model. Hovedprinsippene i geodatamodellen for NGIS - API var i stor grad sammenlignbare med hvordan GML beskriver geometrien, men ikke helt identisk. Andreas Røstad orienterte nærmere om tilgang gjennom NGIS API, metoder i datamodellen, pakker i datamodellen, forholdet mellom datamodell og objektkatalog, håndtering av geometri og håndtering av ikke geometriske egenskaper. Røstad orienterte også om spørringer gjennom NGIS- API og resultater fra spørringer. Bruk av NGIS-API som felles oppdateringsgrensesnitt mot nasjonal forvaltningsløsning for FKB data. Forberedte innlegg fra hvert firma (15 min) Nordkart AS - Hva bør eventuelt forbedres/utvikles på kort sikt? - Utfordringer og problemstillinger i forbindelse med implementering av NGIS-API mot egne forvaltningssystemer. NGIS-API og bruk i GISLINE Benytter standard NGIS-API Utsjekk/innsjekk Geografisk område Enkeltobjekter Validering Modellene i QMS benyttes aktivt i GISLINE Objektkatalog fra QMS benyttes aktivt i GISLINE NGIS-API og sentral forvaltning Sentral forvaltning og GISLINE Ingen konkrete endringsbehov i selve API-et Validering Mange nye valideringer på geometri i de siste versjonene av QMS GeoSynkronisering referat fra møtet 9/ Side 6 av 10

7 Ønske: Validering på objekttyper som avgrenser flater InspireId/LOKALID Felles ID mellom objekter i lokal og sentral base Må på plass i produktspesifikasjoner og data GISLINE må tilpasses sentral forvaltning Sentral forvaltning utfordringer generelt Opptegning Må antakelig baseres på lokale kopier? - To ulike utviklingsteam QMS og GisLine. - GsiLine bruker APIet og modellene internt og mot QMS. - Må gjøres tilpasninger i GisLine for smidig bruk mot sentral base. - (Jobber med et WEB-API på toppen av NGIS-APIet.) Geodata AS Innledning ved Håvard Tobiassen Nytt API for oppdatering av sentral forvaltningsløsning for FKB Må støtte arbeidsprosessfokuserte løsninger på klienter på mobilt og Web Løst koplet og tilstandsløst Web API ( XML eller JSON ) Plattform- og klientuavhengighet Utnytte standarder og eksisterende teknologier i størst mulig grad Mest mulig (all) forretningslogikk på server Oppdatering av enkeltobjekt stiller andre krav enn store oppdateringer Ønsker åpne standarder, som f.eks. SOAP, REST Norconsult Innledning ved Lars Eggan Lars Eggan nevnte innledningsvis at Norconsult har allerede laget en NGIS klient i WinMap programvaren sin. Denne klienten henter datasett fra en NGIS portal og oppdaterer portalen med endringer gjort lokalt. Det er også laget spesiell funksjonalitet for å redigere egenskaper i et AR5 datasett. GeoSynkronisering referat fra møtet 9/ Side 7 av 10

8 Lars Eggan refererte videre til foiler som Norconsult (Lars Eggan) hadde presentert på Teknologiforum om NGIS-API i Foilene var fortsatt aktuelle. I forhold til NGIS så var Norconsult i 2008 opptatt av blant annet følgende: Foiler fra 2008 Svært mange klasser og ikke minst nivåer å forholde seg til Må være på riktig nivå for å få gjort det man vil (casting) NGIS API må gjøres tilgjengelig som et.net Assembly i tillegg til dagens C++ biblioteker NGIS-API må gjøres vesentlig mer robust når det gjelder håndtering av feil i inndata Det bør opprettes en nettadresse der siste versjon av API og dokumentasjon til enhver tid er tilgjengelig for alle som utvikler mot NGIS Opprette et forum der brukere av API-et kan utveksle erfaringer og få hjelp til å løse problemer. NGIS Dokumentasjonen må få en vesentlig oppgradering Bygge opp en offisiell utviklerstøtte NGIS API i fremtiden Helst API som service SOAP eller REST Alternativt.net-bibliotek (med overbygning?) Alle kall må være deklarert med alle parametere slik at vi har kontroll på parametere og datatyper. Bør kompileres for siste Visual Studio (2013) Umiddelbare utfordringer Komplekse egenskaper (Struct i NGIS) Serveren bør tillate NULL-verdier dersom struct er opsjonell, mens det finnes påkrevd egenskap inne i struct. (INSPIRE voidable, nilreason) Det må ikke være slik at man skal la være å sende denne tilbake. Da blir det enklere å håndtere slike egenskaper fra systemer som bruker relasjonsbaser. ID-begrep må avklares NGIS må kunne støtte UUID for feature, og kutte all andre ID'er for geometri m.m. NGIS/QMS i dag: QMS opererer med et sett av IDer: GeoSynkronisering referat fra møtet 9/ Side 8 av 10

9 FeatureID SpatialID for QdiSpatialPropertyObject (Punkt / kurve / med mer) SpatialID for QdiComplexSurface SpatialID for QdiBoundary / QdiPath En klient burde kunne forholde seg til kun en ID for et objekt, nemlig FeatureID. Validering Hvor god er NGIS sin geometrvalidering i dag? Dette spesielt mht. delt geometri. NGIS/QMS må kunne si hvor feil oppstår på en bedre måte. Et av hovedutfordringene med oppdateringsapi mot FKB-data er at det er mange datasett som til sammen utgjør mange objekttyper. Dette i motsetning til MatrikkelAPI som har et begrenset antall objekttyper med klare regler. Det finnes en del regler som kun finnes beskrevet i dokument. Reglene må ligge i UML-modellene (Her var det et forslag at regler som ikke kan modelleres bør fjernes fra produktspesifikasjonene) Delt geometri brukes i NGIS Flater peker til linjer Utfordringer mht. til endringslogg Geometrien til linjer referert fra endrede flater skal være med i datasettet. Alle flater som refererer endrede linjer skal være med i datasettet Brukstilfeller Hvordan tenker vi oss at brukeren skal jobbe mot NGIS? Lange transaksjoner, eller forholdsvis korte? Viktig å se på brukstilfelle for bruk av NGIS API på kort sikt. Et mulig brukstilfelle er at man kun sjekker ut de objekt som skal endres (og de objekt som berøres av endring). Dette er tilsvarende MatrikkelAPI. Det er kun tillatt å ha objekter sjekket ut i en begrenset tidsperiode. Fremtidens oppdaterings-api - Det er tjeneste-basert Eksempelvis SOAP, REST - Uavhengig av programmeringsspråk og plattform - Bygger på internasjonale standarder INSPIRE, OGC, ISO etc. - Alt er regelstyrt, basert på UML-modell Eksempelvis GML applikasjonsskjema - Også dekke andre datasett enn FKB Se på løsninger som: GeoGig (tidligere GeoGit)? GeoSynkronisering referat fra møtet 9/ Side 9 av 10

10 OGC GeoSyncronization - Flere dedikerte nasjonal OppdaterinsgAPI (som MatrikkelAPI) - VBASE (allerede definert: REST) - AR5 - Bygning I Matrikkelen? Uansett bør ny datamodell defineres bygd på prinsippene i INSPIRE Building for å få full 3D. - Ønsker.net interface, forenkler den kortsiktige løsningen, men er ikke nødvendig. - Eksisterende API er litt lite robust i feilsituasjoner. - Ønsker endring på obligatoriske sammensatte egenskaper. - Ønsker flere sjekker på geometri. - Ønsker bedre logging av feilsituasjoner, slik at det er lettere å finne hva som skjer. - Hvorfor ikke bruke WFS-T direkte? Drøfting og planlegging av det videre arbeidet med felles oppdateringsgrensesnitt. Lars Fredrik Gyland innledet med å si at GeoSynkroniseringsprosjektet planlegger møte for aktuelle systemleverandører (Norkart, Norconsult, Geodata og Avinet) i januar Formålet med møtet i januar blir å få bedre estimater over arbeidet med implementasjon av GeoSynkronisering i eksisterende forvaltningssystemer, i tillegg er det ønskelig å få landet nødvendige avklaringer vedr GML (geometri, assosiasjoner mv). Felles diskusjon: - Det kan være mulig å wrappe eksisterende API inn i en tjenesteorientert arkitektur. - Helst API som service - SOAP eller REST - Alternativt.net-bibliotek - Alle kall må være deklarert med alle parametre slik at vi har kontroll på parametre og datatyper. - Langsiktig løsningen er WEB-API (REST/SOAP). Funksjonalitet kan ligne mye på dagens NGIS-API. - Må være et generelt API-som handterer alle datatypene. - Spesialiserte fagapplikasjoner kan bygges oppå det generelle API-et. - Diskusjonene rundt implementasjon av API-et er viktig også i den langsiktige løsningen. - Det er viktig å se på bruksmønstre, og lage en arkitektur som samsvarer med dette. GeoSynkronisering referat fra møtet 9/ Side 10 av 10