Siste oppdatering

Teknisk håndbok for NGIS-plattformen

Denne håndboken tar for seg den tekniske delen av Nasjonalt geografisk informasjonssystem (NGIS). NGIS er en felles plattform for forvaltning av geodata som kommer fra ulike dataeiere, brukere og systemeiere.

Siste oppdatering

Teknisk håndbok for NGIS-plattformen

Denne håndboken tar for seg den tekniske delen av Nasjonalt geografisk informasjonssystem (NGIS). NGIS er en felles plattform for forvaltning av geodata som kommer fra ulike dataeiere, brukere og systemeiere.

Plattformen er egnet for forvaltning av alle typer strukturerte geografiske data. Hovedformålet er at flere dataeiere, brukere og systemeiere fra privat og offentlig sektor kan bidra inn i en felles forvaltning av et datasett. Plattformen kan benyttes på tvers av programvarer/applikasjoner. Ved behov for lagring av lokale kopidata kan disse lagres på tvers av databasene MsSQL og PostGIS.

Plattformen bygger på følgende prinsipper:

  • Modellbasert
  • Åpne API-er
  • Unike ID-er
  • Direkteoppdatering

Plattformen er generell og kan brukes til alle typer geografiske vektordata. Denbaserer seg på at datainnholdet er definert i UML-datamodeller modellert i henhold til standarden for SOSI produktspesifikasjoner. Ut fra UML-datamodellen eksporteres oppsettfiler som definerer og setter krav til datainnholdet i de enkelte datasettene og GML-skjema som setter krav i dataoverføringen inn og ut av systemene gjennom API-ene. Plattformen i seg selv er helt generell og kan brukes til alle typer geografiske vektordata.

Forvaltning av data i NGIS gjøres gjennom maskingrensesnitt (API-er). NGIS-API og NGIS-OpenAPI for oppdatering, og geosynkronisering-API for de som ønsker en kopi av dataene i det lokale forvaltningssystemet.

Alle objekter i NGIS har unike ID-er i form av en UUID. UUID-ene lagres som del av datatypen identifikasjon som egenskapen lokal-ID. Hvert objekt tilordnes en globalt unik lokal-ID. Klienten som oppdaterer data kan sende inn nye objekter med lokal-ID. Hvis det mangler lokal-ID vil NGIS generere dette ved lagring. ID-en følger objektet gjennom hele levetiden, og er grunnlaget for å identifisere objektene i API-ene for å oppdatere og hente data fra systemet.

Lokal-ID identifiserer objektene/forekomstene i kartet/databasen, og ikke objektene i terrenget. Dersom det ønskes unik identifikasjon av objektene i terrenget må dette ordnes med egne ID-er som er modellert for den aktuelle objekttypen.

I tillegg til lokal-ID inneholder datatypen identifikator også egenskapen "navnerom", som skal være en unik identifikasjon av datasettet. Den opsjonelle egenskapen versjon-ID angir versjonen av et objekt. Versjon-ID er viktig for historiske data. NGIS-systemet håndterer navnerom og versjon-ID uten at brukeren trenger å håndtere dette ved oppdateringer.

Plattformen gir mulighet til å styre tilgang til datainnhold både tematisk (avgrenset på datasett- og objekttype-nivå) og geografisk (avgrenset av et område-polygon). Brukere med oppdateringsrettigheter har full tilgang til datainnholdet innenfor gitte rammer, og utfører endringer direkte inn i forvaltningsbasen. Det er ikke lagt inn et ekstra ledd med kvalitetssikring/dokumentasjon av datainnholdet i den enkelte oppdatering. Det vil derfor være viktig at kvaliteten sikres på forhånd, slik at datasettene blir riktige og at brukerfeil unngås.

Kommunikasjonen mellom den sentrale basen og de lokale klientene via API-ene
ARKITEKTUR: Figuren viser kommunikasjonen mellom den sentrale basen og de lokale klientene via API-ene. Illustrasjon: Kartverket.

Oppdatering av data i NGIS-systemet kan gjøres i et utvalg programvarer og apper. All kommunikasjon går gjennom API-ene som beskrevet nedenfor.

Brukeren må først gjennom en tilgangskontroll. Deretter må det velges aktuelt datasett, og innenfor dette de konkrete objekter for redigeringsuttrekk via geografi eller andre utvalgsmetoder. Objektene som velges blir låst for oppdatering fra andre brukere for å unngå konflikter med samtidig redigering. Det blir produsert en datatransaksjon med data for det aktuelle uttrekket, som oversendes til brukeren. Etter fullført redigering i programvare/applikasjon blir uttrekket sjekket inn tilbake i systemet. Ved innsjekk av endringer går dataene gjennom en kontroll etter et gitt sett med regler. Kontrollen kan føre til at innsjekken blir avvist. Ved vellykket innsjekk av data vil uttrekket låses opp så objektene igjen er åpne for redigering av andre brukere.

Data er nå er oppdatert i den sentrale databasen. Hvis applikasjonen bruker et separat innsynsdatasett (lokal kopi) må dette oppdateres. Vanligvis gjøres dette gjennom geosynkronisering. En implementasjon kan også være helt uten visning av dataene, men vise for eksempel et flyfoto, og kun vise dataene ved uttrekk.

Brukeropplevelsen vil være helt avhengig av implementasjonen. Noen implementeringer kan gi brukeren stor grad av valgfrihet i valg av datasett og geografisk område, mens andre implementasjoner er strømlinjeformet og vil i stor grad være innebygget i arbeidsflyten så brukeren knapt merker noe til systemet annet enn den initielle påloggingen.

Quadri Map Server (QMS) er et grunnsystem for lagring og forvaltning av geografiske vektordata som blant annet benyttes på serversiden i NGIS-systemet. Systemet har vært i bruk internt i Kartverket siden 2003, og utvikles og eies i fellesskap av Kartverket og Norkart. Navnetjener, portal, objektkatalog og arkiv er hovedkomponenter i systemet. Dataene organiseres i arkiver, der det blant annet defineres koordinatsystem, geografisk utstrekning, og objekttyper med lovlige egenskaper og geometrier (QMS objektkatalog.) Data lagres i en database (MS-SQL eller PostGIS).

Tilgangen til forvaltningssystemet styres av en navnetjener som ligger på toppen av systemet og styrer riktig forespørsel fra et API til rett portal og arkiv. Tilsgangsstyringen er usynlig for den vanlige bruker. Det er kun oppsettet i portalen en bruker ser når vedkommende logger seg inn og ser sine datasett og tilganger.

Tilgang til arkivene gis gjennom portaler som er satt opp etter datasett, tilgangsnivå og/eller geografi. Portalene håndterer brukere og brukertilganger, og organiserer arkiver i oppgaver og oppgavegrupper, for å gi rett bruker rett tilgang til rett gruppe med arkiver.

All kommunikasjon og alle datatransaksjoner med eksterne brukere, etater, apper og så videre går gjennom tidligere nevnte API-er.

 

Tilgangskontroll består av

  • Autentisering: brukeren må oppgi brukernavn og passord for å bekreftes som autentisk.
  • Autorisering: brukeren må være gitt tilstrekkelig tillatelse for redigering på et gitt datasett og geografi.

Autorisering og autentisering skjer i dag i QMS og administreres av Kartverket. Det arbeides ny løsning for autentisering og autorisering. Dette vil gi økt sikkerhet, med mulighet for multifaktorautentisering gjennom ID-porten, samt ny løsning for autorisering med distribuert administratoransvar.

Det tilbys to API (programmeringsgrensesnitt) for lesing og oppdatering av data i NGIS. API-ene gir også tilgang til en del metadata om data lagret i NGIS. Felles for begge API-ene er at brukeren må være definert i NGIS med tilgang til de aktuelle datasettene for å kunne lese eller oppdatere data. Ta kontakt med brukerstøtte for mer informasjon og tilgang.

4.1.1 NGIS-API

NGIS-API er et C++ API, med tilhørende binær-moduler som må installeres lokalt.

API-et består av disse hovedelementene:

  • En geodatamodell. Denne benyttes for transport av geometriske objekter og deres egenskaper.
  • En action-modell som er en dataoperasjonsmodell. Denne benyttes for å utføre lagring og endring av objekter i arkivet.
  • En query-modell med spørringer for å hente lagrede objekter til geodatamodellen.
  • Et tilgangs-API over query- og action-modellene.
  • Et kommunikasjonsrammeverk som innkapsler det hele.

Data overføres mellom klient og server i en egenutviklet geodatamodell.

API-et har vært i bruk i klientene FYSAK, WInMap og GISLINE i mange år.

Sammenlignet med NGIS-OpenAPI har NGIS-API mer funksjonalitet, men er mer omfattende å programmere mot.

4.1.2 NGIS-OpenAPI

NGIS OpenAPI er et tjenestebasert grensesnitt basert på OpenAPI og REST. API-et er under stadig utvikling og forbedring.

Grov oversikt over funksjonalitet:

  • Hente liste over tilgjengelige datasett
  • Hente metadata for et bestemt datasett
  • Hente data fra et bestemt datasett
    • Med lesetilgang eller skrivetilgang (medfører låsing)
      • Områdebegrensning
      • Egenskapsspørring (begrenset i første versjon til bygningsnummer eller lokalid)
  • Lagre data til et bestemt datasett
    • Operasjoner som håndteres: nytt objekt, endre (erstatte) objekt og slett objekt

Data overføres mellom klient og server på GML- eller GeoJSON-format, og oppdateringene er pakket inn som WFS-T-transaksjoner.

Mer informasjon er tilgjengelig på GitHub.

NGIS-systemet støtter overføring av endringsdata med geosynkroniserings-API. Dette er et API som er dokumentert i geosynkronisering-standarden og baserer seg på rollene «Tilbyder» og «Abonnent». Konseptet er at abonnentene spør tilbyder om oppdaterte data etter et gitt transaksjonsnummer så ofte de ønsker. Tilbyder vil da svare «ingen endring siden sist» eller sende over oppdatert transaksjonsnummer sammen med de endrede dataene.

Selve dataoverføringen skjer i geosynkronisering som WFS-T-transaksjoner med data på GML-format. Se standardiseringsdokumentasjon for geosynkronisering for mer informasjon.

NGIS-systemet inneholder tilbyder-tjenester på mange nivåer, både kommunedelt, fylkesdelt og landsdelt kan være aktuelt. Dette varierer litt for ulike datasett.

4.2.1 Geosynkronisering fra NGIS

For å kunne synkronisere data fra NGIS-systemet trengs følgende:

  1. En geosynkroniseringsabonnent (programvare, se under).
  2. Navn på webtjeneste (eks: http://qmstst01.statkart.no:6019/)
  3. Brukernavn og passord som gir tilgang til webtjenesten. Kommunikasjon skjer på https og medfører ikke behov for åpning av porter (andre enn standard porter for http/https-kommunikasjon) i brannmuren.

4.2.2 Programvare som støtter geosynkronisering

Det finnes open source programvare som støtter geosynkronisering-standarden. Se kildekode og dokumentasjon på GitHub.

I tillegg har flere av de store leverandørene av GIS-programvare i Norge programvare som støtter geosynkroniseringen. Denne programvaren er i varierende grad basert på open source komponentene.

NGIS-systemet gjør en teknisk validering av dataene ved alle oppdateringstransaksjoner. Dersom valideringen avdekker avvik fra kravene på noen av dataene i en oppdateringstransaksjon blir hele transaksjonen avvist og ingenting oppdatert i systemet.

Hva som er lovlige objekttyper/geometrityper/egenskaper/egenskapsverdier valideres mot det som er definert i objektkatalogen til datasettet i NGIS (som igjen er generert fra UML-modellen). Dataene må være i henhold til følgende krav:

  • Objektene må være av en objekttype som er definert i objektkatalogen
  • Objektene må peke til en geometritype som er definert på objekttypen
  • Egenskapene må peke til en egenskap som er definert på objekttypen. Ukjente egenskaper (uten peker til lovlig egenskap) avvises
  • Obligatoriske egenskaper må finnes på objektene
  • Egenskapsverdier må være gyldig i forhold til eventuelle beskrankninger gitt i UML-modellen
  • Dato- og datotid-egenskaper må ha lovlige verdier
  • DATAFANGSTDATO og VERIFISERINGSDATO kan ikke være framtidige datoer
  • Kodeliste-egenskaper må ha verdi som finnes i tilhørende kodeliste
  • Egenskapen LOKALID skal være en UUID (bestå av 36 av følgende tegn ^[a-fA-F0- 9-]+$) og må være unik
  • Kontroll av lovlige XML-tegn på tekststreng-egenskaper

NGIS er satt opp med 0,1 mm oppløsning i databasen. Det er denne verdien som benyttes ved beregning av om geometri er lik/forskjellig i alle geometrivalideringene (det vil si at punkter regnes som like dersom de er nærmere hverandre enn 0,1 mm). Dataene må være i henhold til følgende krav:

  • Kurver må bestå av minst 2 punkter og ha lengde > 0.
  • Kurver kan ikke inneholde dobbeltpunkter (benytter databasens oppløsning som grenseverdi)
  • Kurver kan ikke overlappe seg selv i to eller flere etterfølgende punkter (egenkryssing i ett punkt er altså tillatt).
  • Det kan ikke være gap mellom kurver som avgrenser en flate (benytter databasens oppløsning som grenseverdi).
  • Representasjonspunkt i flate må ligger innenfor flatens avgrensning, eller være identisk med ett av grensepunktene.
  • Avgrensningen til en flate kan ikke krysse seg selv. Egenkrysning av kurver er altså ikke lov om de inngår i avgrensning av en flate.
  • Hull (indre avgrensning) i en flate må ligge innenfor flatens ytre avgrensning. Tangering av ytre avgrensning i ett punkt er tillatt.
  • Hull (indre avgrensning) i en flate kan ikke overlappe andre hull i samme flate. To hull kan tangere hverandre i ett punkt.
  • Dataenes koordinatverdier må være innenfor utstrekning definert i arkiv og oppgave. Dette gjelder i grunnriss for alle arkiver og for høyde der min/maks høyde er angitt. For arkiver som er satt opp uten definering av vertikaldatum vil data med høyde avvises.

Det er satt opp testmiljøer som er tilgjengelige for eksterne utviklere.

Ta kontakt med brukerstøtte for mer informasjon.

XPPT