Veileder for Geography Markup Language (GML) <UTKAST>

Transkript

1 <UTKAST> Tittel: Veileder for Geography Markup Language (GML) Utarbeidet av: Norge digitalt Søkeord: Veileder, Geography Markup Language, GML, Web Feature Service, WFS, NSDI, SDI, Infrastruktur for stedfestet informasjon, Norge digitalt. Opplagstall: 1 elektronisk Versjon: 0.43 Dato: Dok. status: Utkast

2 Revisjonshistorikk Versjon Produsert av Dato Endring Initiell versjon Lagt til flere delkapitler basert på mottatte forslag, korrigert tekst etter GML-møte Tatt inn ny tekst og endret struktur iht innkomne forslag Tatt vekk tomme kapitler, justert tekst og struktur iht innkomne forslag fra siste arbeidsmøte, satt inn figurer/illustrasjoner, m.m Lagt inn ref til INSPIRE objektkatalog Lagt inn justeringer for innkomne kommentarer Oppdatert linker til ny nasjonal geoportal

3 Innholdsfortegnelse Revisjonshistorikk... 2 Innholdsfortegnelse Forord Innledning Formål Målgruppe Dokumentets oppbygning Forholdet til andre dokumenter Ord og begreper Grunnleggende om GML Hva er GML? Objekttyper og objekter Objektmodell Versjoner GML og WFS GML vs. SOSI-formatet Slik fungerer de tekniske mekanismene i GML (T) Kvalitetsnivåer og validering (T) Geometri (T) GML og koordinatsystemer (T) GML-profiler (T) GML og navnerom (T) Bruke GML Bruksområder for GML GML og geometri i Norge Norge digitalt konformitetsnivåer Forholdet til BIM Bruk av kodelister (T) Identifikatorer (T) Definisjons- og merknadsangivelser i GML (T) Bruk av XLink (T) Støtte for flere språk (T) Versjon

4 5.10 Kvalitetskontroll Plassering av applikasjonsskjemaer, eksterne kodelister m.m. (T) Koordinatsystemer (T) Norsk profil av GML (T) FeatureCollection (T) Topologi (T) Tidsangivelser (T) Tematiske flatedekkende representasjoner (coverage) (T) Programvare Programvare for editering av GML-filer Programvare for visning av GML-fil som kartbilde Programvare for å tilby WFS-tjenester med GML-respons Programvare for å validere GML-filer (T) Geometrityper for nasjonalt harmoniserte datasett (T) Geometrityper for INSPIRE-harmoniserte datasett (T) Krav og anbefalinger Krav Anbefalinger Figurliste Vedlegg A Brukstilfeller og eksempler A.1 Se på innholdet i en GML-fil A.2 Endre innhold i en GML-fil A.3 Validere en GML-fil A.4 Lage en GML-fil fra et datasett A.5 Konvertere et datasett fra SOSI til GML A.6 Konvertere et datasett fra Shape til GML A.7 Dele GML-filer med nasjonale parter A.8 Dele GML-filer med institusjoner i andre land A.9 Bestille objektinformasjon som GML fra en WFS-tjeneste A.10 Bestille objektinformasjon som GML fra WMS getfeatureinfo A.11 Bestille coverage som inneholder GML-elementer A.12 Bruke GML i WFS-T Insert, Update, Replace eller Delete A.13 Bestille objekter som GML fra en SOAP WebService A.14 Eksempler på GML med delt og heleid geometri (T) A.15 Opprette eller endre et GML-applikasjonsskjema (T) Vedlegg B Eksempel på Schematronfil med topologiske regler (T) Versjon

5 Vedlegg C Eksempel på interne Schematronregler i GML-applikasjonsskjema (T) Vedlegg D Lage en GML-eksempelfil (T) Kapitler merket med (T) er tekniske kapitler beregnet for systemutviklere, leverandører og andre som ønsker å implementere teknologien. Versjon

6 1 Forord Dette veilederdokumentet er 1 av en rekke veiledningsdokumenter i Norge digitalt. Veilederdokumentene er tilgjengelige for alle partene i Norge digitalt fra GML-veilederen er utarbeidet av Geodatakoordinatorseksjonen i Kartverket sammen med en arbeidsgruppe bestående av representanter for programvareleverandører og parter i Norge digitalt. Gruppa hadde som mandat å utarbeide en GML-veileder tilpasset Norge digitalt-samarbeidet. Veilederen blir i ferdig versjon overlevert Geodatakoordinatorseksjonen i Kartverket. De vil stå for enkelt vedlikehold og sørge for at den er tilgjengelig. Større revisjoner av veilederen er tenkt gjort ved at man setter ned en ny arbeidsgruppe. Det er partene i Norge digitalt-samarbeidet som eier veilederen og innholdet i den. Ønske om revisjoner kan tas opp av alle parter i samarbeidet og av programvareleverandørene ved å kontakte Geodatakoordinatorseksjonen i Kartverkets eller ved å ta det opp i Teknologiforum. Veilederen er delt inn i en kortfattet introduksjon til GML, deretter egne kapitler som belyser bruk av GML fra ulike vinkler. Beslutningstakere kan med fordel lese introduksjonen til GML ( Hva er GML? ). Versjon

7 2 Innledning Dette dokumentet er laget med en praktisk tilnærming, med mange konkrete eksempler. Eksemplene kan med fordel prøvekjøres for å øke forståelsen av hvordan GML kan og bør brukes. 2.1 Formål Fremme bruk av GML for utveksling av geografisk informasjon i leveranser og tjenester. Beskrive retningslinjer for bruk av GML som er i tråd med den internasjonale standarden OGC/ISO19136, Geodataloven/Geodataforskriften samt INSPIREs tekniske krav og retningslinjer. Belyse primære bruksområder for GML. Anbefale implementasjonsmåter. Belyse sammenhengen mellom andre formater og GML. 2.2 Målgruppe Norge digitalt partene og systemleverandører. 2.3 Dokumentets oppbygning Dokumentet gir først en generell introduksjon til GML og hvordan det fungerer rent teknisk. Videre er det også forklart hvordan man bør bruke GML i praksis og spesielt innenfor Norge digitalt. Dokumentet inneholder også et eget kapittel med brukstilfeller og eksempler. De krav og anbefalinger som gjelder ved bruk av GML er listet mot slutten av dokumentet. 2.4 Forholdet til andre dokumenter Denne veilederen bygger blant annet på OGC og ISO standarden for GML OGC/ISO19136 ( og GML 3.3 ( Versjon

8 Den ivaretar også de krav som stilles i Geodataloven/forskriften ( Veilederen bygger også på Rammeverksdokumentet ( Skissen under viser sammenhengen mellom de ulike standardene, dokumentene og lover/forskrifter. Figur 1 - Sammenhengen mellom de ulike veilederdokumentene og relaterte dokumenter Versjon

9 3 Ord og begreper BIM FE Geodata Geodatasett Geografisk objekt GFM GML Applikasjonsskjema Geodatatjeneste GMLapplikasjonsskjema GML-fil GML-skjema Infrastruktur for geografisk informasjon ISO Metadata OCL Datamodell (for beskrivelse av data tilhørende en applikasjon eller et fagdomene). På dataformatuavhengig nivå brukes ofte UML. På datafomatsnivå med XML, er applikasjonsskjemaet beskrevet som XSD. Building Information Model. Model som følger av en prosess med å spesifisere en bygnings karakteristikker forut for en byggeprosess. Filter Encoding International Standard beskriver spørring mot databaser vha XML (NS-EN ISO 19143). Data i elektronisk form med direkte eller indirekte referanse til et bestemt sted eller geografisk område. Identifiserbar samling av geodata. Operasjoner som kan utføres ved å opprette en forbindelse ved hjelp av et dataprogram, på geodata i geodatasett eller på tilknyttede metadata. Abstrakt representasjon av et virkelig fenomen knyttet til et bestemt sted eller geografisk område. General Feature Model. Geographic Markup Language (GML) beskriver geografiske data vha XML. GML er en ISO-standard (NS-EN ISO 19136). Datamodell beskrevet i GML. XML-fil med objektinformasjon angitt i GML. Grunnleggende geografiske objekttyper definert i GML-standarden (NS-EN ISO 19136). Det finnes en rekke GML-skjemaer som hver definerer ulike geografiske objekttyper. Fundament for tilgang til og anvendelse av geodata. International Standardization Organization. Informasjon som beskriver geodatasett og geodatatjenester, og som gjør det mulig å finne fram til, liste opp og bruke geodata. Object Constraint Language. Språk for å spesifisere vilkår og beskrankninger i en UML datamodell. Versjon

10 OGC SOSI SOSI-format UML UMLapplikasjonsskjema UTF-8 UUID WFS WFS-T WMS XML XSD Open GIS Consortium. SOSI (Samordnet Opplegg for Stedfestet Informasjon) er en norsk standard for utveksling av digitale kartdata. Norsk format for utveksling av geografisk informasjon. Unified Modeling Language. Modelleringsspråk for å lage datamodeller med mulighet for å fremstille disse grafisk. Datamodell som er beskrevet i modelleringsspråket UML. Også kalt applikasjonsskjemapakke i modelleringsarbeidet. Tegnkoding som dekker alle Unicode tegn, og som i praksis dekker alle europeiske tegn. Universell Unik Identifikator. Identifikator som brukes på geografiske objekter og som består av domenets URL og en lokal identifikator som er generert ut fra spesifiserte regler (se Rammeverksdokumentet). <TODO - som beskrevet i ISO/IEC 11578:1996 "Information technology Open Systems Interconnection Remote Procedure Call (RPC)" og nyere versjon i ITU-T Rec. X.667 ISO/IEC :2005> Web Feature Service er en tjenestetype for tilgang til geografiske data (GML) beskrevet med et XML-grensesnitt (ISO 19142). WFS Transactional gir i tillegg til funksjonaliteten i WFS, også metoder for innlegging, oppdatering og sletting av geografiske data (ISO 19142). Web Map Service (WMS) er en tjeneste som leverer kartbilder og egenskapsinformasjon om kartobjekter (ISO 19128). Extensible Markup Language (XML) er et språk for å kommunisere mellom maskiner. XML Schema Definition (XSD) definerer gyldige elementer og typer i et XML-dokument vha XML. Også kalt XML skjema. Versjon

11 4 Grunnleggende om GML Dette kapitlet belyser de grunnleggende sidene ved GML når det gjelder oppbygning, forholdet til standarder, virkemåte og forholdet til sentrale tjenestetyper. 4.1 Hva er GML? GML er et XML-basert format for utveksling av geografisk informasjon. GML er spesifisert av OGC og senere standardisert av ISO for GML OGC/ISO19136 ( Som med de fleste XML-baserte formater, består også GML av 2 hoveddeler: - Regelbeskrivelser (GML-skjemaer og GML-applikasjonsskjemaer) - Datadokument (GML-fil) Ved bruk av regelbeskrivelsene for GML (GML-skjemaene) kan man lage enkle GML-filer som inneholder geografiske objekter med punkter, linjer, polygoner eller andre grunnleggende geometrier. Men ofte er det ikke nok å beskrive geografiske objekter med kun de enkle geometriske figurene som for eksempel punkt og linje. Hva med en motorveg eller en bygning? Dette kan løses ved å lage GML-applikasjonsskjemaer. Her kan man bruke GML-skjemaenes innhold og definere nye og mer komplekse geografiske objekttyper, som f.eks bygning som kan bestå av en rekke punkter, linjer, polygoner, sirkler osv. Når man først har laget et GML-applikasjonsskjema, kan også andre som ønsker å bruke GML-filer som er laget i samsvar med dette GML-applikasjonsskjemaet, vite sikkert at datastrukturen er ivaretatt når de mottar og bruker GML-dataene. Versjon

12 Figur 2 - Grunnsteinene i GML 4.2 Objekttyper og objekter I praktisk bruk består GML av objekttyper og objekter. Disse brukes på hver sine måter og i ulike sammenhenger, men også sammen. I et GML-applikasjonsskjema defineres objekttypene man ønsker å bruke i det enkelte datasettet. Objekttyper er definisjonene av datastrukturen og krav til innhold i objektene. Disse definisjonene spesifiseres ved bruk av tekstlige, numeriske og geometriske egenskapsfelter. Objektene på sin side er selve databærerne der verdiene er plassert i henhold til den datastrukturen som er definert i objekttypen. Objektene er i realiteten kun tekstlige lister av egenskaper, samt geometri. Versjon

13 Figur 3 - Prinsippet i forholdet mellom objekttyper og objekter I forenklet GML vil dette kunne se slik ut: Figur 4 - Definisjon av objekttype med tilhørende objekt 4.3 Objektmodell En objektmodell sier noe om hvilken virkelighetsfortolkning man baserer seg på, og hvordan denne skal fremstilles i datamodeller. GML baserer seg på en objektmodel som heter General Feature Model (GFM) som er beskrevet i ISO-standarden ISO19109 ( GFM beskriver Versjon

14 blant annet grunnleggende geometrityper og topologi. INSPIRE beskriver også hvilke hensyn til objektmodeller som ligger til grunn ved bruk av GML, blant annet GFM. Mer om dette i GFM er også objektmodellen for SOSI objektaktalogen, og er således utgangspunktet for både SOSI-syntaksrealisering og GML-applikasjonsskjemaene. Figur 5 - De overordnede elementene i General Feature Model <TODO - Denne forstår ikke jeg. Hvis den skal være med må det inn en forklaring av figuren.> 4.4 Versjoner GML finnes i flere versjoner. Pr. dato eksisterer følgende versjoner: Versjon Årstall OGCspesifikasjon ISOstandard JA NEI JA NEI JA JA JA 2014? Veilederen forholder seg til versjon samt (denne inneholder bare utvidelser jfr 3.2.1, for eksempel coverage). Versjon

15 4.5 GML og WFS GML brukes blant annet i responsen fra WFS-tjenester som et format for å beskrive de geografiske objektene. Det er laget en egen veileder for bruk av WFS i Norge digitalt, se GML vs. SOSI-formatet SOSI-formatet er det norske vektorformatet for utveksling av geografisk informasjon. GML er et internasjonalt format for samme formål. SOSI-formatet er fortsatt det mest anvendte formatet i Norge, mens GML i løpet av kort tid må kunne leveres av partene i Norge digitalt for å imøtekomme kravene i Geodataloven. Partene må derfor forberede seg på å kunne levere sine data i GML-formatet innen tidsfristene som følger av Geodataloven, se Veileder for leveranser i Norge digitalt ( 4.7 Slik fungerer de tekniske mekanismene i GML (T) For å kunne bruke objekttypene og objektene i sammenheng, er altså GML i hovedsak bygget opp av 3 hoveddeler: GML-skjemaer (i formatet XML uttrykt som XSD) GML-applikasjonsskjemaer (i formatet XML uttrykt som XSD) GML-objekter (i formatet XML uttrykt som GML) Disse 3 hoveddelene er alle XML-filer, og relatert til hverandre slik skissen under viser. Versjon

16 Figur 6 - Hovedrelasjonsprinsippene i GML I en virkelig verden har man ofte behov for å bruke GML på en ytterligere forsterket måte. Det finnes derfor flere mekanismer som man med GML kan dra nytte av. De mer detaljerte relasjonsprinsippene i GML vises i skissen under. Versjon

17 Figur 7 - Detaljerte relasjonsprinsipper i GML Siden GML er XML-basert, inneholder GML mekanismer for å definere den datastrukturen som skal være mulig å beskrive i GML-objektene (objektene). De 2 førstnevnte elementene (GML-skjemaene og GML-applikasjonsskjemaene) benyttes for å definere datastrukturen i et GML-objekt. Selve GML-filen er stedet der vi finner objektene med tilhørende egenskapsverdier, gjerne omtalt som datafil i andre sammenhenger. En GML-fil refererer i praksis alltid til 1 eller flere GML-applikasjonsskjemaer, og dette referer igjen til 1 eller flere GML-skjemaer GML-skjemaer (T) Et GML-skjema er en samling XSD-beskrivelser av generelle geografiske objekter med tilhørende egenskaper. Disse har ofte (men ikke nødvendigvis) geometri, slik som punkt, linje, polygon osv. GML-skjemaene opprettes, endres og forvaltes av OGC. Man kan se på GMLskjemaer som et bibliotek over grunnleggende geografiske objekttyper for GML. Disse objekttypene tilsvarer mange av de man finner i blant annet SOSI. Disse ferdige definerte objekttypene kan brukes direkte i GML-applikasjonsskjemaet, men man kan også bruke de til å definere nye mer komplekse sammensatte objekttyper i GML-applikasjonsskjemaet, som f.eks objekttypen Tiltak som består av polygoner, linjer og punkter. GML-skjemaer er organisert innenfor samme navnerom, nærmere bestemt eller slik Versjon

18 dette er spesifisert i NS-EN ISO GML. GML-skjemaene består av skjemaer for objekttyper geometriske primitiver topologi tidsaspektet (temporal) definisjoner og kataloger enhet/mål og verdier (UoM) koordinatreferansesystem retning (directions) observasjoner coverages (GML 3.3) GML-skjemaene som inngår i standarden i versjon <TODO listen tas vekk?>: basictypes.xsd coordinateoperations.xsd coordinatereferencesystems.xsd coordinatesystems.xsd coverage.xsd datums.xsd defaultstyle.xsd deprecatedtypes.xsd dictionary.xsd direction.xsd dynamicfeature.xsd feature.xsd geometryaggregates.xsd geometrybasic0d1d.xsd geometrybasic2d.xsd geometrycomplexes.xsd geometryprimitives.xsd gml.xsd Versjon

19 gmlbase.xsd grids.xsd measures.xsd observation.xsd referencesystems.xsd temporal.xsd temporalreferencesystems.xsd temporaltopology.xsd topology.xsd units.xsd valueobjects.xsd GML-applikasjonsskjemaer (T) Et GML-applikasjonsskjema er XML-beskrivelser av objekttyper, ofte basert på en UML-datamodell. GML-applikasjonsskjemaer opprettes, endres og forvaltes innen det enkelte domene (bedrift/organisasjon). Men tanken er at de også skal registreres i sentralt register for Norge digitalt slik at andre kan benytte de. Et GML-applikasjonsskjema er ikke i seg selv GML, men beskrevet med XMLskjemaer (XSD). Ved bruk av XSD beskrives datastrukturen for GML-objektene innenfor det angitte domenet. Et GML-applikasjonsskjema refererer alltid til 1 eller flere GML-skjemaer, men kan også referere til 1 eller flere andre GML-applikasjonsskjemaer. Det er programvaren som håndterer GML-applikasjonsskjemaene. Brukeren trenger altså ikke å forholde seg til GML-applikasjonsskjemaer dersom man bare skal åpne en GML-fil eller se på dataene. Men dersom GML-filen ikke validerer i programvaren, kan det være greit å vite at dette skyldes ulikheter mellom GMLapplikasjonsskjemaets definisjoner og de faktiske verdiene eller objektstrukturen i GML-filen. I arbeidet med produktspesifikasjoner i Norge digitalt opprettes GMLapplikasjonsskjemaer via programvare (for tiden ShapeChange) som kan generere det fra et UML-applikasjonsskjema. GML-applikasjonsskjemaer forvaltes av den enkelte organisasjon og skal registreres i sentralt register i Norge digitalt ( Versjon

20 For automatisk generering av GML-applikasjonsskjemaer vises det til egne veiledere for utarbeidelse av produktspesifikasjoner, ref. På samme måte vil endring av et eksisterende GML-applikasjonsskjema oftest skje ved at man oppdaterer sin UML-datamodell, og deretter regenererer GMLapplikasjonsskjemaet automatisk via programvare for dette. Et GML-applikasjonsskjema består generelt av følgende deler: Deklarasjoner av navnerom og plassering for GML-skjema(ene) Referanser til evt andre GML-apllikasjonsskjemaer Definisjoner av interne kodelister Eventuelt referanser til eksterne kodelister Definisjoner av objekttyper Eventuelt referanser til objekttyper i refererte GML-skjemaer/GMLapplikasjonsskjemaer Versjon

21 Eksempel på et GML-applikasjonsskjema for objekttypen GrenseSjø definert fra SOSI objektkatalog. Eksempelet går over 3 sider, der hver side inneholder egne deler av GML-applikasjonsskjemaet. Alle 3 delene henger sammen i 1 fil. <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" xmlns:app=" " xmlns:gml=" elementformdefault="qualified" targetnamespace=" nser/2012-1" version=" april"> <import namespace=" schemalocation=" <simpletype name="landkodetype"> <documentation>navn på land med tilhørende alfanumerisk kode som definert i ISO 3166 Codes for the representation of names of countries and their subdivisions -- Definition - - name of country with appurtenant alphanumeric code as defined in ISO 3166 Codes for the representation of names of countries and their subdivisions </documentation> <union membertypes="app:landkodeenumerationtype app:landkodeothertype"/> </simpletype> <simpletype name="landkodeenumerationtype"> <documentation> navn på land med tilhørende alfanumerisk kode som definert i ISO 3166 Codes for the representation of names of countries and their subdivisions -- Definition - - name of country with appurtenant alphanumeric code as defined in ISO 3166 Codes for the representation of names of countries and their subdivisions </documentation> <restriction base="string"> <enumeration value="bv"/> <enumeration value="dk"/> <enumeration value="fo"/> <enumeration value="is"/> <enumeration value="gl"/> <enumeration value="no"/> <enumeration value="ru"/> <enumeration value="sj"/> <enumeration value="se"/> <enumeration value="gb"/> </restriction> </simpletype> <simpletype name="landkodeothertype"> <restriction base="string"> <pattern value="other: \w{2,}"/> </restriction> </simpletype> Definisjon av intern kodeliste Versjon

22 <element abstract="true" name="sosi_objekt_nmg_grenser" substitutiongroup="gml:abstractfeature" type="app:sosi_objekt_nmg_grensertype"/> <complextype abstract="true" name="sosi_objekt_nmg_grensertype"> <complexcontent> <extension base="gml:abstractfeaturetype"> <sequence> <element minoccurs="0" name="datafangstdato" type="datetime"> <documentation> for fastsatte grenser/flater er datafangstdato det samme som vedtaksdato eller dato for undertegning av traktat eller avtale </documentation> </element> <element name="oppdateringsdato" type="datetime"/> <element name="kvalitet"> <documentation>produktspesifikasjon: gjelder ikke data fra Norsk polarinstitutt (kystkontur) </documentation> </element> <element maxoccurs="unbounded" name="status"/> <element minoccurs="0" name="gyldigfra" type="datetime"> <documentation>dato for ikrafttredelse av lov, forskrift eller traktat </documentation> </element> <element maxoccurs="unbounded" minoccurs="0" name="informasjon" type="string"> <documentation>offisiell definisjon samt annen informasjon</documentation> </element> <element maxoccurs="unbounded" minoccurs="0" name="link"> <documentation>link til lov, forskrift eller traktat</documentation> </element> <element maxoccurs="unbounded" name="navn" type="string"/> <element maxoccurs="unbounded" minoccurs="0" name="lovref" type="string"> <documentation>produktspesifikasjon: henviser til lover, forskrifter eller traktater </documentation> </element> <element maxoccurs="unbounded" name="landkode" type="app:landkodetype"/> </sequence> </extension> </complexcontent> </complextype> Definisjon av generell SOSI objekttype Versjon

23 <element name="grensesjø" substitutiongroup="app:sosi_objekt_nmg_grenser" type="app:grensesjøtype"> <documentation>grenselinjer i sjø --Definition-- boundry line at sea Note:Economic zone, fishery protection zone and centerlines </documentation> </element> <complextype name="grensesjøtype"> <complexcontent> <extension base="app:sosi_objekt_nmg_grensertype"> <sequence> <element name="grense" type="gml:curvepropertytype"> <documentation>forløp som følger objektets sentrale del -- Definition -- cource follwed by the central part of the object </documentation> </element> <element name="grensetypesjø"/> <element minoccurs="0" name="gyldigtil" type="datetime"/> </sequence> </extension> </complexcontent> </complextype> <complextype name="grensesjøpropertytype"> <sequence minoccurs="0"> <element ref="app:grensesjø"/> </sequence> <attributegroup ref="gml:associationattributegroup"/> <attributegroup ref="gml:ownershipattributegroup"/> </complextype> </schema> Definisjon av objekttypen GrenseSjø GML-filer (T) GML-filer er der selve GML-objektene blir angitt. Det er disse filene som kan vises i GIS-programvare som et kartbilde. GML-filen inneholder referanser til GML-applikasjonsskjemaet og evt til Schematronfil(er). I tillegg kan GML-filen inneholde interne eller eksterne referanser til XML-elementer ved bruk av XLink GML-objekter (T) I GML-filen finner vi GML-objektene. Et GML-objekt omtales også som bare objekt. Alle objekter har egenskapsverdier. Det enkelte objekt refererer til minst ett tilhørende GML-applikasjonsskjema som beskriver den tillatte objektstrukturen i GML-filen. GML-applikasjonsskjemaet referer igjen til ett eller flere GML-skjemaer som inneholder definisjoner av geometriske og topologiske primitiver, koordinatreferansesystemer, etc. Navneromsangivelsene i starten av GML-filen angir vanligvis hvilken versjon av GML som er brukt. Versjon

24 En GML-fil er bygget opp på følgende måte: Deklarasjoner av navnerom og plassering for GMLapplikasjonsskjema(ene) Opplisting av det enkelte objekt med tilhørende egenskaper Et eksempel på innhold i en GML-fil kan se slik ut (utdrag): <?xml version="1.0" encoding="utf-8"?> <gml:featurecollection xmlns=" xmlns:xlink=" xmlns:gml=" xmlns:xsi=" gml:id="no.sk.nmg.v2012-1" xsi:schemalocation=" Grenser/ <!-- Eksempel på heleid primitiv geometriegenskap med GML 3.2 med full speiling av primitiv-klassene i ISO19107 geometrimodell --> <gml:boundedby> <gml:envelope srsname="urn:ogc:def:crs:epsg::4258"> <gml:lowercorner> </gml:lowerCorner> <gml:uppercorner> </gml:upperCorner> </gml:envelope> </gml:boundedby>... <gml:featuremember> <GrenseSjø gml:id="no.sk.nmg "> <datafangstdato> t11:00:00z</datafangstdato> <oppdateringsdato> t11:00:00z</oppdateringsdato> <kvalitet> <Posisjonskvalitet> <målemetode codespace=" enser/2012-1/målemetode.xml">11</målemetode> <nøyaktighet>13</nøyaktighet> </Posisjonskvalitet> </kvalitet> <status codespace=" enser/2012-1/status.xml">v</status> <navn>fiskerisonegrensen Z</navn> <landkode>no</landkode> <grense> <gml:curve srsname="urn:ogc:def:crs:epsg::4258" gml:id="no.sk.nmg.c444444"> <gml:segments> <gml:linestringsegment interpolation="linear"> <gml:poslist> </gml:posList> </gml:linestringsegment> </gml:segments> </gml:curve> </grense> <grensetypesjø codespace=" enser/2012-1/grensetypesjø.xml">v</grensetypesjø> </GrenseSjø> </gml:featuremember>... </gml:featurecollection> Versjon

25 4.7.5 Kodelister (T) Kodelister i GML er en samling av koder som kan brukes for å fylle inn lovlige verdier i objekter i GML-filen. Kodelister kan være enten interne eller eksterne. Interne kodelister inngår som en del av GML-applikasjonsskjemaet, mens eksterne kodelister skilles ut som et eget XML-dokument og kun refereres til fra GML-applikasjonskjemaet. For kodelister med koder som har allmenn anvendelse, som f.eks. kommunenummer, er det vanlig å lage disse som eksterne kodelister. Dermed kan andre benytte samme listen i sine GML-applikasjonsskjemaer XLink-referanser (T) XLink er en generell XML-mekanisme for å linke mellom elementer i XMLdokumenter eller internt i samme dokument. Også i GML er det mulig å referere til et annet GML-element ved bruk av XLink. Dette gjøres typisk dersom et GMLelement er assosiert med et annet GML-element. Det er kun i GML-filen man bruker XLink (ikke i GML-applikasjonsskjemaet). <TODO - Bør nevne delt geometri som eksempel på bruk av XLink. Det bør stå at det er gmlid det refereres til ved bruk av XLink.> Det er 3 hovedmåter å bruke i XLink-referanser på: Internt i samme dokument Eksternt til annet dokument, men i samme katalog på samme maskin Eksternt til annet dokument på annen plassering (URL) Eksempel på intern referanse i samme dokument: <app:produsent xlink:href= #produsent.1 /> Eksempel på ekstern referanse til annet dokument i samme mappe: <app:produsent xlink:href= Produsenter.gml#produsent.1 /> Eksempel på referanse til annet dokument på annen plassering (URL): <app:produsent xlink:href= # ent.1 /> I tillegg kan man kombinere for eksempel XLink og XPointer, men det er utenfor det som belyses i denne veilederen. For mer info om XLink generelt, se for eksempel Versjon

26 4.8 Kvalitetsnivåer og validering (T) For XML-filer generelt er det 3 kvalitetsnivåer: Velformet XML (XML-syntaksregler) Skjemavalidert Schematron-validert Velformet XML og skjemavalidering er nødvendig for alle GML-filer for å sikre at innholdet er i tråd med XML syntaksregler generelt og GML-applikasjonsskjemaet. Schematronvalidering er derimot bare nødvendig dersom dataeier har lagt inn spesielle begrensninger eller vilkår som man må være klart over ved produksjon av datasett i henhold til GML-applikasjonskjemaet. Det enkelte kvalitetsnivå ivaretas gjennom validering mot respektive kvalitetsregler. Figur 8 - Valideringstypene som ivaretar de 3 kvalitetsnivåene for GML-filer Velformet XML (XML-syntaksregler) (T) Dette er en svært enkel syntakskontroll som kun sjekker om XML-filen er i henhold til syntakskravene i XML generelt. Det gjøres ingen kontroll av hvorvidt reglene i eventuelle refererte GML-applikasjonsskjemaer er overholdt. Det kreves ikke engang at GML-filen inneholder referanser til GML-applikasjonsskjemaer. De fleste XML-editorer inneholder muligheter for å kontrollere om en XML-fil er velformet. Versjon

27 4.8.2 Skjemavalidering (T) Med skjemavalidering menes å kvalitetssjekke innholdet i en GML-fil i henhold til GML-applikasjonsskjemaet og tilhørende GML-skjemaer. Både bruken av selve elementene og verdiene sjekkes mot det som er definert som gyldige kombinasjoner i GML-applikasjonsskjemaet og tilhørende GML-skjemaer. Det finnes en rekke verktøy som kan skjemavalidere GML-filer. Siden GML også er XML, kan ofte vanlige XML-editorer skjemavalidere GML-filer. Ofte er skjemavalidering innebygget i forvaltningssystemer som kan vise GML eller koble mot WFS. En skjemavalidering av dataene i en GML-fil mot GML-applikasjonsskjemaet tilsvarer format- og egenskapskontroll i SOSI-kontroll. Figur 9 - Hovedprinsippet i skjemavalidering Schematron-validering (T) Schematron er et XML-basert språk for å beskrive begrensninger og vilkår ut over det som er gitt i XML-skjemaer og GML applikasjonsskjemaer. Schematron er også en ISO-standard (ISO/IEC Denne valideringstypen sjekker mer avanserte forhold mellom elementene i XML-filen som må være oppfylt, for eksempel semantiske eller topologiske krav. Grunnelementene i Schematronspråket er: <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" <pattern> <rule> <assert></assert> Versjon

28 <report></report> </rule> </pattern> </schema> I elementene assert og report brukes XPath-uttrykk for å identifisere delene i en GML-fil. Selve reglene for å angi valideringsuttrykk er definert i standarden, men man kan også finne mange beskrivelser av mekanismene i Schematron på internett, for eksempel på Et eksempel på bruksområde for Schematronvalidering kan være å kvalitetskontrollere at datoer i en GML-fil faktisk ligger tilbake i tid, for eksempel at registreringsdato ikke er en fremtidig dato. Eksempel på Schematron-regler for å sjekke at registreringsdato ligger tilbake i tid: <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" <pattern> <title>registreringsdatokontroll</title> <rule context="testobjekt"> <assert test="registreringsdato < current-date()">registreringsdato kan ikke være en fremtidig dato.</assert> </rule> </pattern> </schema> Et annet eksempel kan være at en dataeier har behov for å tydeliggjøre at eiendommer i datamodellen sin må ligge i fylke 06 Buskerud. Dette kan gjøres i GML-applikasjonsskjemaet ved å definere en intern kodeliste for fylke, som bare inneholder fylke 06 Buskerud. Men da dupliserer man listeinnhold som allerede finnes i en ekstern nasjonal kodeliste, og det er ikke ideelt ved oppdateringer av den nasjonale kodelista. En bedre løsning er å referere til den nasjonale kodelista for fylker i sin helhet, og heller begrense fylkesrelasjonen med OCL-uttrykk i datamodellen sin. OCL-uttrykk kan så overføres til Schematronregler som kobles mot GML-filene som lages fra GML-applikasjonsskjemaet. Et tredje eksempel kan være en beskrankning i UML datamodellen der landkode bare kan være NO. Dette vil i OCL se slik ut: inv: self.landkode='no' Uttrykt i en Schematron-fil vil det se slik ut: <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" xmlns:sch=" sdl/schematron"> <title>schematron constraints for schema 'Svalbardplan test'</title> <ns prefix="sch" uri=" /> <ns prefix="svp" uri=" rdplan/4.5" /> <pattern> <rule context="svp:administrativenhetskode"> <assert test="svp:landkode = 'NO'">Landkode alltid NO: Landkode kan bare være 'NO' </assert> </rule> Versjon

29 </pattern> </schema> For å gjøre en manuell Schematron-validering mot en GML-fil kreves egne verktøy eller plugins til XML-editorer, se kapittelet Programvare for å validere GML-filer. <TODO - Det er meningsløst å snakke om manuell Schematron-validering. Vi må beskrive en virkelighet som ligner på det en normal kartbruker vil ha, og her bør all GML-handtering skje ved hjelp av funksjonalitet i tilpasset programvare. Selv handtering i XML-editor editor bør være et unntakstilfelle for spesielt interesserte som oss. Men: det er vel ikke gitt at veilederen kun skal være for en spesiell type brukere som ikke kjenner XML-editorer? En annen ting er at det finnes kanskje ikke automatiserte verktøy for enhver anledning. Kanskje noen vil sette opp Schematronregler uavhengig av øvrige verktøy de bruker? Hva når man skal definere Schematron-reglene. En programmerer vil trolig teste ut om reglene er som forventet ved bruk av manuell verktøy.> For å muliggjøre automatisk maskinell validering av en GML-fil mot en Schematronfil tilsvarende det som gjøres mot et GML-applikasjonsskjema, må referansen til Schematronfilen oppgis i selve GML-filen. Dette kan gjøres ved å angi en prosesseringsinstruksjon i form av elementet xml-model som beskrevet av W3C (Associating Schemas with XML documents 1.0 (Third Edition)). Denne instruksjonen må angis helt i starten av filen (linje 2) som vist i eksempelet under. <?xml version="1.0" encoding="utf-16"?> <?xml-model href=" schematypens=" phase="#all"?> <Fylke xmlns=" ">... </Fylke> Begge de to foregående måtene å gjøre en Schematronvalidering på, innebærer at valideringen gjøres uavhengig av GML-applikasjonsskjemaet. GML-filer lages jo med basis i GML-applikasjonsskjemaet, og hvordan kan vi da sikre at Schematronreglene blir kontrollert mot GML-filene når det ikke ligger noen referanse til Schematronfilen i GML-applikasjonsskjemaet? Måten dette kan løses på er å legge Schematronreglene inn direkte i GMLapplikasjonsskjemaet. Eksempel på intern plassering av Schematronregler i et GML-applikasjonsskjema (komplett eksempel i vedlegget Eksempel på interne Schematronregler i GMLapplikasjonsskjema ): <?xml version="1.0" encoding="utf-8"?> <schema targetnamespace=" Versjon

30 " elementformdefault="qualified" version="4.9.0" xmlns=" ma" xmlns:app=" xmlns:gm l=" xmlns:sch=" <import namespace=" schemalocation=" opengis.net/gml/3.2.1/gml.xsd" /> <appinfo> <sch:title>schematron validering</sch:title> <sch:ns prefix="app" uri=" /> </appinfo>... <complextype name="fylketype"> <complexcontent> <extension base="app:administrativenhettype"> <sequence>... <element name="fylkesnummer" type="gml:codetype"> <appinfo> <sch:pattern id="fylkesnummertest"> <sch:rule context="app:fylke"> <sch:assert test="app:fylkesnummer='06'"> Det er kun 06 Buskerud som er gyldig fylke </sch:report> </sch:rule> </sch:pattern> </appinfo> </element> </sequence> </extension> </complexcontent> </complextype>... </schema> Dermed oppnår man at alle GML-filer som er laget med basis i GMLapplikasjonsskjemaet blir validert mot Schematronreglene samtidig som valideringen mot GML-applikasjonsskjemaet skjer (forutsatt at validatoren støtter Schematronvalidering). <TODO - Bør anbefale at schematromregler legges inn i skjema i stedet for at de legges på egne filer. Det er enklest at hele beskrivelsen ligger på en fil.> Eksemplene: Kunne tenkt meg et eksempel der man kan utrykke TOPO-reglene for delt geometri i UML-skjema i Schematron. Det skal være mulig i følge Tor Kjetil. 4.9 Geometri (T) GML beskriver geometrien ved bruk av tekstlige elementer. Noen av de grunnleggende geometriske datatypene i GML er: Point MultiPoint LineString Polygon MultiPolygon Surface Versjon

31 MultiSurface Curve MultiCurve Arc Circle Solid For en komplett oversikt over de grunnleggende geometriske datatypene i GML vises det til dokumentet for standarden OGC/ISO kapittel 10. Denne kan lastes ned fra OGCs sider GML har et rikt reportoar for å beskrive geometri i flere dimensjoner: 0-dimensjonale (f.eks point) beskriver et punkt i rommet. 1-dimensjonale (f.eks curve) beskriver en linje i rommet. 2-dimensjonale (f.eks surface) beskriver en flate i rommet. 3-dimensjonale (f.eks solid) beskriver et volum i rommet. I tillegg vil hver av disse ha ulike interpolasjonsmetoder. For eksempel kan "Curve" angis som "linear", "geodesic", "circulararc3points", etc. <TODO - Curve har ingen egenskap for interpolasjonsmetode. Det er gml:linestringsegment som har dette. I tillegg bør vi anbefale at interpolasjonsmetode ikke brukes. LineStringSegment brukes når det er interpolasjonsmetode linear. For andre varianter brukes de andre alternativene under segments, som for eksempel gml:arc og gmlcircle.> Det finnes en klar mapping mellom de geometrityper vi benytter i SOSI UMLmodeller og GML. SOSI syntaks eksempel GML eksempel.buep 1:..OBJTYPE GangSykkelveg..NØ <sosi:kurve> <gml:curvemember> <gml:curve gml:id="c22222" srsname="epsg:4326"> <gml:segments> <gml:arc> <gml:poslist> </gml:posList> </gml:arc> </gml:segments> </gml:curve> </gml:curvemember> </sosi:kurve> Denne veilederen omhandler de mest vanlige geometriene med tilhørende interpolasjonsmetoder. For en komplett oversikt over de grunnleggende geometriske datatypene i GML vises det til dokumentet for standarden OGC/ISO kapittel 10. Denne kan lastes ned fra OGCs sider Versjon

32 4.10 GML og koordinatsystemer (T) I GML angis koordinatsystemet ved hjelp av en EPSG-kode. Følgende kodesyntaks brukes: urn:ogc:def:crs:epsg:: Tallkoden refererer til UTM sone 32 basert på EUREF89 (ETRS89/UTM), 2d. For detaljert beskrivelse og oppslag henvises til EPSG-registeret som er tilgjengelig på denne adressen: Dette er det offisielle registeret over godkjente EPSG-koder Koordinatangivelse i GML (T) Selve angivelsen av koordinater i forbindelse med et objekts geometri gjøres ved bruk av faste GML-elementer. GML tilbyr i utgangspunktet 4 ulike elementer for å angi koordinater: <gml:coord> - GML 2 <gml:coordinates> - GML 2 og 3 <gml:pos> - GML 3 <gml:poslist> - GML 3 GML 2 støtter kun gml:coord og gml:coordinates. gml:coord er ikke anbefalt brukt selv i GML 2, man bruker i stedet gml:coordinates både for enkeltpunkt og lineære geometrier. For WFS-servere og transformasjonsverktøy som fortsatt kun støtter GML 2, må derfor gml:coordinates brukes. GML 3 støtter gml:coordinates (ikke anbefalt), men tilbyr gml:pos og gml:poslist som anbefalte elementer for å angi posisjonsdata. Elementet gml:pos brukes for å angi koordinatene til et punkt. Elementet gml:poslist brukes i alle tilfeller der det er behov for å angi mer enn en koordinat, også for ikke lineær geometri. Eksempel på bruk av gml:pos (GML 3) for punkt: <gml:point gml:id="_45gh7b2g-lkoi-66t7-op98- d33jh671as12" srsname="urn:ogc:def:crs:epsg::4258"> <gml:pos srsdimension="2"> </gml:pos> </gml:point> Eksempel på bruk av gml:poslist (GML 3) for linje: Versjon

33 <gml:linestring gml:id="_23bc4c1f-abbe-41f8-ba21- b98ea310dc65" srsname="urn:ogc:def:crs:epsg::25833"> <gml:poslist srsdimension="2">177003, , </gml:posList> </gml:linestring> <TODO: srsdimension="2" på samme element som srsname? eller utelates. PostGIS leverer GML på denne måten men tror det er bedre å utelate?> 4.11 GML-profiler (T) GML-profiler er begrensninger av GML, og kan uttrykkes i et dokument eller i et XML skjema (XSD). Hensikten med profiler er å forenkle bruken av GML for bestemte formål, samt legge til rette for en økende bruk av standarden. Følgende profiler er utarbeidet som globale profiler av GML (men ikke alle er i praktisk bruk): En Point profil for applikasjoner med behov for punktgeometri men uten alle de øvrige GML-elementene. En GML Simple Features profil som støtter de vanligste vektorbaserte objekttypene i forespørsler og transaksjoner mot f.eks WFS-tjenester. En GML-profil for GMJP2 (GML i JPEG 2000) (ukjent praktisk anvendelse). En GML-profil for RSS (ukjent praktisk anvendelse). Det er viktig å merke seg forskjellen mellom profiler og GMLapplikasjonsskjemaer. En profil er en begrensning av de generelle mulighetene i GML, mens et GML-applikasjonsskjema er en modell av virkeligheten uttrykt i komplett GML eller innenfor en GML-profil. Det er Simple Features profilen som er den mest kjente og anvendte av de over nevnte GML-profilene Simple Features profilen (T) Simple Features profilen er den mest komplette ferdige definerte GML-profilen. Den tilbyr et bredt spekter av objekttyper og mekanismer: En redusert geometrimodell som inneholder de lineære objektene samt MultiPoint og MultiCurve. En forenklet objektmodell som kun kan være ett nivå dyp. Alle ikke-geometriske egenskaper må være SimpleTypes, dvs de kan ikke inneholde nøstede elementer. Bruk av referanser med xlink:href tilsvarende som i ordinær GML. Versjon

34 Simple Features profilen støtter ikke følgende: coverages topology observations value objects (for sanntids sensordata) dynamic features For mer informasjon om Simple Features profilen, se GML og navnerom (T) Navnerom er en mekanisme i XML som dermed også benyttes i GML. Et XMLnavnerom er en globalt unik streng som tildeler ett eller flere XML-elementer et spesifikt gyldighetsområde. To ulike navnerom kan ha samme elementnavn, hver får da ulikt gyldighetsområde. Hvert navnerom deklareres innledningsvis i en GML-fil med prefikset xmlns : <?xml version="1.0" encoding="utf-8"?> <gml:featurecollection xmlns:gts=" xmlns:gco=" xmlns:ns1=" xmlns:hfp=" xmlns:gml=" xmlns:app=" " xmlns:gss=" xmlns:gsr=" xmlns:gmd=" xmlns:xlink=" xmlns:xsi=" gml:id="_019a916d-80b2-41e3- b44e-a7e3b765ff57" xsi:schemalocation=" rming/1.0 file:/c:/users/test/documents/workspace/enterprisearchitect/xsd/universellutforming.xs d"> Dermed blir de ulike navnerommene hver tilordnet sin spesifikke URI, og all bruk av navnerommene kan identifiseres unikt ut fra dette. Eksempel på samme elementnavn med ulike navnerom som kan forekomme i en GML-fil: <wfs:featurecollection> og <gml:featurecollection> Versjon

35 Det er en lur praksis å lage slike strenger som http-uri-er, da er en sikker på unikhet. De fleste bruker dette nå. I xml-filer angis navnerommene slik: xmlns[:navneromsprefiks]="navneromsnavn(som http-uri)" Eksempel: xmlns:gml=" Eksempel på data i GML-navnerommet: <gml:linestringsegment interpolation="linear"> Dersom navneromsprefikset mangler tilhører alle elementer uten prefiks standard-navnerommet. Eksempel: xmlns=" r/1.0" Eksempel på GML-element i standard navnerommet: <Flytebrygge gml:id="no.sk.fkyst "> Eksempel på GML-element med definert navnerom (app): <app:flytebrygge gml:id="no.sk.fkyst "> Navnerommet app må da være definert i begynnelsen av GML-filen. Vår erfaring fra GeoSynkronisering er at alle element bør ha navneromprefiks. (deegree er meget streng på dette). Versjon

36 5 Bruke GML GML og SOSI er de påkrevde realiseringsformatene fra en produktspesifikasjon. Ved å generere GML-applikasjonsskjemaet fra UML-modellen i produktspesifikasjonen, sikrer vi at GML-data som skal produseres blir i samsvar med produktspesifikasjonen. Dette ivaretas da gjennom objekttypedefinisjonene i GML-applikasjonsskjemaet. Figur 10 - Realisering av produktspesifikasjoner i GML og SOSI For blant annet å gjøre det enklere å foreta en overgang fra SOSI til GML, kan det være lurt å bruke GML på måter som legger til rette for akkurat dette. I dette kapittelet belyses områder hvor det er behov for å bruke GML på anbefalte måter. 5.1 Bruksområder for GML GML kan i utgangspunktet benyttes for alle tilsvarende formål som SOSIformatet. I løpet av kort tid er partene i Norge digitalt forpliktet til å kunne levere datasett i GML via for eksempel WFS-tjenester, ref dokumentet "Veileder for leveranser i Norge digitalt ( Avhengig av hvilken bruksrolle man har, vil GML brukes på ulike måter. En person som laster ned en GML for videre visning i et kartverktøy, vil bruke GML annerledes enn en person som skal publisere et datasett i GML via en WFStjeneste. Det gis videre noen eksempler på ulike brukerroller og deres bruk av GML. Versjon

37 5.1.1 Bruker som lager produktspesifikasjoner En bruker som lager produktspesifikasjoner som skal realiseres i GML, vil måtte forholde seg til både GML-applikasjonsskjemaer og GML-filer. GMLapplikasjonsskjemaene genereres normalt direkte i prosessen med produktspesifikasjonen, og det er også nødvendig å lage et godt eksempel på en GML-fil som er basert på GML-applikasjonsskjemaet. Produktspesifikasjonen skal inneholde begge deler. Figur 11 - GML og produktspesifikasjoner <TODO - Hva er Grafisk datamodell? Går ut fra at det bør stå UML applikasjonsskjema?> Versjon

38 Se Vedlegg B Lage en GML-eksempelfil for hvordan en GML-eksempelfil kan lages. GML-kompetanse for denne brukerrollen: GML-kompetanse Nødvendig Anbefalt Generell kjennskap til GML-applikasjonsskjemaer JA Generell kjennskap til GML-filer JA Kunne kvalitetssikre GML-applikasjonsskjemaer JA Kunne kvalitetssikre GML-filer JA Kunne lage GML-filer basert på et GMLapplikasjonsskjema JA Avansert kunnskap om GML-applikasjonsskjemaer Kunnskap om dataharmonisering Bruker som produserer datasett i GML Det er brukt ordet dataharmonisering, er ikke skjematransformasjon mer korrekt?. I forbindelse med GeoSynkronisering er det skrevet 2 notater om dette. Vanligvis vil produksjon av datasett i GML (en GML-fil) skje fra et verktøy som kan eksportere datasettet direkte til GML. Men selv om verktøyet kan produsere gyldig GML, er det ikke sikkert at datastrukturen følger et gitt GMLapplikasjonsskjema. For å sikre dette er det vanlig å harmonisere datasettet. Harmonisere vil si å tilpasse dataene en gitt datastruktur. Dette kan gjøres ved å - enten sette opp enten en databasetabell (view) der den riktige datastrukturen i henhold til GML-applikasjonsskjemaet er ivaretatt og eksportere til GML fra denne strukturen, - eller bruke et dataharmoniseringsverktøy som kobler data fra en database mot et GML-applikasjonsskjema, og filtrerer ut de riktige feltene og verdiene. Harmoniseringen av dataene kan skje enten på nasjonalt nivå eller på INSPIREnivå. For å harmonisere på nasjonalt nivå brukes GML-applikasjonskjemaet som et filter for å strukturere dataene som skal legges i det enkelte datasettet. For å harmonisere på INSPIRE-nivå brukes INSPIREs dataspesifikasjoner i form av deres GML-applikasjonsskjemaer ( Det som beskrives her er forhåpentligvis langt fra det som kommer til å bli virkeligheten. (Selv om det har skjedd en del hacking på dette nivået hittil.) Foreslår nytt første avsnitt: Vanligvis vil produksjon av datasett i GML skje fra et verktøy som kan eksportere datasettet direkte til GML i henhold til et gitt GML-applikasjonsskjema basert på en UML-modell. Versjon

39 Strekpunktene utgår. Avsnitt som starter med Harmoniseringen utgår. Figur 12 utgår. Harmonisering mellom ulike datamodeller vil skje på datamodell nivå. Deretter kan en produsere data i henhold til det aktuelle skjemaet (som er harmonisert mot et eller annet). Det er ikke datasettene som harmoniseres, men data produseres i henhold til et skjema som er harmonisert. Kompetansekravene skal være det samme som i punkt Nasjonalt harmoniserte datasett bør endres til Nasjonale datasett. Mulig at også INSPIRE-harmoniserte datasett bør endres til INSPIRE-datasett. Figur 12 - Dataharmonisering på nasjonalt- og INSPIRE-nivå GML-kompetanse for denne brukerrollen: GML-kompetanse Nødvendig Anbefalt Generell kjennskap til GML-applikasjonsskjemaer JA Generell kjennskap til GML-filer JA Kunne kvalitetssikre GML-applikasjonsskjemaer JA Kunne kvalitetssikre GML-filer JA Kunne lage GML-filer basert på et GMLapplikasjonsskjema JA Avansert kunnskap om GML-applikasjonsskjemaer Versjon

40 Kunnskap om dataharmonisering JA Bruker som mottar leveranser i GML Brukere som mottar en leveranse med GML-fil(er) eller skal laste ned og se på en GML-fil i en kartapplikasjon, har en enkel oppgave. Nedlasting skjer typisk fra nasjonal geoportal eller fra dataeiers egen nedlastingsløsning. Når filen er lastet ned kan den vises direkte i de fleste kartapplikasjoner. Uenig, målet er ikke at GML-filen skal kunne vises direkte, målet er at man skal kunne håndtere GML-filen for visning i kartapplikasjonen. Hvordan dette håndteres avhenger av formen GML-filen kommer på. Er det en WFS-tjeneste, GeoSynkronisering, en ren filnedlasting etc. Om generelle (les OpenSource GML-viewere) kan lese GML-filen avhenger av kompleksitet på GML-filen pr. dags dato. Figur 13 - Bruker lokaliserer og laster ned GML-filer fra nasjonal geoportal GML-kompetanse for denne brukerrollen: GML-kompetanse Nødvendig Anbefalt Generell kjennskap til GML-applikasjonsskjemaer JA Generell kjennskap til GML-filer JA Kunne kvalitetssikre GML-applikasjonsskjemaer Kunne kvalitetssikre GML-filer Kunne lage GML-filer basert på et GMLapplikasjonsskjema Avansert kunnskap om GML-applikasjonsskjemaer Kunnskap om dataharmonisering Versjon

41 5.1.4 Bruker som setter opp tjenester som leverer GML Når man setter opp en nedlastingstjeneste må man sikre at datasettene som returneres fra tjenesten er i henhold til GML-applikasjonsskjemaet. I tjenestekonfigurasjonen må man derfor legge inn de definisjonene som ligger i GML-applikasjonsskjemaet. Noe tjenesteprogramvare lar deg legge inn GMLapplikasjonsskjemaet som en konfigurasjonsfil, mens andre krever at du omskriver reglene til et leverandørspesifikt format i en gitt konfigurasjonsfil. Her er det etter Andreas syn viktig at den som gjør dette har Avansert kunnskap om GML-applikasjonsskjemaer. Dette er viktig for å ha full forståelse av hvordan mappingen mellom data i basen og data i GML-filen skal være. Her bør det kanskje stå noe om at en som tilbyr en tjeneste for GML, kanskje også tilbyr disse på ulikt kompleksitetsnivå ut fra type tjeneste. Figur 14 - Publisering av datasett basert på GML-applikasjonsskjema GML-kompetanse for denne brukerrollen: GML-kompetanse Nødvendig Anbefalt Generell kjennskap til GML-applikasjonsskjemaer JA Generell kjennskap til GML-filer JA Kunne kvalitetssikre GML-applikasjonsskjemaer JA Kunne kvalitetssikre GML-filer JA Kunne lage GML-filer basert på et GMLapplikasjonsskjema JA Avansert kunnskap om GML-applikasjonsskjemaer Kunnskap om dataharmonisering JA Versjon

42 5.1.5 Bruker som benytter tjenester som leverer GML Dette brukstilfellet er identisk med Bruker som mottar leveranser i GML. Bør ikke GeoSynkronisering være med her? På den annen side; skal ikke geosynkronisering gjøres automatisk uten brukers involvering? Figur 15 - Bruker som benytter tjenester som leverer GML GML-kompetanse for denne brukerrollen: GML-kompetanse Nødvendig Anbefalt Generell kjennskap til GML-applikasjonsskjemaer Generell kjennskap til GML-filer JA Kunne kvalitetssikre GML-applikasjonsskjemaer Kunne kvalitetssikre GML-filer Kunne lage GML-filer basert på et GMLapplikasjonsskjema Avansert kunnskap om GML-applikasjonsskjemaer Kunnskap om dataharmonisering 5.2 GML og geometri i Norge Norge digitalt forholder seg til to overordnede geometrimodeller: Heleid geometri - typisk bruk gjennom OGC-tjenester for visning og bruk av geometridata i presentasjoner og analyser som ikke har behov for å Versjon

43 forholde seg til eksakt struktur i originaldata. Dette fører til at data kan bli duplisert to til tre ganger, og at det derfor kan føre til vesentlig økning av datamengden som må overføres. Delt geometri - typisk for utveksling av geometridata og overføring av eksakt struktur, eksempelvis fra SOSI. - Heleid geometri - typisk bruk gjennom OGC-tjenester for visning, men også for analyser og bruk av geodata der data ikke skal forvaltes. - Delt geometri - typisk for utveksling av geodata der data også skal forvaltes i mottakers system. Generelt synes vi at fokuset på delt geometri er for stort, det er brukstilfellene som er viktig. Med de prinsippene som er nedfelt i GeoSynkronisering om at et spesifikt datasett har kun en forvalter, er ikke dette med delt geometri lengre så viktig. Og det store fokuset på delt geometri er kanskje et særnorsk fenomen? Jeg er ikke enig i at kommentar fra Andreas om økning i datamengde som overføres i forbindelse med heleid geometri skal være med, dette er uvesentlig i den store sammenheng. Viktig å få med at ved heleid geometri så blir selvfølgelig også geometrien til alle objekter med, eksempelvis har en flate egen geometri for selve flaten (eksempelvis planområde), og linjen har egen geometri (eksempelvis plangrense). Og sammenhengen mellom flatene og linjene kan eventuelt overføres som regler (TOPO). Ser i et eksempel fra INSPIRE Cadastral Parcels: cification_cp_v3.0.pdf Der er det "delt geometri", men der er retningen motsatt av det som har vært vanlig i Norge. Eiendomsgrensen vet hvilke Eiendom(er) den tilhører er (1..2), men ikke motsatt. Det mangler å beskrive det å ha flere geometrier på en objekttype (samme forekomst). Det må være med. Men da bør man angi hva som er hoved-geometrien til en objekttype (metadata). Det tror jeg letter implementasjonen. I Inspire er dette gjort på f.eks. BuildingGeometry2D (som er en type knyttet til AbstractBuilding) der man har en egenskap " referencegeometry" (True/False): The geometry to be taken into account by view services, for portrayal Heleid geometri (T) <TODO er disse relasjonene korrekte?> SOSI typene for heleid geometri er foreslått relatert til GML som følger: Enig med Andreas, Høyde skal ikke være med. Vi må ha en måte å få overført punkt med rotasjon. Hva med tekster? Her er det behov for å lage en norsk variant. Hva med siste forslag fra Kent på SOSI Ag1 om geometri-typer? Skal det inn? SOSI GML Versjon

44 Punkt Kurve Flate Sverm Buep Sirkelp gml:point gml:curve gml:surface gml:multipoint gml:arc gml:circle Standard mappinger fra ShapeChange: SOSI Høyde Dybde GML xs:double xs:double Delt geometri (T) <TODO er disse relasjonene korrekte?> SOSI typene for delt geometri er i SOSI 5.0 foreslått relatert til GML som følger: SOSI DeltPunkt DeltKurve DeltFlate DeltSverm GML gml:compositepoint gml:compositecurve gml:compositesurface gml:compositemultipoint Eksempel som viser praktisk bruk av delt geometri ved hjelp av xlink: <?xml version="1.0" encoding="utf-16"?> <wfs:featurecollection timestamp=" T07:00:00" numbermatched="2" numberreturned="2" xsi:schemalocation=" o/sosi/produktspesifikasjon/primærdatakystkontur/1.0 tur.xsd xmlns=" fikasjon/primærdatakystkontur/1.0" xmlns:xlink=" xmlns:wfs="http: // xmlns:gml=" xmlns:xsi=" <wfs:boundedby> <gml:envelope srsname="urn:ogc:def:crs:epsg::4258"> <gml:lowercorner> </gml:lowerCorner> <gml:uppercorner> </gml:upperCorner> </gml:envelope> </wfs:boundedby> <wfs:member> <Flytebrygge gml:id="no.sk.pkyst.flytebrygge1"> <datafangstdato> t11:00:00z</datafangstdato> <oppdateringsdato> t11:00:00z</oppdateringsdato> Versjon

45 <område> <gml:compositesurface srsname="urn:ogc:def:crs:epsg::4258" gml:id="no.sk.pkyst.compositesurface1"> <gml:surfacemember> <gml:surface srsname="urn:ogc:def:crs:epsg::4258" gml:id="no.sk.pkyst. SURFACE1"> <gml:patches> <gml:polygonpatch interpolation="planar"> <gml:exterior> <gml:ring> <gml:curvemember xlink:href="#no.sk.pkyst.curve1" /> <gml:curvemember xlink:href="#no.sk.pkyst.curve3" /> </gml:ring> </gml:exterior> </gml:polygonpatch> </gml:patches> </gml:surface> </gml:surfacemember> </gml:compositesurface> </område> <!-- HVORDAN BLIR DENNE MED DELT GEOMETRI? > <avgrensning xlink:href="#no.sk.pkyst.flytebryggekant1"/--> </Flytebrygge> </wfs:member> <wfs:member> <Flytebrygge gml:id="no.sk.pkyst.flytebrygge2"> <datafangstdato> t11:00:00z</datafangstdato> <oppdateringsdato> t11:00:00z</oppdateringsdato> <område> <gml:compositesurface srsname="urn:ogc:def:crs:epsg::4258" gml:id="no.sk.pkyst.compositesurface2"> <gml:surfacemember> <gml:surface srsname="urn:ogc:def:crs:epsg::4258" gml:id="no.sk.pkyst. SURFACE2"> <gml:patches> <gml:polygonpatch interpolation="planar"> <gml:exterior> <gml:ring> <gml:curvemember xlink:href="#no.sk.pkyst.curve2" /> <gml:curvemember> <gml:orientablecurve orientation="- " gml:id="no.sk.pkyst.orientablecurveref1"> <gml:basecurve xlink:href="#no.sk.pkyst.cu RVE3" /> </gml:orientablecurve> </gml:curvemember> </gml:ring> </gml:exterior> </gml:polygonpatch> </gml:patches> </gml:surface> </gml:surfacemember> </gml:compositesurface> </område> <!-- HVORDAN BLIR DENNE MED DELT GEOMETRI? > <avgrensning xlink:href="#no.sk.pkyst.flytebryggekant1"/--> </Flytebrygge> </wfs:member> <wfs:member> <Flytebryggekant gml:id="no.sk.pkyst.flytebryggekant1"> <datafangstdato> t11:00:00z</datafangstdato> <kvalitet> <Posisjonskvalitet> <målemetode>11</målemetode> <nøyaktighet>13</nøyaktighet> </Posisjonskvalitet> </kvalitet> <oppdateringsdato> t11:00:00z</oppdateringsdato> <grense> <gml:compositecurve srsname="urn:ogc:def:crs:epsg::4258" gml:id="no.sk.pkyst.c Versjon

46 OMPOSITECURVE1"> RVE1"> <gml:curvemember> <gml:curve srsname="urn:ogc:def:crs:epsg::4258" gml:id="no.sk.pkyst.cu <gml:segments> <gml:linestringsegment interpolation="linear"> <gml:poslist> </gml:posList> </gml:linestringsegment> </gml:segments> </gml:curve> </gml:curvemember> </gml:compositecurve> </grense> </Flytebryggekant> </wfs:member> <wfs:member> <Flytebryggekant gml:id="no.sk.pkyst.flytebryggekant2"> <datafangstdato> t11:00:00z</datafangstdato> <kvalitet> <Posisjonskvalitet> <målemetode>11</målemetode> <nøyaktighet>13</nøyaktighet> </Posisjonskvalitet> </kvalitet> <oppdateringsdato> t11:00:00z</oppdateringsdato> <grense> <gml:compositecurve srsname="urn:ogc:def:crs:epsg::4258" gml:id="no.sk.pkyst.c OMPOSITECURVE2"> <gml:curvemember> <gml:curve srsname="urn:ogc:def:crs:epsg::4258" gml:id="no.sk.pkyst.cu RVE2"> <gml:segments> <gml:linestringsegment interpolation="linear"> <gml:poslist> </gml:posList> </gml:linestringsegment> </gml:segments> </gml:curve> </gml:curvemember> </gml:compositecurve> </grense> </Flytebryggekant> </wfs:member> <wfs:member> <Flytebryggekant gml:id="no.sk.pkyst.flytebryggekant3"> <datafangstdato> t11:00:00z</datafangstdato> <kvalitet> <Posisjonskvalitet> <målemetode>11</målemetode> <nøyaktighet>13</nøyaktighet> </Posisjonskvalitet> </kvalitet> <oppdateringsdato> t11:00:00z</oppdateringsdato> <grense> <gml:compositecurve srsname="urn:ogc:def:crs:epsg::4258" gml:id="no.sk.pkyst.c OMPOSITECURVE3"> <gml:curvemember> <gml:curve srsname="urn:ogc:def:crs:epsg::4258" gml:id="no.sk.pkyst.cu RVE3"> <gml:segments> <gml:linestringsegment interpolation="linear"> <gml:poslist> </gml:posList> </gml:linestringsegment> </gml:segments> </gml:curve> </gml:curvemember> </gml:compositecurve> </grense> </Flytebryggekant> Versjon

47 </wfs:member> </wfs:featurecollection> Geometrityper i Norge (T) I Norge digitalt anbefales det at man generelt begrenser seg til følgende grunnleggende objekttyper i GML (definert i GML-skjemaene): Point MultiPoint LineString Polygon Surface MultiSurface Curve MultiCurve Arc Circle Solid Dette er ingen absolutt grense for bruken, men heller en prioritering av hvilke geometrityper som håndteres i første versjon. I programvaren FYSAK har man valgt følgende implementasjonsplan for geometrityper (Svart = Implementeres nå, Grå = utsettes til senere): gml:point Choice [1..1] gml:pos gml:curve gml:segments gml:coordinates (deprecated) gml:surface Choice [1..1] gml:patches gml:polygonpatches gml:trianglepatches (deprecated) (deprecated) gml:polyhedralsurface gml:triangulatedsurface gml:tin gml:solid gml:orientablecurve gml:orientablesurface gml:ring gml:curvemember [1..*] gml:shell gml:linestring Choice [1..1] Versjon

48 Choice [2..*] gml:pos gml:pointproperty gml:pointrep gml:poslist gml:coordinates gml:polygon Sequence [1..1] gml:exterior [0..1] gml:interior [0..*] gml:linearring gml:compositecurve Sequence [1..1] gml:curvemember [1..*] (deprecated) (deprecated) gml:compositesurface Sequence [1..1] gml:surfacemember [1..*] gml:compositesolid gml:geometriccomplex gml:multigeometry gml:multipoint Sequence [1..1] gml:pointmember [0..*] gml:pointmembers [0..1] gml:multicurve Sequence [1..1] gml:curvemember [0..*] gml:curvemembers [0..1] gml:multisurface Sequence [1..1] gml:surfacemember [0..*] gml:surfacemembers [0..1] gml:arc Choice [1..1] Choice [3..3] gml:pos gml:pointproperty gml:pointrep gml:poslist gml:coordinates gml:arcbybulge gml:arcbycenterpoint gml:arcstring gml:arcstringbybulge (deprecated) (deprecated) Versjon

49 gml:bezier gml:bspline gml:circle Choice [1..1] Choice [3..3] gml:pos gml:pointproperty gml:pointrep gml:poslist gml:coordinates (deprecated) (deprecated) gml:circlebycenterpoint Sequence [1..1] Choice [1..1] gml:pos gml:pointproperty gml:pointrep (deprecated) gml:poslist gml:coordinates (deprecated) gml:radius [1..1] gml:clothoid gml:cubicspline gml:geodesicstring gml:linestringsegment gml:offsetcurve gml:abstractsurfacepatch gml:abstractparametriccurvesurface gml:cone gml:cylinder gml:geodesic gml:polygonpatch gml:rectangle gml:sphere gml:triangle gml:node gml:edge gml:face gml:toposolid gml:topocomplex gml:topopoint gml:topocurve gml:toposurface gml:topovolume gml:abstracttimeobject gml:abstracttimecomplex gml:abstracttimegeometricprimitive gml:timeinstant gml:timeperiod gml:timetopologycomplex gml:abstracttimetopologyprimitive gml:timenode gml:timeedge Versjon

50 INSPIRE har laget en egen objektkatalog som inneholder alle objekttyper som brukes I INSPIREs dataspesifikasjoner. Hver objekttyper er beskrevet med hvilkeegenskaper de har og hvilke datatyper hver egenskap har. Her beskrives også hvilke geografiske egenskaper objekttypene har og dessuten alle relasjoner til andre objekttyper. Dette kan være et nyttig oppslagsverk når man skal harmonisere og modellere egne datasett etter INSPIREs dataspesifikasjoner. INSPIREs objektkatalog finnes på for annex I, og for annex II og III. Siste avsnitt: er linken til INSPIRE sin objektkatalog til siste versjon? Denne er vel nyere? ir/fc/. Knut: ja, men den er til Annex 2 og 3 dataene. Har tatt den med. <TODO - Det drøftes behovet for å komme opp med en mer fullstendig liste som ivaretar alle typer som følger av Geodataloven/INSPIRE anneks 1, 2 og 3. Listen er tenkt å inneholde de antatt relevante objekttypene for Norge digitalt og bør markeres slik at de relevante er sorte og de øvrige grå. Partene må bringes inn i arbeidet med å finne ut hvilke objekttyper som er direkte relevante og ikke. Forholdet mellom disse objekttypene i GML og SOSI bør også fremkomme. Tas inn i egne kapitler Geometrityper for nasjonalt harmoniserte datasett og Geometrityper for INSPIRE-harmoniserte datasett > 5.3 Norge digitalt konformitetsnivåer Norge digitalt forholder seg til noen ulike konformitetsnivåer for støtte for GML. Følgende konformitetsnivåer er definert, uavhengig av geometrimodeller: SOSI (støtte for SOSI produktspesifikasjoner nasjonalt harmonisert) INSPIRE (støtte for INSPIRE datasettspesifikasjoner INSPIRE harmonisert) BIM? Se også kapittelet Bruker som produserer datasett i GML. <TODO - Beskrive disse konformitetsnivåene, når og hvordan den enkelte skal brukes.> 5.4 Forholdet til BIM Dette er ikke beskrevet i denne versjonen av dokumentet. 5.5 Bruk av kodelister (T) Det brukes 2 referansemåter for kodelister; interne og eksterne. Versjon

51 5.5.1 Interne kodelister (T) Kodelister som kun inneholder verdier som utelukkende brukes innen den enkelte datamodellen, kan ligge som interne referanser (interne kodelister) i det enkelte GML-applikasjonsskjemaet. Disse bør da modelleres med elementet enumeration, altså GMLs mekanisme for å angi interne lister. I utgangspunktet er enumerations å anse som lukkede lister, dvs at det ikke er mulig å endre eller legge til nye verdier i bruk. <TODO - Kunne også vært nevnt enum som er lukket og åpen... for eksempel ukedager lukket liste og xkategori som har noen kjente men tillater også nye udefinerte koder i GML.> Eksempel på intern kodeliste definert i et GML-applikasjonsskjema: <schema xmlns=" xmlns:app=" " xmlns:gml=" targetnamespace=" ng/1.0" elementformdefault="qualified" version="1.0"> <import namespace=" schemalocation=" <simpletype name="vegdekkeenumerationtype"> <restriction base="string"> <enumeration value="asfalt"/> <enumeration value="betong"/> <enumeration value="brostein"/> <enumeration value="stein"/> <enumeration value="gress"/> <enumeration value="skogsbunn"/> <enumeration value="grus"/> </restriction> </simpletype> </schema> Eksterne kodelister (T) Kodelister som har allmenn anvendelse eller repeterende anvendelse innenfor flere datamodeller (også andre parters datamodeller), skal primært legges som eksterne referanser (eksterne kodelister) i applikasjonsskjemaene. Eksempler på dette kan være kommunenummer, norske fartsgrenser eller bonitet. Det mest naturlige tidspunktet å definere referansen til eksterne kodelister er i modelleringen av UML-modellen. Beskrivelse av hvordan dette gjøres finnes i dokumentasjonen for utarbeidelse av produktspesifikasjoner ( <TODO - Bør anbefale bruk av DefaultCodespace i applikasjonsskjemaet, slik at en slipper at det refereres til kodelisteplassering i hver forekomst.> Versjon

52 Eksempel på utdrag fra et GML-applikasjonsskjema med referanse til ekstern kodeliste: <complextype name="kystkonturtype"> <complexcontent> <extension base="sosi:sosi_objektkystkonturtype"> <sequence> <element minoccurs="0" name="kystreferanse" type="gml:codetype"> <documentation>kystkonturens referansenivå</documentation> <appinfo> <defaultcodespace xmlns=" ntur/1.0/kystreferanse.xml</defaultcodespace> </appinfo> </element> <element minoccurs="0" name="høyde" type="double"> <documentation>bla bla bla documentation> </element> <element minoccurs="0" name="medium" type="gml:codetype"> <documentation>objektets beliggenhet i forhold til jordoverflaten</documentation> </element> </sequence> </extension> </complexcontent> </complextype> 5.6 Identifikatorer (T) <TODO - forslag fra Geosynkronisering om å bruke komplette ID er basert på navnerom og UUID for hvert eneste objekt på objektnivå. Sparer mye jobb og tid ved generering av ID for hvert objekt. Normalt håndteres ID er slik at man setter sammen navnerom og lokal-id i det øyeblikk man har behov for en globalt unik ID for objektet, men Geosynkronisering har rapportert at de ønsker å ha ID for hvert objekt ferdig sammensatt av navnerom og lokal-id. Ulempen er at det blir mye redundant informasjon som fyller opp og øker filstørrelsen. Dessuten bryter det med den vanlige måten å bruke Ider på. Vurderes.> <TODO - Ser ikke riktig ut det som står i rødt ang. geosynkronisering Det bør også forklares forskjellen på gml:id og Identifikasjon Savner mer informasjon om gml:id. (Forskjellig bruk i de ulike eksemplene.) Hvordan er sammenhengen med INSPIRE-ID?> Samkjøres med siste fra SOSI Ag1 notat Morten Borrebæk. Versjon

53 5.6.1 Identifikatorer for objekter (T) I henhold til Rammeverksdokumentet skal en identifikator for et objekt settes sammen av et navnerom og en lokal-id. Følgende struktur skal brukes for identifikasjon av objekter i GML: <Navnerom>.<Lokal-ID> Eksempel: NO.KV.NMG.e106adf4-c9d8-4fce-a9b5-7886a4126d23 Navnerom <NO(obligatorisk)>.<VIRKSOMHET(obligatorisk)>.<FAGOMRÅDE(obligatorisk)> Dette er en standard konvensjon for navnerom. Geosynkronisering vil stille krav om å bruke denne. Fordelen med å anbefale dette generelt, er at vi slipper en sentral administrasjon, og vi får en generell løsning som enkelt kan støttes av alle produsenter og leverandører av geodata og GIS-systemer. Eksempel: NO.KV.NMG Lokal-ID <UID (UUID)(obligatorisk)> Det anbefales å benytte systemgenerert UUID som lokal-id. Dette er et strengere krav enn det INSPIRE legger opp til, men det bryter ikke med prinsippene og det er i henhold til den sterke anbefalingen som er gitt i Rammeverksdokumentet for Norge digitalt. For IKT-utstyr er ofte UUID generert gjennom en kombinasjon av nettverkskortnummer, tid og random seeds. Eksempel: e106adf4-c9d8-4fce-a9b5-7886a4126d23 Uansett må dataeier sikre at en lokal-id er unik innenfor eget navnerom. 5.7 Definisjons- og merknadsangivelser i GML (T) Definisjoner og merknader kan gjøres i GML-applikasjonsskjemaet. Ofte blir disse lagt inn i datamodellen i produktspesifikasjonsarbeidet (eller allerede i SOSI del 2 fagområdemodelleringen), og kommer automatisk med i GMLapplikasjonsskjemaet når dette genereres fra datamodellen. Det er feltet annotation med underfeltet documentation som benyttes for slikt. <TODO - Her må det inn moen anbefalinger om eventuell bruk. Tilfeldige/ustrukturerte kommentarer og merknader har liten verdi hvis det ikke er dokumentert hvordan de skal brukes.> Versjon

54 Eksempel på GML-applikasjonsskjema med merknadsangivelser for egenskapene fylkesnavn og fylkesnummer : <?xml version="1.0" encoding="utf-16"?>... <complextype name="fylketype"> <complexcontent> <extension base="app:administrativenhettype"> <sequence> <element name="fylkesnavn" type="app:administrativenhetnavnpropertytype"> <documentation>offisielle navn på fylket</documentation> </element> <element name="fylkesnummer" type="gml:codetype"> <documentation>nummerering av fylker i henhold til Statistisk sentralbyrå sin offisielle listemerknad:det presiseres at fylkesnummer alltid skal ha 2 siffer, dvs. eventuelt med ledende null. Fylkesnummer benyttes for kopling mot en rekke andre registre som også benytter 2 siffer -- Definition - - official numbering of counties in accordance with Statistics Norway's official list Note: It must be emphasised that county number always consists of 2 digits, i.e. sometimes with leading zero. County number is used for establishing relations to a number of other registers which also use 2 digits</documentation> </element> </sequence> </extension> </complexcontent> </complextype> Bruk av XLink (T) Generelt om bruk av XLink i GML-filer: Det anbefales ikke bruk av eksterne referanser på geometri-elementer. Det anbefales også at man er generelt forsiktig med å bruke XLink til andre typer eksterne referanser. Det anbefales at XLink hovedsakelig brukes for assosiasjoner og at alle egenskaper angis som inline. <TODO - Må få inn en presisering om at det er gml:id XLink peker til. Er usikker på om vi bør/kan innføre en regel som sier at det bare er xlink:href som anbefales brukt?> Bruk av XLink kan illustreres med et fiktivt eksempel fra fagområdet lufthavn og objekttypen lufthavnlys (objekttypenavn og struktur er forenklet for eksempelets skyld). I eksempelet ønsker man å gjenbruke en definert lysprodusent i flere sammenhenger, fremfor å gjenta definisjonen av lysprodusenten hver gang den skal refereres til. På denne måten kan GML-filenes størrelse reduseres og man forenkler vedlikehold av produsentinformasjonen. Versjon

55 Definisjon av lysprodusenten gjøres da kun 1 gang i 1 GML-fil: <app:produsent gml:id= produsent.1 > <app:navn>ge Aero Energy Norway</app:navn> <app:adresse>elektrikerveien 18c</app:adresse> <app:postnummer>0105</app:postnummer> <app:poststed>oslo</app:poststed> </app:produsent> Eksempel på bruk av XLink som referer til lysprodusenten i samme GML-fil: <app:rullebanelys gml:id= rullebanelys.1 > <app:height>90</app:height> <app:produsent xlink:href= #produsent.1 /> </app:rullebanelys> Eksempel på bruk av XLink som referer til lysprodusenten i en annen GML-fil i samme katalog på samme maskin: <app:rullebanelys gml:id= rullebanelys.1 > <app:height>90</app:height> <app:produsent xlink:href= Lysprodusenter.gml#prodsent.1 /> </app:rullebanelys> Eksempel på bruk av XLink som refererer til lysprodusenten i en annen GML-fil som ligger på en annen maskin: <app:rullebanelys gml:id= rullebanelys.1 > <app:height>90</app:height> <app:produsent xlink:href= sent.1 /> </app:rullebanelys> <TODO - inlineorbyreference kan være angitt på assosiasjoner i UML modell som da sier om xlink er lov eller ikke. Standard er at begge er lov. Er det behov for å skille mellom ulike typer assosiasjoner? Viktig å få frem forskjellen på vanlig assosiasjon, aggregering og komposisjon. Komposisjon: sterk avhengighet med et klart Parent-Child forhold. (kan vel sidestilles med dagens multiple egenskaper i SOSI-formatet). Aggregering definerer også et Parent-Child fohold, men bindingen er svakere. Skal man ha en "best practice" for hvordan dette skal se ut på GML-fila? Vi bør ha med mer om assosiasjoner. Også mht. ikke-geometriske assosiasjoner. Kommentar fra Tor Kjetil om inlineorbyreference: Enig. Og vi må ha med litt mer forklaring.> 5.9 Støtte for flere språk (T) <TODO> Om ikke lenge må man regne med at GML-filene og GML-applikasjonsskjemaer må tilbys også på engelsk. Hvordan legge til rette for dette enklest mulig? Versjon

56 5.10 Kvalitetskontroll GML-filer skal lages basert på et GML-applikasjonsskjema. Kvalitetskontroll av GML-filene skal gjøres ved å validere mot GML-applikasjonsskjemaet. I tillegg kan det være aktuelt å legge til Schematronregler for det enkelte GMLapplikasjonsskjema. At GML-filen overholder disse reglene kvalitetssjekkes gjennom Schematronvalidering. Med Schematron-validering kan man altså definere ytterligere spesifiserte regler for hvilke begrensinger eller vilkår som skal sjekkes, i tillegg til de reglene som ligger i GML-applikasjonsskjemaet. Normalt opprettes Schematronreglene i forbindelse med utarbeidelse av datamodellen i produktspesifikasjonen. Beskrankninger i UML-modellen (OCL-constraints) ivaretas i GML-filene ved å overføre disse til Schematronregler. Håpet er at man kan få automatisert produksjon av Schematronregler fra datamodellen i produktspesifiseringsarbeidet Plassering av applikasjonsskjemaer, eksterne kodelister m.m. (T) Forslag: GML-applikasjonsskjemaer, eksterne kodelister og Schematronfiler () skal legges i en katalogstruktur under Det legges opp til et regime med angivelse av plasseringen basert på det man benytter i arbeidet med produktspesifikasjoner: navn på datasettet>/<versjon>/<kodeliste eller applikasjonsskjema>/<navn på filen> Eksempel på plassering av kodeliste: kodelister/kystreferanse.xml Eksempel på plassering av GML-applikasjonsskjema: applikasjonsskjema/kystkontur.xsd Eksempel på plassering av Schematronfil: schematron/kystkontur_schematronregler.sch <TODO - Tror applikasjonsskjema, kodelister og schematron fil bør ligge på samme katalog for at spesielt schematron validering skal fungere. Versjon

57 Foreslår at applikasjonsskjema og tilhørende kodelister legges på samme katalog. Kan da fjerne et nivå i katalogstrukturen. Jeg er litt usikker på hvordan dette slår ut på kodelister som brukes felles for flere produkter. Uansett blir det samme problemet med den foreslåtte katalogstrukturen. Hvis dette skal løses må vi ha en katalogstruktur for kodelister som er uavhengig at hvilke skjema de er brukt i. Det enkleste er antakelig at kodelistene ligger sammen med det viktigste skjemaet for bruken av denne listen, og at andre produkter som bruker samme listen henviser til denne plasseringen.> 5.12 Koordinatsystemer (T) Innen Norge digitalt må man minimum støtte alle EPSG-koder som er definert som påkrevde i henhold til Rammeverksdokumentets kapittel om koordinatsystemer. For utveksling av geografisk informasjon kodet i GML med andre land, kan andre ønskede EPSG-koder benyttes Koordinatsystemer i SOSI-formatet I SOSI brukes KOORDSYS eller GEOSYS for å angi horisontalt datum. VERT- DATUM brukes for å gi vertikalt datum. Fram til i dag har SOSI-data sjelden hatt informasjon om vertikalt datum. Dette har ligget implisitt i form av det offisielle høydesystemet, som har vært Norsk null av 1954 og (tidligere) Nordnorsk null av Innføringen av EUREF89 gir nå større valgmuligheter. I SOSI er det definert svært mange koordinatsystemer, men det er bare en liten del av disse er aktuelle i fastlands-norge Koordinatsystemer i GML Mens SOSI har mekanismer for å angi både horisontalt og vertikalt koordinatsystem, har ikke GML de samme mekanismene. Det er ikke mulig å bruke en kombinasjon av to koordinatsystemer, et vertikalt og et horisontalt, uten at disse er slått sammen til en ny sammensatt ( compound ) koordinatsystemkode. I de fleste praktiske tilfeller av data med høyde får vi kombinasjonen av to koordinatsystemer, ett horisontalt og ett vertikalt. For at dette skal kunne gjengis i GML må det lages sammensatte EPSG-koder. I første omgang lages dette for de mest brukte kombinasjonene. Ved behov utvides dette senere. For liste over gyldige koordinatsystemer til bruk i GML, se Rammeverksdokumentets kapittel om koordinatsystemer (ref til Rammeverksdokumentet i gjeldende versjon). Versjon

58 I første omgang lages det sammensatte koordinatsystemer for alle kombinasjoner av følgende koordinatsystemer: Vertikal o NN54 (urn:ogc:def:crs:epsg::5776 o NN2000 (urn:ogc:def:crs:epsg::5941 Horisontal o EUREF89 UTM sone 32, 33 og 35 o EUREF89 NTM Sone 5-30 o ETRS89 <TODO - Avklaringer: EVRF2000 er erstattet av EVRF2007. Koordinatsystem styrer akseretninger, nord/øst rekkefølge, og dimensjon (med /uten høyde). NN54 er definert som vertikalt CRS EPSG::5776 og vertikalt datum (EPSG::5174). Det er CRS som skal brukes.> De fleste datum og projeksjoner som er angitt over er i 2D, dvs grunnriss. EPSGkodene identifiserer unikt enhver kombinasjon av horisontalt og vertikalt datum. De aller fleste høyder i praktisk bruk i Norge er basert på NN54, og er i utgangspunktet standard. Dersom det er angitt for eksempel x, y og z i en 2D projeksjon som angitt over, er det implisitt en forståelse av at høydedatum er NN54. NN54 er definert som vertikalt CRS EPSG::5776 og vertikalt datum (EPSG::5174). Det fines ingen implisit forståelse av høydedatum i GML! Det er direkte feil å gi xyz i en fil der EPSG-koden tilsier 2D data. All validering skal gi feil på dette Norsk profil av GML (T) Det er jobbet med å definere en norsk profil av GML (hvor? Og hvem?). De GMLskjemaene som foreløpig inngår i en norsk profil er: // Denne inkluderer alle Versjon

59 FeatureCollection (T) I GML er det mulig å definere en FeatureCollection som inneholder en eller flere andre FeatureCollection. Det anbefales ikke å bruke FeatureCollection på denne måten. Det bør kun finnes ett FeatureCollection-element i en GML-fil eller WFSrespons Topologi (T) Det anbefales å bruke geometri fremfor topologi i størst mulig grad. I de UMLapplikasjonsskjemaene der man må benytte topologiske primitiver, kan dette realiseres i GML-applikasjonsskjemaene ved bruk av GMLs topologityper. <TODO - Uklart hva som menes med topologi og geometri savner mer utdypende forklaring. > 5.16 Tidsangivelser (T) Det anbefales å bruke tidsformatet <yyyy-mm-dd tt:mm:ss>. <TODO - I Erlings XML-validator kreves yyy-mmm-ddttt:mm:ss for å slippe gjennom, med referanse til xmlns:gml= med metadata (ISO19115-eksempel)> Eksempel: :58:33 Det anbefales å bruke lokaltid, med mindre spesielle forhold tilsier at det bør brukes zulutid Tematiske flatedekkende representasjoner (coverage) (T) <TODO - Brukseksempel: DTM10 som rektifisert grid i coverage? Noen spesielle anbefalinger?> Se for øvrig eksempelet Bestille et coverage som inneholder GML-elementer. Versjon

60 6 Programvare Dette kapittelet gir eksempler på ulike typer programvare for GML, og hvordan disse håndterer GML-applikasjonsskjemaene og GML-filer. Programvareleverandørene oppfordres til å komme med korte beskrivelser av egen GML-programvare for presentasjon i denne veilederen. 6.1 Programvare for editering av GML-filer For å editere GML-applikasjonsskjemaer eller GML-filer, kan man bruke vanlige teksteditorer som Notepad, WordPad, jedit og lignende. Men i de fleste av disse får man liten eller ingen hjelp til å validere mot GML-skjemaene. Man får heller ikke hjelp av programvaren med hvilke elementer som henger sammen og således må brukes i spesielle sekvenser. Derfor er det oftest en stor fordel å benytte mer avanserte XML-editorer eller spesialiserte GML-editorer. Eksempler på avanserte XML-editorer er Oxygen og XMLSpy. Eksempler på spesialiserte GML-editorer er FYSAK og ArcGIS. Figur 16 - Visning av GML-applikasjonsskjema i XMLSpy 6.2 Programvare for visning av GML-fil som kartbilde Eksempler på programvare som kan vise en GML-fil som et kartbilde er Gaia, QGIS, udig, ArcGIS og FYSAK, Snowflake GML Viewer og ISY WinMap/GeoMedia. Versjon

61 Figur 17 - Visning av GML-fil som kartbilde i QGIS 6.3 Programvare for å tilby WFS-tjenester med GML-respons For å sette opp tjenester der GML er responsformatet kan man i utgangspunktet bruke alle typer programvare som er laget for generelle tjenesteformål, men det kan være besparende å bruke dedikert GIS-programvare. Eksempler på slike er Geoserver, Deegree, ArcGIS Server, GeoMedia WebMap, Erdas Apollo. 6.4 Programvare for å validere GML-filer (T) For å kontrollere velformethet i henhold til XML-syntaks kan man bruke de fleste XML-editorer, som f.eks XMLSpy, Oxygen m.fl. For å validere en GML-fil mot tilhørende GML-applikasjonsskjema, kan også de fleste XML-editorer benyttes. I tillegg kan også en del GIS-programvare validere GML-filer mot GML-applikasjonsskjemaet. Eksempler er ArcGIS, Gaia, OGIS og udig. Versjon

62 For å kontrollere innholdet i en GML-fil i henhold til Schematronregler kreves egne validatorer som for eksempel XML ValidatorBuddy ( Et annet verktøy som kan validere en GML-fil mot en Schematronfil er det kommandolinjebaserte verktøyet Probatron ( Eksempel på kommando for å gjøre en Schematron-validering av en GML-fil med Probatron: java -jar probatron.jar Fylke.gml Schematronregler.sch Men også OGC har laget en egen TestSuite med verktøy som gjør det mulig å validere mot både GML-applikasjonsskjemaer og Schematronfiler. Blant annet finnes en REST-tjeneste som kan benyttes direkte fra nettleseren. Se r11/web/overview.html for mer info om denne. OGC har også flere andre testverktøy for ulike tjenestetyper og OGCspesifikasjoner. Mer info om disse finner du på Versjon

63 7 Geometrityper for nasjonalt harmoniserte datasett (T) <TODO - Her kan det være nyttig med en liste over de GML-geometritypene som er benyttet og antas å skulle benyttes i SOSI produktspesifikasjoner. Det kan også være nyttig med en oversikt over hvilke geometrityper i SOSI som tilsvarer hvilke geometrityper i INSPIRE annexene og/eller vice versa.> Versjon

64 8 Geometrityper for INSPIRE-harmoniserte datasett (T) En komplett oversikt over objekttypene som benyttes i INSPIRE Annex I finnes i INSPIREs objektkatalog på En komplett oversikt over objekttypene som benyttes i INSPIRE Annex II og III finnes i INSPIREs objektkatalog på <TODO her kan det være nyttig med en liste over de GML-geometritypene som benyttes og antas å skulle benyttes i INSPIRE-harmoniserte datasett, gjerne gruppert pr annex.> Versjon

65 9 Krav og anbefalinger 9.1 Krav ID Krav Merknad 1 Alle leveranser skal benytte UTF-8 som tegnsettkoding, både i datasett, tjenester og dokumentasjon, ref Forskrift om ITstandarder i offentlig forvaltning ( html) 2 Alle leveranser skal benytte GML versjon eller nyere. 3 Dataeier må sikre at lokal-id er er unike innenfor eget navnerom. 4 GML-applikasjonsskjemaer, eksterne kodelister og Schematronfiler skal legges i en nærmere angitt katalogstruktur under Anbefalinger ID Anbefaling Merknad 1 Det anbefales at XLink hovedsakelig brukes for assosiasjoner mot ikke-geometriske elementer og at alle egenskaper angis som inline. 2 Det anbefales ikke å bruke FeatureCollection i en FeatureCollection. 3 Det anbefales å bruke lokaltid fremfor zulutid som grunnlag for tidsangivelser. Hva menes med dette? Feil? 4 Det anbefales å bruke geometri fremfor topologi i størst mulig grad. 5 Ved delt geometri legges geometrien på linje-objektet, og refereres fra tilstøtende flater. Versjon

66 6 Versjon

67 10 Figurliste Figur 1 - Sammenhengen mellom de ulike veilederdokumentene og relaterte dokumenter... 8 Figur 2 - Grunnsteinene i GML Figur 3 - Prinsippet i forholdet mellom objekttyper og objekter Figur 4 - Definisjon av objekttype med tilhørende objekt Figur 5 - De overordnede elementene i General Feature Model Figur 6 - Hovedrelasjonsprinsippene i GML Figur 7 - Detaljerte relasjonsprinsipper i GML Figur 8 - Valideringstypene som ivaretar de 3 kvalitetsnivåene for GML-filer Figur 9 - Hovedprinsippet i skjemavalidering Figur 10 - Realisering av produktspesifikasjoner i GML og SOSI Figur 11 - GML og produktspesifikasjoner Figur 12 - Dataharmonisering på nasjonalt- og INSPIRE-nivå Figur 13 - Bruker lokaliserer og laster ned GML-filer fra nasjonal geoportal Figur 14 - Publisering av datasett basert på GML-applikasjonsskjema Figur 15 - Bruker som benytter tjenester som leverer GML Figur 16 - Visning av GML-applikasjonsskjema i XMLSpy Figur 17 - Visning av GML-fil som kartbilde i QGIS Versjon

68 Vedlegg A Brukstilfeller og eksempler Brukstilfellene er ikke gode nok. En del av dem er kunstige. Eksempelvis er A2 uaktuell. Foreslår at det må tas en ny runde på dette. Brukstilfellene må ligge nærmere opp mot utveksling av geodata. Knut: Dette er vi enige om, men noen må produsere eksemplene! A.1 Se på innholdet i en GML-fil uc Se på innholdet i en GML-fil GML-fil 1 Hente fil 1.1 Åpne fil Skjemaserv er Se på innholdet i en GML-fil 2 Validere fil Bruker GML-applikasjon 2.1 Vise filinnhold Dette brukstilfellet beskriver hvordan en bruker kan se på innholdet i en GML-fil. Brukstilfellebeskrivelse Navn Se på innholdet i en GML-fil Prioritet Umiddelbart svar Beskrivelse En sluttbruker ønsker å se innholdet i en GML-fil. Versjon

69 Brukstilfellebeskrivelse Før-tilstand Flyt Bruker har skaffet tilgang til en GML-fil og har tilgang til en applikasjon som kan vise innholdet i en GML-fil 1 Bruker kopiererer GML-filen til sitt lokale miljø. 1.1 Bruker åpner GML-filen i applikasjonen 2 Applikasjonen henter alle refererte skjema og validerer dataene. 2.1 Applikasjonen viser innholdet i GML-filen i henhold til skjema. Etter-tilstand Datakilde Beskrivelse Datatilbyder Geografisk område Tematisk område Detaljeringsgrad Leveranse Bruker ser en validert GML-fil. Eks: filnedlasting.geonorge.no Eks: Kartverket Eks: Norske territorier og havområder, med biland. Eks: Alle typer offentlig geografisk informasjon Eks: Fra internasjonalt nivå ned til det mest detaljerte lokalnivå. Geografiske objekter på vektorform. Dokumentasjon Produktspesifikasjon, ISO 19136: GML Eksempel på innhold i en GML fil (GML 3.2.1): <?xml version="1.0" encoding="utf-8"?> <gml:featurecollection xmlns:gts=" xmlns:gco=" xmlns:ns1=" xmlns:hfp=" xmlns:gml=" xmlns:app=" " xmlns:gss=" xmlns:gsr=" xmlns:gmd=" xmlns:xlink=" xmlns:xsi=" gml:id="_019a916d-80b2-41e3- b44e-a7e3b765ff57" xsi:schemalocation=" rming/1.0 file:/c:/users/test/documents/workspace/enterprisearchitect/xsd/universellutforming.xs d"> <gml:featuremember> <app:tilgjengeligveg gml:id="_a460c5ea-6be be6b381c591"> <app:førstedatafangstdato> T00:00:00Z</app:førsteDatafangstdato> <app:oppdateringsdato> T00:00:00Z</app:oppdateringsdato> <app:opphav>statens kartverk</app:opphav> <app:kommune>0616</app:kommune> <app:målemetode>direkte innlagt på skjerm</app:målemetode> <app:bilde></app:bilde> <app:kommentar></app:kommentar> <app:tilgjengelighetsvurderingbevegelse> Tilgjengelig</app:tilgjengelighetsvurderingBevegelse> <app:posisjon> <gml:linestring gml:id="_23bc4c1f-abbe-41f8-ba21- b98ea310dc65"> <gml:coordinates decimal="." cs="," ts=" ">177003, , </gml:coordinates> Versjon

70 </gml:linestring> </app:posisjon> <app:gatetype>sti</app:gatetype> <app:bredde>115</app:bredde> <app:dekke>asfalt</app:dekke> <app:møteplass>false</app:møteplass> <app:varmekabel>true</app:varmekabel> <app:stigningsforhold>1:10</app:stigningsforhold> <app:tverrfall>1:08</app:tverrfall> <app:vegdekketilstand>ujevnt</app:vegdekketilstand> <app:ledelinje>ikke vurdert</app:ledelinje> <app:ledelinjekontrast>god</app:ledelinjekontrast> </app:tilgjengeligveg> </gml:featuremember> </gml:featurecollection> A.2 Endre innhold i en GML-fil uc Endre innholdet i en GML-fil GML-fil 1 Hente fil 1.1 Åpne fil Skjemaserv er Endre innhold i en GML-fil 2 Validere fil Bruker GML-applikasjon 3 Endre data 4 Validere endrede data 4.1 Oppdatere filinnhold Dette brukstilfellet beskriver hvordan en bruker endrer data i en GML-fil. Brukstilfellebeskrivelse Navn Endre innhold i en GML-fil Prioritet Umiddelbart svar Beskrivelse En sluttbruker skal arbeide med en GML-fil. Versjon

71 Brukstilfellebeskrivelse Før-tilstand Flyt Bruker har skaffet tilgang til en GML-fil og har tilgang til en applikasjon som kan vise og endre GML-filer 1 Bruker kopiererer GML-filen til sitt lokale miljø. 1.1 Bruker åpner GML-filen i applikasjonen 2 Applikasjonen henter alle refererte skjema og validerer dataene. 3 Bruker endrer data i GML-filen 4 Applikasjonen validerer de endrede dataene iht. innhentede skjema 4.1 Applikasjonen oppdaterer data i GML-filen i henhold til skjema. Etter-tilstand Datakilde Beskrivelse Datatilbyder Geografisk område Tematisk område Detaljeringsgrad Leveranse Bruker har en validert og oppdatert GML-fil. Eks: filnedlasting.geonorge.no Eks: Kartverket Eks: Norske territorier og havområder, med biland. Eks: Alle typer offentlig geografisk informasjon Eks: Fra internasjonalt nivå ned til det mest detaljerte lokalnivå. Geografiske objekter på vektorform. Dokumentasjon Produktspesifikasjon, ISO 19136:2007 GML Versjon

72 A.3 Validere en GML-fil uc Validere en GML-fil GML-fil 1 Hente fil 1.1 Åpne fil Validere GML-fil 2 Lese fil Skjemaserv er Bruker 2 Hente skjemaer 3 Starte validering 3.1 Validere fil GML-applikasjon 3.2 Vise v alideringsstatus Dette brukstilfellet beskriver hvordan en bruker validerer en GML-fil Brukstilfellebeskrivelse Navn Prioritet Beskrivelse Før-tilstand Flyt Validere en GML-fil Umiddelbart svar En sluttbruker vil validere en GML-fil. Bruker har skaffet tilgang til en GML-fil og har tilgang til en applikasjon som kan vise og validere GML-filer. 1 Bruker kopiererer GML-filen til sitt lokale miljø. 1.1 Bruker åpner GML-filen i applikasjonen 2 Applikasjonen leser filen Versjon

73 Brukstilfellebeskrivelse 2.1 Applikasjonen innhenter alle refererte skjemaer fra skjemaserver(e) 3 Bruker velger å validere GML-filen 3.1 Applikasjonen validerer innholdet iht innhentede skjemaer 3.2 Applikasjonen gir bruker beskjed om utfallet av valideringen Etter-tilstand Datakilde Beskrivelse Datatilbyder Geografisk område Tematisk område Detaljeringsgrad Leveranse Bruker har en validert GML-fil. Eks: skjema.geonorge.no Eks: Kartverket Eks: Norske territorier og havområder, med biland. Eks: Alle typer offentlig geografisk informasjon Eks: Fra internasjonalt nivå ned til det mest detaljerte lokalnivå. Geografiske objekter på vektorform. Dokumentasjon Produktspesifikasjon, ISO 19136: GML Versjon

74 A.4 Lage en GML-fil fra et datasett uc Lage en GML-fil fra et datasett GML-fil 1 Åpne datasettet 1.1 Velge å lage GML 2 Lage GML Lage GML-fil fra datasett 3 Åpne GML-fil Bruker GML-applikasjon 3.1 Velge å v alidere GML-fil 4 Validere GML-fil Skjemaserv er 4.1 Vise v alideringsstatus Dette brukstilfellet beskriver hvordan en bruker kan lage en GML-fil fra et datasett. Brukstilfellebeskrivelse Navn Lage en GML-fil fra et datasett Prioritet Umiddelbart svar Versjon

75 Brukstilfellebeskrivelse Beskrivelse Før-tilstand Flyt En sluttbruker vil produsere en GML-fil fra et eget datasett Bruker har skaffet tilgang til datasettet og har tilgang til en applikasjon som kan åpne datasettet og produsere og validere GML-filer. 1 Bruker åpner datasettet i applikasjonen 1.1 Bruker velger å eksportere datasettet som GML 2 Applikasjonen produserer en GML-fil fra datasettet 3 Bruker åpner GML-filen i applikasjonen 3.1 Bruker velger å validere GML-filen 4 Applikasjonen validerer innholdet iht innhentede skjemaer 4.1 Applikasjonen gir bruker beskjed om utfallet av valideringen Etter-tilstand Datakilde Beskrivelse Datatilbyder Geografisk område Tematisk område Detaljeringsgrad Leveranse Bruker har en validert GML-fil fra datasettet. Eks: Eks: Kartverket Eks: Norske territorier og havområder, med biland. Eks: Alle typer offentlig geografisk informasjon Eks: Fra internasjonalt nivå ned til det mest detaljerte lokalnivå. Geografiske objekter på vektorform. Dokumentasjon Produktspesifikasjon, ISO 19136: GML Versjon

76 A.5 Konvertere et datasett fra SOSI til GML uc Konv ertere et datasett fra SOSI til GML GML-fil 1 Åpne SOSI-fil 1.1 Velge å konv ertere SOSI-fil Bruker Konv ertere datasett fra SOSI til GML 2 Konv ertere SOSI-fil SOSI og GML applikasjon 3 Åpne GML-filen 3.1 Velge å v alidere GML-filen 4 Validere Skjemaserv er 4.1 Vise v alideringsstatus Dette brukstilfellet beskriver hvordan en bruker kan konvertere et datasett fra SOSI til en GML-fil. Brukstilfellebeskrivelse Navn Konvertere et datasett fra SOSI til GML Prioritet Umiddelbart svar Beskrivelse En sluttbruker vil konvertere en SOSI-fil til GML. Versjon

77 Brukstilfellebeskrivelse Før-tilstand Flyt Bruker har skaffet tilgang til en SOSI-fil og har tilgang til en applikasjon som kan konvertere fra SOSI til GML og validere GML-filer. 1 Bruker åpner SOSI-filen i applikasjonen 1.1 Bruker velger å konvertere SOSI-filen til GML 2 Applikasjonen konverterer SOSI-filen til GML 3 Bruker åpner GML-filen 3.1 Bruker velger å validere GML-filen 4 Applikasjonen validerer innholdet iht innhentede skjemaer 4.1 Applikasjonen gir bruker beskjed om utfallet av valideringen Etter-tilstand Datakilde Beskrivelse Datatilbyder Geografisk område Tematisk område Detaljeringsgrad Leveranse Bruker har en validert GML-fil. Eks: Eks: Kartverket Eks: Norske territorier og havområder, med biland. Eks: Alle typer offentlig geografisk informasjon Eks: Fra internasjonalt nivå ned til det mest detaljerte lokalnivå. Geografiske objekter på vektorform. Dokumentasjon Produktspesifikasjon, ISO 19136: GML Versjon

78 A.6 Konvertere et datasett fra Shape til GML Brukstilfellet har samsvarende bruksmønster med konvertering fra andre formater. Se diagram for Konvertere et datasett fra SOSI til GML. Brukstilfellebeskrivelse Navn Prioritet Beskrivelse Før-tilstand Flyt Konvertere et datasett fra Shape til GML Umiddelbart svar En sluttbruker vil vil konvertere en Shape-fil til GML. Bruker har skaffet tilgang til en Shape-fil og har tilgang til en applikasjon som kan konvertere fra Shape til GML og validere GML-filer. 1 Bruker åpner Shape-filen i applikasjonen 1.1 Bruker velger å konvertere Shape-filen til GML 2 Applikasjonen konverterer Shape-filen til GML 3 Bruker åpner GML-filen 3.1 Bruker velger å validere GML-filen 4 Applikasjonen validerer innholdet iht innhentede skjemaer 4.1 Applikasjonen gir bruker beskjed om utfallet av valideringen Etter-tilstand Datakilde Beskrivelse Datatilbyder Geografisk område Tematisk område Detaljeringsgrad Leveranse Bruker har en validert GML-fil. Eks: skjema.geonorge.no Eks: Kartverket Eks: Norske territorier og havområder, med biland. Eks: Alle typer offentlig geografisk informasjon Eks: Fra internasjonalt nivå ned til det mest detaljerte lokalnivå. Geografiske objekter på vektorform. Dokumentasjon Produktspesifikasjon, ISO 19136: GML Versjon

79 A.7 Dele GML-filer med nasjonale parter uc Dele GML-fil med nasjonale parter GML-fil 1 Logge inn på Geonorge 1.1 Velge å laste opp GML-fil Dele GML-fil med nasjonale parter 2 Laste opp GML-fil Geonorge Bruker 2.1 Hente refererte skjemaer Skjemaserv er 2.2 Validere GML-fil 2.3 Vise v alideringsstatus Dette brukstilfellet beskriver hvordan en bruker kan dele en GML-fil med nasjonale parter i Norge digitalt. Brukstilfellebeskrivelse Navn Prioritet Beskrivelse Før-tilstand Dele GML-filer med nasjonale parter Umiddelbart svar En sluttbruker vil dele en GML-fil med nasjonale parter i Norge digitalt Bruker har skaffet tilgang til en GML-fil og har gyldig brukernavn og passord til geonorge.no Versjon

80 Brukstilfellebeskrivelse Flyt 1 Bruker logger inn på Bruker velger å laste opp GML-filer 2 Geonorge laster opp GML-filen 2.1 Geonorge innhenter alle refererte skjemaer fra skjemaserver(e) 2.2 Geonorge validerer GML-filen 2.3 Geonorge gir bruker beskjed om utfallet av valideringen Etter-tilstand Bruker har delt en valid GML-fil. Datakilde Beskrivelse Eks: skjema.geonorge.no Datatilbyder Eks: Kartverket Geografisk område Eks: Norske territorier og havområder, med biland. Tematisk område Eks: Alle typer offentlig geografisk informasjon Detaljeringsgrad Eks: Fra internasjonalt nivå ned til det mest detaljerte lokalnivå. Leveranse Geografiske objekter på vektorform. Dokumentasjon Produktspesifikasjon, ISO 19136: GML Versjon

81 A.8 Dele GML-filer med institusjoner i andre land <TODO> Brukstilfellebeskrivelse Navn Prioritet Beskrivelse Før-tilstand Flyt Dele en GML-fil med institusjoner i andre land Umiddelbart svar En sluttbruker vil dele en GML-fil med institusjoner i andre land. Bruker har skaffet tilgang til en GML-fil og har tilgang til 2 Applikasjonen laster opp filen 2.1 Applikasjonen innhenter alle refererte skjemaer fra skjemaserver(e) 3.1 Applikasjonen validerer innholdet iht innhentede skjemaer 3.2 Applikasjonen gir bruker beskjed om utfallet av valideringen Etter-tilstand Datakilde Beskrivelse Datatilbyder Geografisk område Tematisk område Detaljeringsgrad Leveranse Bruker har en validert GML-fil. Eks: skjema.geonorge.no Eks: Kartverket Eks: Norske territorier og havområder, med biland. Eks: Alle typer offentlig geografisk informasjon Eks: Fra internasjonalt nivå ned til det mest detaljerte lokalnivå. Geografiske objekter på vektorform. Dokumentasjon Produktspesifikasjon, ISO 19136: GML Versjon

82 A.9 Bestille objektinformasjon som GML fra en WFS-tjeneste uc Bestille objektegenskapsverdier som GML fra en WFS-tjeneste GML-fil 1 Velge objekt 1.1 Bestille objektbeskriv elsen 2 Generere WFS-forespørsel 2.1 Sende GetFeature forespørsel 3 Motta GetFeature forespørsel Bruker Bestille objektbeskriv else som GML fra WFS-tjeneste 3.1 Generere GetFeature GML respons WFS-tjeneste WFS-klientapplikasjon 4.3 Vise objektbeskriv elsen 3.2 Sende GetFeature respons 4.2 Formatere objektbeskriv elsen 4 Motta GetFeature respons 4.1 Validere GML Dette brukstilfellet beskriver hvordan en bruker bestiller objektinformasjon som GML fra en WFS-tjeneste (GetFeature). Brukstilfellebeskrivelse Navn Bestille objektbeskrivelser i GML fra en WFS-tjeneste Prioritet Umiddelbart svar Beskrivelse En bruker etterspør et sett med utvalgte geografiske objekter. Versjon

83 Brukstilfellebeskrivelse Før-tilstand Flyt Bruker har tilgang til en applikasjon som er koblet mot en WFStjeneste, og applikasjonen gir bruker mulighet til å velge hvilke(t) objekt(er) som det skal vises tekstlige egenskaper for 1 Bruker velger hvilket objekt som skal beskrives 1.1 Bruker velger å bestille beskrivelsen Applikasjonen genererer en filterspørring og legger i en WFSforespørsel om objektbeskrivelse (GetFeature) Applikasjonen sender WFS-forespørselen og ber om objektinformasjonen (GetFeature) 3 WFS-tjenesten mottar WFS-forespørselen (GetFeature) 3.1 WFS-tjenesten genererer en respons iht filterspørringen (GetFeature) 3.2 WFS-tjenesten sender responsen til applikasjonen (Getfeature) 4 Applikasjonen mottar responsen (GetFeature) Etter-tilstand Datakilde Beskrivelse Datatilbyder Geografisk område Tematisk område Detaljeringsgrad Leveranse Dokumentasjon Applikasjonen parser responsen, henter alle refererte skjema og validerer objektene Applikasjonen genererer en menneskelig lesbar beskrivelse av objektinformasjonen Applikasjonen viser den menneskelig lesbare objektinformasjonen til bruker Bruker ser de tekstlige beskrivelsene for de utvalgte objektene. Nedlastingstjeneste (WFS) Eks: Deltagende part. Eks: Norske territorier og havområder, med biland. Eks: Alle typer offentlig geografisk informasjon Eks: Fra internasjonalt nivå ned til det mest detaljerte lokalnivå. Geografiske objekter på vektorform. Produktspesifikasjon, ISO 19136: GML ISO 19142:2010 WFS 2.0, ISO 19143:2010 Filter Encoding 2.0 Eksempel på WFS 2.0 respons med GML (GML 3.2.1): <?xml version="1.0" encoding="utf-8"?> <wfs:featurecollection numbermatched="1" numberreturned="1" timestamp=" T13:21:48.234Z" xsi:schemalocation=" Versjon

84 ype&typename=app:hc-parkering"> <wfs:boundedby> <gml:envelope> <gml:lowercorner> </gml:lowerCorner> <gml:uppercorner> </gml:upperCorner> </gml:envelope> </wfs:boundedby> <wfs:member> <app:hc-parkering gml:id="hc-parkering.902"> <gml:boundedby> <gml:envelope srsdimension="2" srsname="urn:ogc:def:crs:epsg::4258"> <gml:lowercorner> </gml:lowerCorner> <gml:uppercorner> </gml:upperCorner> </gml:envelope> </gml:boundedby> <app:ogc_fid>902</app:ogc_fid> <app:førstedatafangstdato> t09:31:29z</app:førstedatafangstdato> <app:oppdateringsdato> t09:31:29z</app:oppdateringsdato> <app:identifikasjon>9998</app:identifikasjon> <app:opphav>statens kartverk</app:opphav> <app:digitaliseringsmålestokk>1000</app:digitaliseringsmålestokk> <app:kommune>0105</app:kommune> <app:målemetode>direkte innlagt på skjerm</app:målemetode> <app:nøyaktighet>1: 5000, nøyaktighet= 2 m</app:nøyaktighet> <app:posisjon> <gml:point srsdimension="2" srsname="urn:ogc:def:crs:epsg::4258"> <gml:pos> </gml:pos> </gml:point> </app:posisjon> <app:overbygg>nei</app:overbygg> <app:avstandservicebygg>25</app:avstandservicebygg> <app:bredde>0</app:bredde> <app:lengde>0</app:lengde> <app:hc_skilt>ja</app:hc_skilt> <app:merket_hc>nei</app:merket_hc> <app:avgift_hc>nei</app:avgift_hc> <app:bilde> </app:bilde> </app:hc-parkering> </wfs:member> </wfs:featurecollection> Versjon

85 A.10 Bestille objektinformasjon som GML fra WMS getfeatureinfo uc Bestille objektegenskapsverdier som GML fra WMS GetFeatureInfo GML-fil 1 Bestille rasterbilde 1.1 Velge objekt 2 Sende GetFeatureInfo forespørsel Bruker Bestille objektbeskriv else som GML fra WFS-tjeneste 3 Motta GetFeatureInfo forespørsel WMS-tjeneste 3.1 Generere GetFeatureInfo respons 4.2 Vise objektinformasjonen WMS-klientapplikasjon 4.1 Formatere objektinformasjonen 3.2 Sende GetFeatureInfo respons Validere GML 4 Motta GetFeatureInfo respons Dette brukstilfellet beskriver hvordan en bruker bestiller objektinformasjon som GML fra en WMS-tjeneste, som returnerer GML-beskrevet vektorinformasjon for det enkelte objekt. Use Case beskrivelse Navn Prioritet Beskrivelse Bestille objektinformasjon i GML fra WMS-GetFeatureInfo Umiddelbart svar En sluttbruker vil ha detaljinformasjon om et objekt i et WMSrasterbilde. Versjon

86 Use Case beskrivelse Før-tilstand Bruker har tilgang til en applikasjon som er koblet mot en WMStjeneste med mulighet for GetFeatureInfo-spørringer. Flyt 1 Bruker henter et WMS-rasterbilde fra WMS-tjenesten på normal måte. 1.1 Bruker velger hvilken forekomst som skal beskrives 2 Applikasjonen sender en forespørsel til WMS-tjenesten (GetFeatureInfo) 3 WMS-tjenesten mottar forespørselen (GetFeatureInfo) 3.1 WMS-tjenesten genererer en respons med en objektinformasjon i GML iht forespørselen 3.2 WMS-tjenesten sender responsen til applikasjonen 4 Applikasjonen mottar responsen og validerer GML-beskrivelsen av objektet mot refererte skjema. 4.1 Applikasjonen omformer GML-responsen til f. eks. svg og xhtml. 4.2 Applikasjonen viser objektinformasjonen. Etter-tilstand Datakilde Beskrivelse Datatilbyder Geografisk område Tematisk område Detaljeringsgrad Leveranse Dokumentasjon Bruker ser objektinformasjonen Visningstjeneste (WMS) Eks: Kartverket Eks: Norske territorier og havområder, med biland. Eks: Alle typer offentlig geografisk informasjon Eks: Fra internasjonalt nivå ned til det mest detaljerte lokalnivå. Geografiske objekter på vektorform. Produktspesifikasjon, ISO 19136: GML 3.2.1, ISO19128:2005 WMS Versjon

87 A.11 Bestille coverage som inneholder GML-elementer uc Bestille coverage som inneholder GML-elementer GML-fil 1 Velge cov erage 2 Generere WCS forespørsel 2.1 Sende WCS forespørsel Bruker Bestille cov erage som inneholder GML-elementer 3 Motta WCS forespørsel WCS-tjeneste 3.1 Generere WCS GML respons WCS-klientapplikasjon 4.3 Vise objektet og objektinformasjonen 3.2 Sende WCS respons 4.2 Formatere objektinformasjonen 4 Motta WCS respons 4.1 Validere GML Dette brukstilfellet beskriver hvordan en bruker bestiller et coverage som inneholder GMLelementer. Use Case beskrivelse Navn Prioritet Beskrivelse Bestille coverage som inneholder GML-elementer Umiddelbart svar En bruker etterspør et coverage med informasjon på vektorformat. Versjon

88 Use Case beskrivelse Før-tilstand Bruker har tilgang til en applikasjon som er koblet mot en WCStjeneste med mulighet for vektordata. Flyt 1 Bruker velger hvilket coverage som skal bestilles 2 Applikasjonen lager en WCS forespørsel 2.1 Applikasjonen sender en WCS forespørsel til WCS-tjenesten og bestiller det angitte coverage 3 WCS-tjenesten mottar forespørselen 3.1 WCS-tjenesten genererer en respons iht forespørselens innhold 3.2 WCS-tjenesten sender responsen til applikasjonen 4 Applikasjonen mottar responsen 4.1 Applikasjonen mottar responsen og validerer GML-beskrivelsen av objektene mot refererte skjema. 4.2 Applikasjonen omformer GML-responsen til f. eks. svg og xhtml. 4.3 Etter-tilstand Datakilde Beskrivelse Datatilbyder Geografisk område Tematisk område Detaljeringsgrad Leveranse Dokumentasjon Applikasjonen tegner vektorgeometrien og viser objektinformasjonen Bruker har en validert og eventuelt oppdatert GML-fil. Eks: wcs.geonorge.no Eks: Kartverket Eks: Norske territorier og havområder, med biland. Eks: Alle typer offentlig geografisk informasjon Eks: Fra internasjonalt nivå ned til det mest detaljerte lokalnivå. Geografiske objekter på vektorform. Produktspesifikasjon, ISO 19136: GML 3.2.1, OGC-standard WCS 2.0 OGC-document r3, OGC-standard WCS Processing_Extension_WCPS r3,... Eksempel på GML-elementer brukt i et coverage (GML 3.2.1): <?xml version="1.0" encoding="utf-8"?> <cv:cv_discretecoverage gml:id="dc5" xmlns:cv=" xmlns:xsi=" xmlns:xlink=" xmlns:gml=" xsi:schemalocation=" <cv:domainextent> Versjon

89 <gml:timeperiod> <gml:beginposition> t09:00: :00</gml:beginposition> <gml:endposition> t09:00: :00</gml:endposition> </gml:timeperiod> </cv:domainextent> <cv:rangetype xsi:type="gml:referencetype" xlink:href=" <cv:element> <cv:cv_geometryvaluepair> <cv:geometry> <cv:cv_domainobject> <cv:temporalelement> <gml:timeperiod gml:id="tp1"> <gml:beginposition> T09:00+08:00</gml:beginPosition> <gml:endposition> t09:00+08:00</gml:endposition> <gml:duration>pt24h</gml:duration> </gml:timeperiod> </cv:temporalelement> </cv:cv_domainobject> </cv:geometry> <cv:value xsi:type="gml:measuretype" uom="mm">10.1</cv:value> </cv:cv_geometryvaluepair> </cv:element> <cv:element> <cv:cv_geometryvaluepair> <cv:geometry> <cv:cv_domainobject> <cv:temporalelement> <gml:timeperiod gml:id="tp2"> <gml:beginposition> T09:00+08:00</gml:beginPosition> <gml:endposition> t09:00+08:00</gml:endposition> <gml:duration>pt24h</gml:duration> </gml:timeperiod> </cv:temporalelement> </cv:cv_domainobject> </cv:geometry> <cv:value xsi:type="gml:measuretype" uom="mm">15.7</cv:value> </cv:cv_geometryvaluepair> </cv:element> </cv:cv_discretecoverage> Versjon

90 A.12 Bruke GML i WFS-T Insert, Update, Replace eller Delete uc Bruke GML i WFS-T GML-fil 1 Velge objekt 2 Generere WFS-T forespørsel Bruke GML i WFS-T Insert, Update, Replace eller Delete 2.1 Sende WFS-T forespørsel Bruker 3 Motta WFS-T forespørsel WFS-T-tjeneste 3.1 Utføre databaseendringer WFS-T-klientapplikasjon 3.2 Sende WFS-T respons Database Bestille objektbeskriv else som GML fra en WFS-tjeneste 4 Motta WFS-T respons Dette brukstilfellet beskriver bruk av GML i en WFS-T Insert, Update, Replace eller Delete forespørsel. Use Case beskrivelse Navn Prioritet Beskrivelse Før-tilstand Bruke GML i en WFS-T Insert, Update, Replace eller Delete Umiddelbar respons En bruker oppretter/oppdaterer geografiske data beskrevet i GML via WFS-T grensesnitt Bruker har tilgang på en applikasjon som er koblet mot en WFStjeneste som støtter transaksjoner Versjon

91 Use Case beskrivelse Flyt 1 2 Bruker velger i applikasjonen hvilke(t) objekt/objekter som skal opprettes/endres/erstattes/slettes Applikasjonen lager en WFS-T forespørsel (Insert, Update, Replace eller Delete) med GML-objektinformasjon basert på GMLskjemaet for valgt objekt. 2.1 Applikasjonen sender WFS-T forespørselen til WFS-tjenesten 3 WFS-tjenesten mottar WFS-T forespørselen 3.1 WFS-tjenesten utfører endringene på dataene mot databasen 3.2 WFS-tjenesten sender en respons til applikasjonen 4 Applikasjonen mottar responsen 4.1 Applikasjonen lager en forespørsel og ber om det/de nye/endrede objekt/objektene (GetFeature) 4.2 Applikasjonen sender forespørselen (GetFeature) 5 WFS-tjenesten mottar forespørselen 5.1 WFS-tjenesten lager en respons iht forespørselen 5.2 WFS-tjenesten sender responsen til applikasjonen 6 Applikasjonen mottar responsen 6.1 Etter-tilstand Datakilde Beskrivelse Datatilbyder Geografisk område Tematisk område Detaljeringsgrad Leveranse Dokumentasjon Applikasjonen tolker responsen og viser objektinformasjonen til bruker, og/eller tegner objektet visuelt Datakilden er oppdatert iht brukers valg Oppdateringstjeneste (WFS-T) Eks: Kartverket Eks: Norske territorier og havområder, med biland. Eks: Alle typer offentlig geografisk informasjon Eks: Fra internasjonalt nivå ned til det mest detaljerte lokalnivå. Geografiske objekter på vektorform. Produktspesifikasjon, ISO 19136: GML ISO 19142:2010 WFS 2.0, ISO 19143:2010 Filter Encoding 2.0 Eksempel på WFS-T 2.0 insert forespørsel der GML brukes for å angi objektets posisjon (geometri) (GML 3.2.1): <?xml version="1.0" encoding="utf-8"?> <wfs:transaction version="2.0.0" service="wfs" Versjon

92 xmlns:app=" " xmlns:gml=" xmlns:wfs=" xmlns:xsi=" xsi:schemalocation=" rming/1.0 UniversellUtforming.xsd <wfs:insert> <app:hc-parkering gml:id="hc-parkering.892"> <gml:boundedby> <gml:envelope srsdimension="2" srsname="urn:ogc:def:crs:epsg::32633"> <gml:lowercorner> </gml:lowerCorner> <gml:uppercorner> </gml:upperCorner> </gml:envelope> </gml:boundedby> <app:ogc_fid>892</app:ogc_fid> <app:wkb_geometry> <gml:point srsdimension="2" srsname="urn:ogc:def:crs:epsg::32633"> <gml:pos> </gml:pos> </gml:point> </app:wkb_geometry> <app:dato> t10:14:29z</app:dato> <app:oppdatert> t10:14:29z</app:oppdatert> <app:komm>1623</app:komm> <app:overbygg>ja</app:overbygg> <app:avstandservicebygg>25</app:avstandservicebygg> <app:bredde>0</app:bredde> <app:lengde>0</app:lengde> <app:hc_skilt>ja</app:hc_skilt> <app:merket>nei</app:merket> <app:avgift>nei</app:avgift> <app:bilde> </app:bilde> <app:opphav>statens kartverk</app:opphav> <app:målemetode>direkte innlagt på skjerm</app:målemetode> <app:nøyaktighet>1: 5000, nøyaktighet= 2 m</app:nøyaktighet> <app:digmålestokk>1:1000</app:digmålestokk> <app:hcp_id>1055</app:hcp_id> </app:hc-parkering> Versjon

93 </wfs:insert> </wfs:transaction> Eksempel på WFS respons etter innlegging av 3 nye objekter (GML 2.1.2) <TODO eksempelet bør byttes med et GML eksempel>: <wfs:featurecollection numberoffeatures="3" timestamp=" t08:48:47.444z" xsi:schemalocation=" ype&typename=test:plantesykdom <gml:featuremembers> <test:plantesykdom gml:id="plantesykdom.1"> <test:registreringstype>pærebrannbakterie</test:registreringstype> <test:forekomsttype>bulkemispel</test:forekomsttype> <test:beskrivelse>test</test:beskrivelse> <test:forekomststorrelse>1 plante</test:forekomststorrelse> <test:dato> z</test:dato> <test:bildeurl> <test:punkt> <gml:point srsdimension="2" srsname="urn:xogc:def:crs:epsg:32633"> <gml:pos> </gml:pos> </gml:point> </test:punkt> </test:plantesykdom > <test:plantesykdom gml:id="plantesykdom.2"> <test:registreringstype>pærebrannbakterie</test:registreringstype> <test:forekomsttype>pilemispel</test:forekomsttype> <test:beskrivelse>test</test:beskrivelse> <test:forekomststorrelse>10 planter</test:forekomststorrelse> <test:dato> z</test:dato> <test:bildeurl> <test:punkt> <gml:point srsdimension="2" srsname="urn:xogc:def:crs:epsg:32633"> <gml:pos> </gml:pos> </gml:point> </test:punkt> </test:plantesykdom > <test:plantesykdom gml:id="plantesykdom.3"> Versjon

94 <test:registreringstype>pærebrannbakterie</test:registreringstype> <test:forekomsttype>sprikemispel</test:forekomsttype> <test:beskrivelse>test</test:beskrivelse> <test:forekomststorrelse>10 planter</test:forekomststorrelse> <test:dato> z</test:dato> <test:bildeurl> <test:punkt> <gml:point srsdimension="2" srsname="urn:xogc:def:crs:epsg:32633"> <gml:pos> </gml:pos> </gml:point> </test:punkt> </test:plantesykdom > </gml:featuremembers> </wfs:featurecollection> Versjon

95 A.13 Bestille objekter som GML fra en SOAP WebService GML kan også benyttes som returformat for geografiske objekter fra SOAP WebServicer. uc Bestille objekter som GML fra en SOAP WebService GML 1 Velge område 1.1 Velge å bestille objektinfo som GML 2 Generere SOAP forespørsel Bruker Bestille objekter som GML fra SOAP WebServ ice 2.2 Sende SOAP forespørsel 3 Motta SOAP forespørsel SOAP Web Service SOAP klientapplikasjon 4.3 Vise objektinformasjonen 3.1 Generere SOAP respons 4.2 Formatere objektinformasjonen 3.3 Sende SOAP respons 4.1 Tolke SOAP respons 4 Motta SOAP respons Dette brukstilfellet beskriver bestilling av objektinformasjon som GML fra en SOAP WebService. Versjon

96 Use Case beskrivelse Navn Prioritet Beskrivelse Før-tilstand Bestille objektinformasjon som GML fra en SOAP WebService. Umiddelbar respons. En bruker bestiller objektinformasjon som GML fra en SOAP WebService. Bruker har tilgang på en SOAP klientapplikasjon eller en applikasjon som har en innebygget SOAP klient. Flyt 1 Bruker velger geografisk område for det/de objektene han ønsker informasjon om 2 Bruker velger å bestille objektinformasjon som GML 2.1 Applikasjonen genererer SOAP forespørsel 2.2 Applikasjonen sender SOAP forespørselen 3 SOAP tjenesten mottar forespørselen 3.1 SOAP tjenesten genererer en SOAP respons 3.2 SOAP tjenesten sender responsen 4 Applikasjonen mottar responsen Applikasjonen tolker SOAP responsen og finner GMLinformasjonen for objektet/objektene Applikasjonen genererer menneskelig lesbar informasjon og eventuelt grafisk presentasjon av objektinformasjonen 4.3 Applikasjonen viser objektinformasjonen til bruker Etter-tilstand Datakilde Beskrivelse Datatilbyder Geografisk område Tematisk område Detaljeringsgrad Leveranse Bruker har et valid GML-applikasjonsskjema SOAP WebService som tilbyr objektbeskrivelser i GML Eks: Kartverket Eks: Norske territorier og havområder, med biland. Eks: Alle typer offentlig geografisk informasjon Eks: Fra internasjonalt nivå ned til det mest detaljerte lokalnivå. Geografiske objekter på vektorform. Dokumentasjon Produktspesifikasjon, ISO 19136: GML 3.2.1, SOAP 1.2 Versjon

97 A.14 Eksempler på GML med delt og heleid geometri (T) Eksempler på GML med delt og heleid geometri finnes på /eksempel/. Versjon

98 A.15 Opprette eller endre et GML-applikasjonsskjema (T) Det gis her et eksempel på brukstilfelle for automatisk generering av GMLapplikasjonsskjema fra domenespesifikk datamodell i UML. uc Opprette et GML applikasjonsskjema GML applikasjonsskjema 1 Åpne datamodell 2 Velge å generere GML applikasjonsskjema 2.1 Generere GML applikasjonsskjema Opprette et GML applikasjonsskjema GML generator Bruker 3 Åpne generert GML applikasjonsskjema XML validator 3.1 Validere generert GML applikasjonsskjema 3.2 Vise v alideringsstatus Dette brukstilfellet beskriver opprettelse av et GML-applikasjonsskjema fra en domenespesifikk datamodell i UML. Use Case beskrivelse Navn Prioritet Beskrivelse Opprette et GML-applikasjonsskjema automatisk fra domenespesifikk datamodell i UML. Umiddelbar respons. En bruker oppretter et GML-applikasjonsskjema som grunnlag for en WFS-tjeneste eller en GML-fil. Versjon

99 Use Case beskrivelse Før-tilstand Bruker har tilgang på en domenespesifikk datamodell i UML. Bruker har også tilgang til en applikasjon (GML generator) som kan generere GML-applikasjonsskjema fra en datamodell i UML, og som er koblet mot internett. Bruker har også tilgang til en applikasjon (XML-validator) som kan validere XML-filer mot refererte skjemaer og eventuelt kan vise XML-filers innhold på en oversiktlig måte. Flyt 1 Bruker åpner datamodellen 2 Bruker velger å generere GML-applikasjonsskjema 2.1 Applikasjonen genererer GML-applikasjonsskjema 3 Bruker åpner det genererte GML-applikasjonsskjemaet i XMLvalidatoren 3.1 Bruker velger å validere GML-applikasjonsskjemaet 3.2 XML-validatoren viser valideringsstatus Etter-tilstand Datakilde Beskrivelse Datatilbyder Geografisk område Tematisk område Detaljeringsgrad Leveranse Bruker har et valid GML-applikasjonsskjema Domenespesifikk datamodell Eks: Kartverket Eks: Norske territorier og havområder, med biland. Eks: Alle typer offentlig geografisk informasjon Eks: Fra internasjonalt nivå ned til det mest detaljerte lokalnivå. Geografiske objekter på vektorform. Dokumentasjon Produktspesifikasjon, ISO 19136: GML Et eksempel på et GML-applikasjonsskjema (GML 3.2.1) som er generert fra en domenespesifikk datamodell, er her hentet fra et prosjekt om kartlegging av tilgjengelighet for syns- og bevegelseshemmede. Datamodellen beskriver de 4 objekttypene HC-parkering, Tilgjengelig veg, Parkeringsområde og InngangBygg som subtyper av objekttypen UniversellUtformingTettstedSupertype. GML-applikasjonsskjemaet inneholder i UniversellUtformingTettstedSupertype en referanse til en eksternt forvaltet kodeliste for kommunenummer, slik at disse ikke opptar plass i det enkelte GML-applikasjonsskjemaet, men kan gjenbrukes på tvers av domenespesifikke datamodeller. Eksempel på domenespesifikk datamodell som GML-applikasjonsskjemaeksempelet er generert fra (kodelistene er utelatt i skjermdumpen): Versjon

100 Eksempel på GML-applikasjonsskjema som er generert fra den domenespesifikke datamodellen over: <?xml version="1.0" encoding="utf-8"?><schema xmlns=" xmlns:app=" " xmlns:gml=" elementformdefault="qualified" targetnamespace=" ng/1.0" version="1.0.0"> <import namespace=" schemalocation=" <!--XML Schema document created by ShapeChange--> <simpletype name="ledelinjetype"> <union membertypes="app:ledelinjeenumerationtype app:ledelinjeothertype"/> </simpletype> <simpletype name="ledelinjeenumerationtype"> <restriction base="string"> <enumeration value="ikke valgt"/> <enumeration value="ikke vurdert"/> <enumeration value="ingen"/> <enumeration value="taktil"/> <enumeration value="visuell"/> </restriction> Versjon

101 </simpletype> <simpletype name="ledelinjeothertype"> <restriction base="string"> <pattern value="other: \w{2,}"/> </restriction> </simpletype> <simpletype name="døråpnertype"> <union membertypes="app:døråpnerenumerationtype"/> </simpletype> <simpletype name="døråpnerenumerationtype"> <restriction base="string"> <enumeration value="manuell"/> <enumeration value="halvautomatisk"/> <enumeration value="automatisk"/> </restriction> </simpletype> <simpletype name="gatetypetype"> <union membertypes="app:gatetypeenumerationtype"/> </simpletype> <simpletype name="gatetypeenumerationtype"> <restriction base="string"> <enumeration value="fortau"/> <enumeration value="gangfelt"/> <enumeration value="gangveg"/> <enumeration value="sykkelsti"/> <enumeration value="gang- og sykkelveg"/> <enumeration value="gågate"/> <enumeration value="sti"/> <enumeration value="gate"/> <enumeration value="torg"/> <enumeration value="gågate og torg"/> </restriction> </simpletype> <simpletype name="årstidsbruktype"> <union membertypes="app:årstidsbrukenumerationtype"/> </simpletype> <simpletype name="årstidsbrukenumerationtype"> <restriction base="string"> <enumeration value="helårsbruk"/> <enumeration value="sommerbruk"/> <enumeration value="vinterbruk"/> </restriction> </simpletype> <element name="parkeringsområde" substitutiongroup="app:universellutformingtettstedsupertype" type="app:parkeringsområdetype"/> <complextype name="parkeringsområdetype"> <complexcontent> <extension base="app:universellutformingtettstedsupertypetype"> <sequence> <element name="posisjon" type="gml:surfacepropertytype"/> <element minoccurs="0" name="overbygg" type="string"/> <element minoccurs="0" name="varmekabel" type="string"/> <element minoccurs="0" name="eierforhold" type="app:eierforholdtype"/> <element minoccurs="0" name="årstidsbruk" type="app:årstidsbruktype"/> <element minoccurs="0" name="kapasitetpersonbiler" type="integer"/> <element minoccurs="0" name="kapasitetuu" type="integer"/> <element minoccurs="0" name="dekke" type="app:vegdekketype"/> <element minoccurs="0" name="vegdekketilstand" type="app:vegdekketilstandtype"/> </sequence> </extension> </complexcontent> </complextype> <complextype name="parkeringsområdepropertytype"> <sequence minoccurs="0"> <element ref="app:parkeringsområde"/> </sequence> <attributegroup ref="gml:associationattributegroup"/> <attributegroup ref="gml:ownershipattributegroup"/> </complextype> Versjon

102 <element name="hc-parkering" substitutiongroup="app:universellutformingtettstedsupertype" type="app:hcparkeringtype"/> <complextype name="hc-parkeringtype"> <complexcontent> <extension base="app:universellutformingtettstedsupertypetype"> <sequence> <element name="posisjon" type="gml:pointpropertytype"/> <element minoccurs="0" name="overbygg" type="string"/> <element minoccurs="0" name="varmekabel" type="string"/> <element minoccurs="0" name="avstandservicebygg" type="integer"> <documentation>avstand til nærmeste servicebygg oppgis i m uten desimaltall</documentation> </element> <element minoccurs="0" name="bredde" type="integer"> <documentation>minste bredde oppgis i cm uten desimaltall</documentation> </element> <element minoccurs="0" name="lengde" type="integer"> <documentation>minste lengde oppgis i cm uten desimaltall</documentation> </element> <element minoccurs="0" name="hc_skilt" type="string"> <documentation>angir om HC-parkeringsplassen er skiltet eller ikke</documentation> </element> <element minoccurs="0" name="merket_hc" type="string"> <documentation>angir om HC-parkeringsplassen er merket</documentation> </element> <element minoccurs="0" name="avgift_hc" type="string"> <documentation>angir om HC-parkering er avgiftspliktig</documentation> </element> <element minoccurs="0" name="tilgjengeligautomat" type="string"/> <element minoccurs="0" name="automathøyde" type="integer"> <documentation>høyden måles til den øverste knappen eller myntinnkastet og oppgis i cm uten desimaltall</documentation> </element> </sequence> </extension> </complexcontent> </complextype> <complextype name="hc-parkeringpropertytype"> <sequence minoccurs="0"> <element ref="app:hc-parkering"/> </sequence> <attributegroup ref="gml:associationattributegroup"/> <attributegroup ref="gml:ownershipattributegroup"/> </complextype> <simpletype name="vegdekketype"> <union membertypes="app:vegdekkeenumerationtype"/> </simpletype> <simpletype name="vegdekkeenumerationtype"> <restriction base="string"> <enumeration value="asfalt"/> <enumeration value="betong"/> <enumeration value="brostein"/> <enumeration value="stein"/> <enumeration value="gress"/> Versjon

103 <enumeration value="skogsbunn"/> <enumeration value="grus"/> </restriction> </simpletype> <element name="tilgjengeligveg" substitutiongroup="app:universellutformingtettstedsupertype" type="app:tilgjengeligvegtype"/> <complextype name="tilgjengeligvegtype"> <complexcontent> <extension base="app:universellutformingtettstedsupertypetype"> <sequence> <element name="posisjon" type="gml:curvepropertytype"/> <element minoccurs="0" name="gatetype" type="app:gatetypetype"> <documentation>bygningsnummer på den nærmeste offentlige bygningen som ble registrert i sammenheng med denne HC-plassen</documentation> </element> <element minoccurs="0" name="bredde" type="integer"> <documentation>minste bredde oppgis i cm uten desimaler</documentation> </element> <element minoccurs="0" name="dekke" type="app:vegdekketype"/> <element minoccurs="0" name="møteplass" type="string"/> <element minoccurs="0" name="varmekabel" type="string"> <documentation>minste lengde oppgis i cm uten desimaltall</documentation> </element> <element minoccurs="0" name="stigningsforhold" type="string"> <documentation>stigning/fall i kursretningen oppgis som forholdstall, eks 1:15</documentation> </element> <element minoccurs="0" name="tverrfall" type="string"> <documentation>stigning/fall på tvers av kursretningen oppgis som forholdstall, eks 1:22</documentation> </element> <element minoccurs="0" name="nedsenk1" type="double"> <documentation>gjelder bare gangfelt. Terskelhøyden på nedsenkningen oppgis i cm med 1 desimal. Det må inntegnes i kartet hvilken nedsenkning som er Nedsenk1 og Nedsenk2</documentation> </element> <element minoccurs="0" name="nedsenk2" type="double"> <documentation>gjelder bare gangfelt. Terskelhøyden på nedsenkningen oppgis i cm med 1 desimal. Det må inntegnes i kartet hvilken nedsenkning som er Nedsenk1 og Nedsenk2</documentation> </element> <element minoccurs="0" name="lyssignal" type="string"> <documentation>gjelder bare gangfelt</documentation> </element> <element minoccurs="0" name="lydsignal" type="string"/> <element minoccurs="0" name="vegdekketilstand" type="app:vegdekketilstandtype"/> <element minoccurs="0" name="ledelinje" type="app:ledelinjetype"/> <element minoccurs="0" name="ledelinjekontrast" type="app:kontrasttype"/> </sequence> </extension> </complexcontent> </complextype> <complextype name="tilgjengeligvegpropertytype"> Versjon

104 <sequence minoccurs="0"> <element ref="app:tilgjengeligveg"/> </sequence> <attributegroup ref="gml:associationattributegroup"/> <attributegroup ref="gml:ownershipattributegroup"/> </complextype> <simpletype name="tilgjengelighetsvurderingtype"> <documentation>fast skala for vurdering av tilgjengelighet -- Definition - - fixed scale for appraisal of accessibility</documentation> <union membertypes="app:tilgjengelighetsvurderingenumerationtype"/> </simpletype> <simpletype name="tilgjengelighetsvurderingenumerationtype"> <documentation>fast skala for vurdering av tilgjengelighet -- Definition - - fixed scale for appraisal of accessibility</documentation> <restriction base="string"> <enumeration value="tilgjengelig"> <documentation>oppfyller minstekrav til tilgjengelighet for personer med funksjonsnedsettelse, der rullestol har vært en dimensjonerende faktor -- Definition -- fulfils minimum requirements to accessibility for persons with</documentation> </enumeration> <enumeration value="vanskelig tilgjengelig"> <documentation>oppfyller delvis minstekrav -- Definition -- partially fulfils minimum requirements</documentation> </enumeration> <enumeration value="ikke tilgjengelig"> <documentation>vurdert, funnet å ikke oppfylle minstekrav. Denne klassen er lagt til fordi en i visse sammenhenger, bl.a. i virkningsarbeid for bedre tilrettelegging kan ønske å fokusere på ulike typer bygg der forholdene er dårlige. -- Definition -- Assessed and found not to fulfil minimum requirements. This class has been added because one in certain connections, such as in efforts for</documentation> </enumeration> <enumeration value="ikke vurdert"/> </restriction> </simpletype> <element abstract="true" name="universellutformingtettstedsupertype" substitutiongroup="gml:abstractfeature" type="app:universellutformingtettstedsupertypetype"> <documentation>abstrakt objekt som bærer en rekke egenskaper som er fagområdeuavhengige og kan benyttes for alle objekttyper Merknad: Spesielt i produktspesifikasjonsarbeid vil en velge egenskaper og av grensningslinjer fra denne klassen. -- Definition -- Versjon

105 abstract object which carries a number of attributes which are independent of specific disciplines and may be used for all object types</documentation> </element> <complextype abstract="true" name="universellutformingtettstedsupertypetype"> <complexcontent> <extension base="gml:abstractfeaturetype"> <sequence> <element minoccurs="0" name="førstedatafangstdato" type="datetime"> <documentation>dato når data ble registrert/observert/målt første gang, som utgangspunkt for første digitalisering Merknad: førstedatafangstdato brukes hvis det er av interesse å forvalte informasjon om når en ble klar over objektet. Dette kan for eksempel gjelde datoen for første flybilde som var utgangspunkt for registrering i en database. -- Definition -- date when data were registered/observed/measured for the first time, as a starting point for the first digitisation Note: firstdatacapturedate is used if it is of interest to manage information on when one became aware of the object. This may for example apply to??<truncated text></documentation> </element> <element minoccurs="0" name="oppdateringsdato" type="datetime"> <documentation>dato for siste endring på objektetdataene Merknad: Oppdateringsdato kan være forskjellig fra Datafangsdato ved at data som er registrert kan bufres en kortere eller lengre periode før disse legges inn i datasystemet (databasen). -- Definition -- date of latest modification of object data Note: Date of updating may differ from date of data capture in that data which is registered may be buffered for a shorter or longer period of time, before being entered into the computer system (the database).</documentation> </element> <element minoccurs="0" name="opphav" type="string"> <documentation>referanse til opphavsmaterialet, kildematerialet, organisasjons/publiseringskilde Merknad: Kan også beskrive navn på person og årsak til oppdatering -- Definition -- reference to the original material, the source material, organization/publication source Note: May also describe the name of a person and reason for updating:</documentation> </element> <element minoccurs="0" name="kommune" type="gml:codetype"> <documentation>nummerering av kommuner i henhold til SSB sin offisielle liste Merknad: Det presiseres at kommune alltid skal ha 4 siffer, dvs. eventuelt med ledende null. Kommune benyttes for kopling mot en rekke andre registre som også benytter 4 siffer. -- Definition -- numbering of municipalities in accordance with Statistics Norway's official list Note: It must be emphasised that the municipality number always consists of 4 digits, i.e. sometimes with leading zero. Municipality is used for establishing relations to a number of other registers which also use 4 digits.</documentation> <appinfo> Versjon

106 <defaultcodespace xmlns=" sjon/universellutforming/1.0/kommune.xml</defaultcodespace> </appinfo> </element> <element minoccurs="0" name="målemetode" type="app:målemetodetype"/> <element minoccurs="0" name="bilde" type="string"/> <element minoccurs="0" name="kommentar" type="string"/> <element minoccurs="0" name="tilgjengelighetsvurderingbevegelse" type="app:tilgjengelighetsvurderingtype"/> <element minoccurs="0" name="tilgjengelighetsvurderingsynshemmede" type="app:tilgjengelighetsvurderingtype"/> <element maxoccurs="unbounded" minoccurs="0" name="kobling" type="app:universellutformingtettstedsupertypepropertytype"> <documentation>angivelse av objekt dette objektet er knyttet til</documentation> </element> </sequence> </extension> </complexcontent> </complextype> <complextype name="universellutformingtettstedsupertypepropertytype"> <sequence minoccurs="0"> <element ref="app:universellutformingtettstedsupertype"/> </sequence> <attributegroup ref="gml:associationattributegroup"/> <attributegroup ref="gml:ownershipattributegroup"/> </complextype> <simpletype name="målemetodetype"> <documentation>metode som ligger til grunn for registrering av posisjon -- Definition - - method on which registration of position is based</documentation> <union membertypes="app:målemetodeenumerationtype"/> </simpletype> <simpletype name="målemetodeenumerationtype"> <documentation>metode som ligger til grunn for registrering av posisjon -- Definition - - method on which registration of position is based</documentation> <restriction base="string"> <enumeration value="frihåndstegning"/> <enumeration value="digitalisert fra krokering"/> <enumeration value="direkte innlagt på skjerm"/> <enumeration value="gps kodemåling, enkeltmålinger"> <documentation>tidligere GPS, Absolutt, pseudorange -- Definition -- Previous GPS, absolute, pseudorange</documentation> </enumeration> </restriction> </simpletype> <simpletype name="håndlistplasseringtype"> <union membertypes="app:håndlistplasseringenumerationtype"/> </simpletype> <simpletype name="håndlistplasseringenumerationtype"> <restriction base="string"> <enumeration value="høyre (sett mot inngang)"/> <enumeration value="venstre (sett mot inngang)"/> <enumeration value="begge sider"/> <enumeration value="mangler"/> Versjon

107 </restriction> </simpletype> <simpletype name="vegdekketilstandtype"> <union membertypes="app:vegdekketilstandenumerationtype"/> </simpletype> <simpletype name="vegdekketilstandenumerationtype"> <restriction base="string"> <enumeration value="jevnt"/> <enumeration value="ujevnt"/> </restriction> </simpletype> <simpletype name="dørtypetype"> <union membertypes="app:dørtypeenumerationtype"/> </simpletype> <simpletype name="dørtypeenumerationtype"> <restriction base="string"> <enumeration value="slag inn"/> <enumeration value="slag ut"/> <enumeration value="skyvedør"/> <enumeration value="karusell"/> </restriction> </simpletype> <simpletype name="kontrasttype"> <union membertypes="app:kontrastenumerationtype"/> </simpletype> <simpletype name="kontrastenumerationtype"> <restriction base="string"> <enumeration value="ikke valgt"/> <enumeration value="god"/> <enumeration value="mindre god"/> <enumeration value="dårlig"/> </restriction> </simpletype> <simpletype name="eierforholdtype"> <documentation>eierforhold knyttet til et objekt -- Definition - - ownership in connection with an object</documentation> <union membertypes="app:eierforholdenumerationtype"/> </simpletype> <simpletype name="eierforholdenumerationtype"> <documentation>eierforhold knyttet til et objekt -- Definition - - ownership in connection with an object</documentation> <restriction base="string"> <enumeration value="offentlig"/> <enumeration value="privat"/> <enumeration value="annet"/> </restriction> </simpletype> <simpletype name="bygningsfunksjontype"> <union membertypes="app:bygningsfunksjonenumerationtype"/> </simpletype> <simpletype name="bygningsfunksjonenumerationtype"> <restriction base="string"> <enumeration value="skole"/> <enumeration value="stasjon"/> <enumeration value="sykehus"/> <enumeration value="helsestasjon"/> <enumeration value="rådhus"/> <enumeration value="omsorgssenter"/> <enumeration value="politi"/> <enumeration value="idrettshall"/> <enumeration value="bibliotek"/> </restriction> Versjon

108 </simpletype> <element name="inngangbygg" substitutiongroup="app:universellutformingtettstedsupertype" type="app:inngangbyggtype"/> <complextype name="inngangbyggtype"> <complexcontent> <extension base="app:universellutformingtettstedsupertypetype"> <sequence> <element name="posisjon" type="gml:pointpropertytype"/> <element minoccurs="0" name="atkomstvei_stigning" type="double"> <documentation>stigning/fall i kursretningen oppgis i grad med ett desimal. Her måles den bratteste stigningen på atkomstveien fra parkeringsplass til inngang.</documentation> </element> <element minoccurs="0" name="dørtype" type="app:dørtypetype"/> <element minoccurs="0" name="døråpner" type="app:døråpnertype"/> <element minoccurs="0" name="manøverknapp_høyde" type="integer"> <documentation>høyden oppgis i cm uten desimaler.</documentation> </element> <element minoccurs="0" name="ringeklokke" type="string"> <documentation>kryss av om det finnes en ringeklokke.</documentation> </element> <element minoccurs="0" name="ringeklokke_høyde" type="integer"> <documentation>høyden oppgis i cm uten desimaler.</documentation> </element> <element minoccurs="0" name="inngang_bredde" type="integer"> <documentation>minste bredde oppgis i cm uten desimaler.</documentation> </element> <element minoccurs="0" name="terskelhøyde" type="double"> <documentation>terskelhøyden oppgis i cm med 1 desimal.</documentation> </element> <element minoccurs="0" name="rampe" type="string"> <documentation>kryss av om det finnes en rampe.</documentation> </element> <element minoccurs="0" name="rampe_bredde" type="integer"> <documentation>minste bredde oppgis i cm uten desimaler.</documentation> </element> <element minoccurs="0" name="rampe_tilgjengelighet" type="app:tilgjengelighetsvurderingtype"/> <element minoccurs="0" name="håndlist" type="app:håndlistplasseringtype"/> <element minoccurs="0" name="håndlisthøyde_1" type="integer"> <documentation>høyden på den øverste håndlisten oppgis i cm uten desimaler.</documentation> </element> <element minoccurs="0" name="håndlisthøyde_2" type="integer"> <documentation>høyden på den nederste håndlisten oppgis i cm uten desimaler.</documentation> </element> <element minoccurs="0" name="avstandhc" type="integer"> <documentation>avstand til nærmeste HC-parkeringsplass oppgis i meter uten desimaler.</documentation> Versjon

109 </element> <element minoccurs="0" name="avstandvanligparkering" type="integer"> <documentation>avstand til nærmeste parkeringsplass oppgis i meter uten desimaler. Oppgis kun hvis det ikke finnes en HC-parkeringsplass i nærheten ev den registrerte inngangen.</documentation> </element> <element minoccurs="0" name="bygg_funksjon" type="app:bygningsfunksjontype"> <documentation>bygningens hovedfunksjon</documentation> </element> <element minoccurs="0" name="kontrast" type="app:kontrasttype"/> </sequence> </extension> </complexcontent> </complextype> <complextype name="inngangbyggpropertytype"> <sequence minoccurs="0"> <element ref="app:inngangbygg"/> </sequence> <attributegroup ref="gml:associationattributegroup"/> <attributegroup ref="gml:ownershipattributegroup"/> </complextype> </schema> Versjon

110 Vedlegg B Eksempel på Schematronfil med topologiske regler (T) <?xml version="1.0" encoding="utf-8"?> <sch:schema xmlns:sch=" <sch:ns prefix="gml" uri=" <!-- Linda van den Brink, Geonovum, The schematron file implements the validation of the restricted subset of GML 3.2 defined in the GML simple features profile compliance level SF2. The scope of the validation consists of GML document instances. Validation of the restricted subset of XML Schema, defined in the same profile document, is not implemented by this schematron file.--> <sch:pattern> <sch:rule context="/*/*/*"> <!-- Rule to exclude metadataproperty --> <sch:assert test="not(gml:metadataproperty)">this profile prohibits use of gml:metadataproperty elements for referencing metadata in instance documents.</sch:assert> </sch:rule> <sch:rule context="/*//*"> <!-- Rule to exclude spatial topology types --> <sch:assert test="not(self::gml:node self::gml:edge self::gml:face self::gml:toposolid self::gml:topopoint self::gml:topocurve self::gml:toposurface self::gml:topovolume self::gml:topocomplex)">spatial properties are limited to the set of geometric types consisting of point, curve with linear and/or circular arc interpolation, planar surface, or aggregates thereof. Spatial topology is excluded.</sch:assert> <!-- Rule for content of curves --> <sch:assert test="count(self::gml:curve/gml:segments/*[self::gml:linestringsegment self::gml:arc s elf::gml:circle self::gml:circlebycenterpoint]) = count(self::gml:curve/gml:segments/*)">curves (standalone or within surfaces) must have linear and/or circular arc interpolation (LineString, Curve with Arc, Circle or CircleByCenterpoint segments)</sch:assert> <!-- Rule for constraints on planar surfaces --> <sch:assert test="not(self::gml:orientablesurface self::gml:compositesurface self::gml:polyhedrals urface self::gml:tin self::gml:triangulatedsurface)">planar surface types are restricted to Polygon or Surface elements.</sch:assert> <!-- Rule for constraints on GeometryPropertyType --> <sch:assert test="not(self::gml:solid self::gml:multisolid self::gml:compositesolid self::gml:compositecurve self::gml:grid)">supported geometry types are restricted to point, curve with linear and/or circular arc interpolation, planar surface, or aggregates thereof.</sch:assert> <!-- Rule for geometry coordinates of points and circles by centerpoint -- > <sch:assert test="count(self::gml:point/gml:pos) = count(self::gml:point/*)">geometry coordinates shall only be specified using the gml:pos element for gml:point.</sch:assert> <sch:assert test="count(self::gml:circlebycenterpoint/gml:pos self::gml:circlebycenterpoint/gml:ra dius) = count(self::gml:circlebycenterpoint/*)">geometry coordinates shall only be specified using the gml:pos element for gml:circlebycenterpoint.</sch:assert> <!-- Rules for geometry coordinates in geometries other than points --> <sch:assert test="count(self::gml:linestringsegment/gml:poslist) = count(self::gml:linestringsegment/*)">geometry coordinates shall only be specified using the gml:poslist element for gml:linestringsegment.</sch:assert> Versjon

111 <sch:assert test="count(self::gml:linearring/gml:poslist) = count(self::gml:linearring/*)">geometry coordinates shall only be specified using the gml:poslist element for gml:linearring.</sch:assert> <sch:assert test="count(self::gml:arc/gml:poslist) = count(self::gml:arc/*)">geometry coordinates shall only be specified using the gml:poslist element for gml:arc.</sch:assert> <sch:assert test="count(self::gml:circle/gml:poslist) = count(self::gml:circle/*)">geometry coordinates shall only be specified using the gml:poslist element for gml:circle.</sch:assert> <!-- Rules for aggregate geometry types --> <sch:assert test="not(self::gml:multipoint/gml:pointmembers)">this profile restricts instance documents to using the property container gml:pointmember for the MultiPoint geometry type.</sch:assert> <sch:assert test="not(self::gml:multicurve/gml:curvemembers)">this profile restricts instance documents to using the property container gml:curvemember for the MultiCurve geometry type.</sch:assert> <sch:assert test="not(self::gml:multisurface/gml:surfacemembers)">this profile restricts instance documents to using the property container gml:surfacemember for the MultiSurface geometry type.</sch:assert> <sch:assert test="not(self::gml:multigeometry/gml:geometrymembers)">this profile restricts instance documents to using the property container gml:geometrymember for the MultiGeometry geometry type.</sch:assert> <!-- Rule for content of surfaces --> <sch:assert test="count(self::gml:surface/gml:patches/gml:polygonpatch) = count(self::gml:surface/gml:patches/*)">the content of gml:surface elements is restricted to gml:polygonpatch patches.</sch:assert> <!-- Rule fo srsdimension --> <sch:assert test="not(self::*/@srsdimension > 3)">coordinate reference systems may have 1, 2 or 3 dimensions</sch:assert> </sch:rule> </sch:pattern> </sch:schema> Versjon

112 Vedlegg C Eksempel på interne Schematronregler i et GMLapplikasjonsskjema (T) <?xml version="1.0" encoding="utf-16"?> <schema targetnamespace=" " elementformdefault="qualified" version="4.9.0" xmlns=" ma" xmlns:app=" xmlns:gm l=" xmlns:sch=" <import namespace=" schemalocation=" opengis.net/gml/3.2.1/gml.xsd" /> <!--XML Schema document created by ShapeChange - <appinfo> <sch:title>schematron validering</sch:title> <sch:ns prefix="app" uri=" /> </appinfo> <element name="administrativenhet" type="app:administrativenhettype" abstract="true" substitutiongroup="app:fellesegenskaper"> <documentation>område hvor det utøves offentlig forvaltning på lokalt, regionalt eller nasjonalt nivå</documentation> </element> <complextype name="administrativenhettype" abstract="true"> <complexcontent> <extension base="app:fellesegenskapertype"> <sequence> <element name="område" type="gml:surfacepropertytype" /> </sequence> </extension> </complexcontent> </complextype> <complextype name="administrativenhetpropertytype"> <sequence minoccurs="0"> <element ref="app:administrativenhet" /> </sequence> <attributegroup ref="gml:associationattributegroup" /> <attributegroup ref="gml:ownershipattributegroup" /> </complextype> <element name="administrativenhetnavn" type="app:administrativenhetnavntype" subst itutiongroup="gml:abstractobject"> <documentation>offisielle navn på administrativ enhet eller administrativt nivå</documentation> </element> <complextype name="administrativenhetnavntype"> <sequence> <element name="navn" type="string"> <documentation>offisielt navn på administrativ enhet</documentation> </element> </sequence> </complextype> <complextype name="administrativenhetnavnpropertytype"> <sequence> <element ref="app:administrativenhetnavn" /> </sequence> </complextype> <element name="fellesegenskaper" type="app:fellesegenskapertype" abstract="true" s ubstitutiongroup="gml:abstractfeature"> <documentation>abstrakt objekt som bærer en rekke egenskaper som er fagområde-uavhengige og kan benyttes for alle objekttypermerknad:spesielt i produktspesifikasjonsarbeid vil en velge egenskaper og av grensningslinjer fra denne klassen.</documentation> Versjon

113 </element> <complextype name="fellesegenskapertype" abstract="true"> <complexcontent> <extension base="gml:abstractfeaturetype"> <sequence> <element name="oppdateringsdato" type="datetime"> <documentation>dato for siste endring på objektetdataene Merknad: Oppdateringsdato kan være forskjellig fra Datafangsdato ved at data som er registrert kan bufres en kortere eller lengre periode før disse legges inn i datasystemet (databasen).-definition-date and time at which this version of the spatial object was inserted or changed in the spatial data set.</documentation> </element> </sequence> </extension> </complexcontent> </complextype> <complextype name="fellesegenskaperpropertytype"> <sequence minoccurs="0"> <element ref="app:fellesegenskaper" /> </sequence> <attributegroup ref="gml:associationattributegroup" /> <attributegroup ref="gml:ownershipattributegroup" /> </complextype> <element name="fylke" type="app:fylketype" substitutiongroup="app:administrativenh et"> <documentation>administrativ inndeling av nasjonen, avgrenset av fylkesgrenser og eventuelt riksgrense og territorialgrensen-- Definition -- administrative districting of nation, delimited by county boundaries and possibly national and territorial boundaries</documentation> </element> <complextype name="fylketype"> <complexcontent> <extension base="app:administrativenhettype"> <sequence> <element name="fylkesnavn" type="app:administrativenhetnavnpropert ytype"> <documentation>offisielle navn på fylket</documentation> </element> <element name="fylkesnummer" type="gml:codetype"> <appinfo> <sch:pattern id="fylkesnummertest"> <sch:rule context="app:fylke"> <sch:report test="app:fylkesnummer='06'"> Det er kun 06 Buskerud som er gyldig fylke </sch:report> </sch:rule> </sch:pattern> </appinfo> </element> </sequence> </extension> </complexcontent> </complextype> <complextype name="fylkepropertytype"> <sequence minoccurs="0"> <element ref="app:fylke" /> </sequence> <attributegroup ref="gml:associationattributegroup" /> <attributegroup ref="gml:ownershipattributegroup" /> </complextype> </schema> Versjon

114 Vedlegg D Lage en GML-eksempelfil (T) <TODO - Skille ut dette i eget dokument? Hører dette hjemme i veilederen?> Å lage en GML-eksempelfil er oftest et ganske manuelt arbeid. Det finnes få (om noen) verktøy som kan produsere komplette eksempelvise GML-filer direkte fra et GML-applikasjonsskjema. Årsaken er at det ikke er trivielt å maskinelt konstruere eksempelverdier i GML-filen som matcher kravene i et GML-applikasjonsskjema. For eksempel må en kommune ha et riktig kommunenummer og en geografisk plassering i tråd med virkeligheten. Det kreves dermed en veldig kraftig datamodell i bakkant av et verktøy som skal konstruere realistiske eksempelverdier. Dessuten er det mange valgmuligheter innenfor GML når det gjelder gyldige kombinasjoner av geometriske datatyper. Det er ikke mulig for et verktøy å vite hvilke av disse kombinasjonene du som bruker ønsker å vise i GML-filen. Dermed vil verktøyet i beste fall foreslå alle mulige kombinasjoner, og du ender opp med et eksempel som viser et totalt kaos av nøstede geometriske GML-elementer. Det er imidlertid mulig å få maskinelt laget et brukbart utgangspunkt for et GMLeksempel. Med litt videre manuell tilpasning kan det til slutt bli bra. Eksempel (fiktivt): Vi tar utgangspunkt i følgende datamodell fra en produktspesifikasjon: class Fylker område :Flate «featuretype» Fellesegenskaper + oppdateringsdato :DateTime «featuretype» AdministrativEnhet constraints {bare tillatt med landkode for Norge} «datatype» Administrativ EnhetNav n + navn :CharacterString «codelist» Fylkesnummer «featuretype» Fylke + fylkesnavn :AdministrativEnhetNavn + fylkesnummer :Fylkesnummer Versjon

115 Verktøyet XMLSpy kan utfra GML-applikasjonsskjemaet til denne datamodellen lage en GML-eksempelfil. <?xml version="1.0" encoding="utf-8"?> <!--Sample XML file generated by XMLSpy v2013 sp1 (x64) ( <app:fylke gml:id="id_1" xsi:schemalocation=" Fylke.xsd" xmlns:app=" xmlns:gml=" xmlns:xsi=" <app:oppdateringsdato> t09:30:47z</app:oppdateringsdato> <app:område/> <app:fylkesnavn> <app:administrativenhetnavn> <app:navn>string</app:navn> </app:administrativenhetnavn> </app:fylkesnavn> <app:fylkesnummer>string</app:fylkesnummer> </app:fylke> Som vi ser er eksempelfilen veldig tynn og mangler innhold i viktige elementer som for eksempel geometri (elementet område ). Det er altså behov for videre manuell bearbeiding før eksempelfilen er valid i henhold til datamodellen. For det første må vi manuelt fylle inn relevante verdier i henhold til lovlige datatyper i GML-applikasjonsskjemaet. De primitive datatypene klarer verktøyet selv å lage brukbare eksempelverdier for, men vi bør justere verdiene slik at de stemmer med det vi ønsker å illustrere med eksempelfilen vår. For eksempel må String i feltet app:navn og app:fylkesnummer, byttes med reelt fylkesnavn og nummer. De komplekse datatypene derimot, har ikke verktøyet klart å lage eksempelverdier for, så her må vi selv lage gyldige verdier og fylle inn. Her er den største utfordringen å fylle inn for app:område, som er av datatypen Flate. Det betyr at vi må lage en GML-sekvens av gyldige GML-elementer for datatypen Flate og lime inn her. Igjen kan for eksempel XMLSpy kan lage et utgangspunkt for oss med basis i datatypen Flate, som er spesifisert i GML-applikasjonsskjemaet til å være av GML-datatypen Surface. <?xml version="1.0" encoding="utf-16"?> <!--Sample XML file generated by XMLSpy v2013 sp1 (x64) ( <gml:surfaceproperty xsi:schemalocation=" kasjon/fylke/4.9 Fylke.xsd" xmlns:gml=" xmlns:xsi=" 1/XMLSchema-instance"> <gml:polyhedralsurface gml:id="id_1"> <gml:metadataproperty> <gml:genericmetadata>text</gml:genericmetadata> </gml:metadataproperty> <gml:description>string</gml:description> <gml:descriptionreference /> <gml:identifier codespace=" <gml:name>string</gml:name> <gml:patches> <gml:triangle> <gml:exterior> <gml:ring> <gml:curvemember> <gml:curve gml:id="id_2"> <gml:metadataproperty> <gml:genericmetadata>text</gml:genericmetadata> </gml:metadataproperty> <gml:description>string</gml:description> Versjon

116 <gml:descriptionreference /> <gml:identifier codespace=" ng</gml:identifier> <gml:name>string</gml:name> <gml:segments> <gml:cubicspline> <gml:pos> e0</gml:pos> <gml:pos> e0</gml:pos> <gml:vectoratstart> e0</gml:vec toratstart> <gml:vectoratend> e0</gml:vecto ratend> </gml:cubicspline> </gml:segments> </gml:curve> </gml:curvemember> </gml:ring> </gml:exterior> </gml:triangle> </gml:patches> </gml:polyhedralsurface> </gml:surfaceproperty> For geografiske objekttyper som Surface genererer verktøyet mye søl og vi må vaske eksempelet grundig manuelt. Elementer må ryddes i og korrekte koordinater i ønsket koordinatsystem for objektet må fylles inn. Slik blir det seende ut etter en vask: <gml:surface srsname="urn:ogc:def:crs:epsg::4258" gml:id="no.sk.nmg.s222222"> <gml:patches> <gml:polygonpatch interpolation="planar"> <gml:exterior> <gml:ring> <gml:curvemember> <gml:curve srsname="urn:ogc:def:crs:epsg::4258" gml:id="no.sk.nmg.s444444"> <gml:segments> <gml:linestringsegment interpolation="linear"> <gml:poslist> </gml:posList> </gml:linestringsegment> </gml:segments> </gml:curve> </gml:curvemember> </gml:ring> </gml:exterior> </gml:polygonpatch> </gml:patches> </gml:surface> Dermed kan vi lime sammen eksempeldelene og fylle inn de siste tekstverdiene: <?xml version="1.0" encoding="utf-8"?> <!--Sample XML file generated by XMLSpy v2013 sp1 (x64) ( <app:fylke gml:id="id_1" xsi:schemalocation=" sifikasjon/fylke/4.9 Fylke.xsd" xmlns:app=" x mlns:gml=" xmlns:xsi=" <app:oppdateringsdato> t09:30:47z</app:oppdateringsdato> <app:område> <gml:surface srsname="urn:ogc:def:crs:epsg::4258" gml:id="no.sk.nmg.s222222"> <gml:patches> <gml:polygonpatch interpolation="planar"> <gml:exterior> <gml:ring> <gml:curvemember> <gml:curve srsname="urn:ogc:def:crs:epsg::4258" gml:id ="NO.SK.NMG.S444444"> Versjon

117 <gml:segments> <gml:linestringsegment interpolation="linear"> <gml:poslist> </gml:posList> </gml:linestringsegment> </gml:segments> </gml:curve> </gml:curvemember> </gml:ring> </gml:exterior> </gml:polygonpatch> </gml:patches> </gml:surface> </app:område> <app:fylkesnavn> <app:administrativenhetnavn> <app:navn>buskerud</app:navn> </app:administrativenhetnavn> </app:fylkesnavn> <app:fylkesnummer>06</app:fylkesnummer> </app:fylke> Til slutt må vi kvalitetssikre GML-eksempelfilen vår mot GMLapplikasjonsskjemaet, og om nødvendig, foreta endringer slik at eksempelet validerer. Validering mot GML-applikasjonsskjemaet kan også gjøres i for eksempel XMLSpy. Versjon