Geometrie in uitwisselingsformaten

Samenvatting

Dit document is een handreiking over het uitwisselen van geometrie. Het geeft een overzicht van de verschillende bestandsformaten die je hiervoor kunt gebruiken, geeft handvaten voor het kiezen van het juiste formaat voor de juiste situatie, en geeft in afzonderlijke hoofdstukken gedetaileerde informatie over het uitwisselen van geometrie in HTML, GML, JSON, GeoPackage en RDF.

1. Inleiding

Hoewel Geography Markup Language (GML) nog steeds een van de belangrijkste gestandaardiseerde uitwisselformaten is, zijn er in de laatste jaren een aantal alternatieven in opkomst. GML is een hele volledige, maar ook vrij complexe standaard, en daardoor niet geschikt voor alle toepassingen. Deze handreiking geeft daarom een overzicht van de meest populaire alternatieven voor het uitwisselen en publiceren van vectordata - volgens open standaarden. Het gaat hierbij om 'lichtere bestandsformaten', in tegenstelling tot het allesomvattende (maar daardoor ook complexere) GML formaat.

Voor het uitwisselen van geodata kan men tegenwoordig dus kiezen uit verschillende bestandsformaten. Wat het beste formaat is voor een toepassing, is afhankelijk van meerdere aspecten. In het bij de data behorende informatiemodel kunnen deze aspecten al naar voren komen - bijvoorbeeld de geometrietypes die worden vastgelegd, het gebruikte modelleerparadigma, etc. Echter kun je vanuit één informatiemodel ook weer meerdere implementaties in uitwisselingsformaten afleiden - beslissingen in het model sluiten dit niet per sé uit.

Het is dan ook niet mogelijk om een opsomming te geven van álle relevante aspecten die een rol kunnen spelen bij het kiezen van een passend formaat. Wel zet deze handreiking de belangrijkste aspecten op een rijtje en brengt deze in verband met gangbare toepassingen. De toepassing bepaalt namelijk wat de eisen aan de geometrieën zijn (zijn complexe types nodig? Is een hoge nauwkeurigheid van belang?), en welke verplichtingen aan de orde zijn in de keuze voor standaarden. De antwoorden op deze vragen kunnen al een indicatie geven van de geschiktheid van de formaten.

Daarnaast is het van belang om inzicht te hebben in de behoeften van gebruikers: is ondersteuning in bepaalde tools/frameworks van belang? Moeten de bestanden leesbaar zijn voor mensen, en gemakkelijk te vinden? Hoe belangrijk is de semantiek van de data? Deze handreiking geeft daarom handvaten voor het kiezen van het juiste formaat voor de juiste situatie, en geeft in afzonderlijke hoofdstukken gedetailleerde informatie over het uitwisselen van geometrie in GML, HTML, JSON, GeoPackage en RDF.

1.1 Scope en doelgroep

Het doel van dit document is om handvaten te geven voor het gebruiken van lichtere bestandsformaten voor geodata, en beperkt zich tot de uitwisseling van data waarbij vector geometrieën toegepast worden. Het document richt zich op formaten waarmee 2D data wordt uitgewisseld, aangezien de aspecten die van belang zijn bij het ontsluiten van 3D data meer aandacht vereisen - een uitgebreid overzicht hiervan is dus buiten scope. Met digitale toegankelijkheid voor ogen, ligt de focus hier op formaten waarvan de onderliggende standaarden open zijn. De tekst is daarom gericht op aanbieders van geo-informatie die graag meer willen weten over de afwegingen die je moet maken bij het kiezen van een formaat. Het is niet mogelijk om alle afwegingen in kaart te brengen en bij elke combinatie van antwoorden een formaat aan te raden. Om deze reden neemt de handreiking een aantal gangbare use cases als uitgangspunt.

1.2 Leeswijzer

De handreiking is vormgegeven met het idee dat mensen hun weg erin moeten kunnen vinden ongeacht hun kennis. Hoofdstuk 2 geeft achtergrondinformatie over een aantal relevante standaarden. In Hoofdstuk 3 worden belangrijke aspecten bij het kiezen van een formaat toegelicht aan de hand van vijf gangbare, generieke toepassingen. Vervolgens worden alle formaten afzonderlijk in Hoofdstuk 4, Hoofdstuk 5, Hoofdstuk 6, Hoofdstuk 7, en Hoofdstuk 8 geïntroduceerd en beoordeeld op hun geschiktheid. De lezer kan met behulp van de 'keuze-aspect' tabellen bepalen welk formaat het meest geschikt is voor zijn of haar situatie, en zelf de belangrijkste aspecten daarvoor meewegen in de beslissing. In het document worden voorbeelden gebruikt om het uitdrukken van de geometrie, de semantiek van achterliggende modellen en het gebruik van de bestandsformaten te illustreren.

2. Standaarden

Naast de encoding standaarden zelf zijn er een aantal andere standaarden die ook aandacht verdienen, omdat ze relevant zijn voor het representeren van geometrieën in modellen of omdat ze invloed kunnen hebben op de geschiktheid en toepasbaarheid van de encodings.

2.1 NEN 3610

Het Nederlands Basismodel Geo-informatie [NEN3610] geeft regels voor het eenduidig beschrijven, uitwisselen en op het web publiceren van geo-informatie.

Relevant voor deze handreiking is dat NEN 3610 de regels beschrijft voor het modelleren van geo-informatie. Belangrijk in de definitie van een geografisch object is dat het locatie eigenschappen heeft. Eén van die locatie eigenschappen is de directe locatie die middels coördinaten is beschreven. Door middel van attributen wordt de directe locatie en geometrie door coördinaten gerepresenteerd. De waarden van die attributen zijn coördinaten of coördinaatreeksen die een geometrie representeren. We noemen dit geometrietypen.

2.2 ISO 19107:2019

De standaard Geographic information - Spatial Schema [iso-19107-2019] definieert het ruimtelijk schema: het informatiemodel van geometrieën. In ISO 19107 zijn de geometrietypen, hun eigenschappen en hun onderlinge relaties opgenomen. De geometrietypen uit deze standaard, zoals GM_Point, GM_Curve, en GM_Surface worden gebruikt om de geometrietypen in geo-informatiemodellen te specificeren.

2.3 ISO 19125:2004

ISO 19125-1 Simple feature access [iso-19125-1-2004] definieert een model voor 2 dimensionale geometrietypen. De daarin opgenomen geometrietypen zijn een selectie uit ISO 19107. De term simple feature staat voor features beperkt tot 2 dimensionale geometrie en lineaire interpolatie (alleen rechte lijnen tussen punten).

De simpele geometrietypen zijn:

Punt en multi-punt
Lijn en multi-lijn
Vlak en multi-vlak
Een generiek geometrietype Geometry dat één van bovenstaande kan zijn

2.3.1 Nederlands profiel op ISO 19107

Het ISO 19107 ruimtelijk schema in al zijn complexiteit is geschikt om zeer gevarieerde representaties van geometrieën te definiëren. Bij het kiezen van geometrietypen ter implementatie in een softwareomgeving is het van belang eisen ten aanzien van interoperabiliteit mee te nemen. Hiervoor is Simple Features een goed uitgangspunt: het is een selectie van de meest eenvoudige en gangbare geometrietypen, die breed worden ondersteund. In het kader van het Nederlands profiel op ISO 19107, dat jaren geleden is opgesteld, is er naast Simple Features gekeken naar GML als implementatieomgeving. Op basis daarvan is geëvalueerd welke subset van geometrietypen uit het ruimtelijke schema tot de Nederlandse basisset, het profiel, moeten behoren.

Voor GML 3.2 zijn er drie profielen met toenemende complexiteit, de zogenaamde Simple Features "levels" 0, 1, en 2. Softwareleveranciers kunnen ervoor kiezen hun ondersteuning van GML te beperken tot een van deze levels, of uiteraard om de hele standaard te ondersteunen.

Simple Features Profile level 2 is de standaard voor informatiemodellen in Nederland. Het profiel is een subset van het complete GML 3.2. Toch is het in sommige gevallen gewenst om te werken met een nog eenvoudiger informatiemodel, dat met name voor software die de complexere zaken in SF2 niet ondersteunt, te begrijpen is - hier is SF0 voor. Meer informatie over deze profielen is te vinden in de Handreiking Geometrie in model en GML [gimeg].

Het Nederlands profiel kent dezelfde geometrietypen als ISO 19125: (multi)Punt, (multi)lijn, (multi)vlak, (multi) geometry. Hierbij is voor Nederland afgesproken dat naast lineaire interpolatie, ook interpolatie door middel van cirkelbogen mag worden gebruikt.

3. Keuzehulp bestandsformaten

Stel, je bent een overheidsorganisatie, en je bezit geo-data die je wilt publiceren als open data, of die je wilt uitwisselen met andere partijen. Welk formaat moet je dan kiezen? Vroeger was het antwoord van Geonovum altijd: "GML". Maar tegenwoordig zijn er meerdere formaten waaruit je kunt kiezen.

Bij de keuze voor het juiste uitwisselformaat speelt de beoogde toepassing, of toepassingen, een belangrijke rol. Wat willen gebruikers ermee: willen ze de data kunnen visualiseren in een webapplicatie, of gaan ze de data bijvoordbeeld gebruiken voor GIS analyses? Wordt de data gepubliceerd op het web, of rechtstreeks uitgewisseld tussen systemen waarbij validatie van toepassing is?

Aspecten van de geometrische data zelf spelen ook een rol bij de keuze voor een formaat. Is 3D data nodig? Is nauwkeurigheid van belang? Worden complexe geometrietypes gebruikt? Daarnaast is het belangrijk om te kijken naar de voorkeuren, behoeftes en de tools die gebruikt worden door afnemers - ondersteunen deze de formaten ook? Er is niet één enkel uitwisselformaat voor geometrische data dat het antwoord op alles is. Dit betekent dat de beste oplossing kan variëren, en afhankelijk is van overwegingen die de data-eigenaar zal moeten maken.

De belangrijkste aspecten, die invloed kunnen hebben op de keuze voor een format, lichten we hieronder kort toe. Na deze toelichting vatten we de aspecten samen en brengen ze met elkaar in verband.

3.1 Aspecten die een rol spelen bij de keuze

3.1.1 Aanleveren versus uitleveren van data

Bij het kiezen van het juiste formaat, maakt het veel verschil of de data wordt uitgewisseld tussen softwaresystemen in een keten, bijvoorbeeld bij het aanleveren aan een landelijke voorziening voor data; of dat de data wordt aangeboden aan gebruikers. In een keten heb je altijd te maken met bekende gebruikers, en vaste afspraken die binnen de keten voor gegevensuitwisseling zijn gemaakt. Een partij die binnen een keten acteert heeft doorgaans een langdurig belang en zal dus meer bereid zijn tot het doen van een investering in tijd en/of geld om de data te kunnen uitwisselen. Het kan dan gerechtvaardigd zijn om een wat moeilijker te hanteren formaat te kiezen, als dat opweegt tegen voordelen die dat specifieke formaat heeft. Bij het aanbieden van data aan gebruikers, vaak als open data, is dit veel minder het geval. Datagebruikers hebben vaak beperkt tijd om met een bestand aan de slag te gaan.

3.1.2 Bekende versus onbekende gebruiker

Bij het aanleveren van data aan een landelijke voorziening heb je per definitie een bekende gebruiker: er zijn afspraken tussen verzender en ontvanger van de data. Bij het uitleveren van data is dit niet per definitie het geval. Er kan sprake zijn van bekende gebruikers: partijen die bijvoorbeeld een abonnement op de data hebben of waarvan bekend is dat ze de data afnemen. Maar het kan ook zijn dat de data voor iedereen beschikbaar is zonder verder contact met de data aanbieder. In dat geval kunnen er gebruikers zijn met allerlei verschillende kennisniveau's, applicaties en behoeftes. Denk hierbij bijvoorbeeld aan web developers (applicatiebouwers), data scientists en data journalisten. Om breed gebruik van data te bevorderen is het dan verstandig om de data zo laagdrempelig mogelijk aan te bieden, dus in algemeen gangbare dataformaten waarvoor brede ondersteuning in tooling bestaat.

3.1.3 GIS-gebruikers of andere gebruikers

Nog een aspect dat met gebruikers te maken heeft, is de vraag of het om GIS gebruikers gaat. De huidige GIS systemen kunnen niet alle lichte formaten, die we in deze handreiking beschrijven, aan. Als (een deel van) het publiek van de gepubliceerde data wel de behoefte heeft om data in een GIS in te lezen, om bijvoorbeeld ruimtelijke analyses te kunnen doen, moet hier rekening mee gehouden worden.

3.1.4 Archivering versus direct gebruik

Bij archivering is een belangrijk basisconcept dat vorm, inhoud en structuur van archiefbescheiden behouden moeten blijven of tenminste reproduceerbaar zijn. Voor data die gearchiveerd moeten worden zijn daarom afwegingen zoals langdurige ondersteuning, gedocumenteerde standaarden en open formaten van extra belang. Mogelijk moet er ook voldaan worden aan de Archiefwet.

3.1.5 Ondersteuning in algemene tooling

Als het gaat om de aanleverkant in een keten, is er meestal specifieke ondersteuning voor het gekozen uitwisselformaat in de keten geimplementeerd. Soms kan er echter toch behoefte zijn aan ondersteuning in tooling, die niet onderdeel van de keten is maar wel toegevoegde waarde heeft in het werkproces van de zender of de ontvanger van de data.

3.1.6 Validatie

Validatie, het controleren van de datastructuur en -inhoud tegen vooraf afgesproken regels, is vooral belangrijk bij het direct uitwisselen tussen systemen, bijvoorbeeld aan de aanleverkant van landelijke datavoorzieningen of bij het leveren van data van een uitvoerder aan een opdrachtgever. Men wil immers de kwaliteit borgen van de aangeleverde data, en zorgen dat alleen correcte data wordt ingelezen in het ontvangende systeem. Maar er zijn ook andere situaties denkbaar waarin validatie belangrijk is.

Validatie kan zich richten op verschillende aspecten:

Validatie van een vooraf afgesproken datastructuur (dat meestal is vastgelegd in een informatiemodel)
Validatie van business rules (regels over de inhoud en afhankelijkheden tussen onderdelen van de data)
Validatie van geometrieën

Al deze validatie-aspecten worden in wisselende mate ondersteund door de verschillende formaten. Als je een dataset wilt valideren kun je dit altijd uitprogrammeren, maar vaak biedt het voordelen om zonder programmeerwerk te kunnen valideren. Dit is bijvoorbeeld bij op XML gebaseerde formaten mogelijk omdat het uitdrukken van dataschema's een goed geïmplementeerd onderdeel van de standaard is.

3.1.7 Uitleveren van schema's

In sommige situaties is het gewenst om de afspraken over datastructuur en -inhoud (ook wel: schema's) vast te leggen in machine-leesbare vorm en dit machine-leesbare schema te delen met de ontvangers van data. Dit is niet bij alle lichte formaten mogelijk.

3.1.8 Nauwkeurige data

Als er sprake is van nauwkeurige geometrische data, kan dit gevolgen hebben voor de formaatkeuze. Dit hangt samen met coördinaatreferentiesystemen. Sommige formaten ondersteunen alleen het WGS-84 coördinaatstelsel, waarmee het niet mogelijk is om coordinaten in Nederland net zo nauwkeurig uit te drukken als bijvoorbeeld in het Rijksdriehoekstelsel.

Noot

3.1.9 Simpele geometrie

GIS standaarden en (in mindere mate) -tooling ondersteunen niet alleen rechttoe rechtaan 0, 1 of 2 dimensionale geometrie in de vorm van punten, lijnen en vlakken maar soms ook exotischere vormen zoals kromme lijnen (splines, cirkels, bogen, ellipses), driehoeken, 3D volumes, etc. In Nederland hanteren we het Simple Feature profiel plus een eenvoudige vorm van bogen, (zie [gimeg] hoofdstuk 3), maar ondersteuning van andere kromme lijnen en 3D volumes is voor sommige use cases wel nodig. In lichte formaten is over het algemeen beperkte ondersteuning: soms alleen punten, soms ook lijnen en vlakken, en in een enkel geval ook bogen en/of volumes.

3.1.10 Bogen en volumes

Als de toepassing het nodig maakt om bogen en/of 3D volumes in de data uit te wisselen, moet er extra gelet worden op ondersteuning hiervoor bij de keuze van het uitwisselformaat.

Noot

3.1.11 Datavolume

Bij geodata kan men te maken hebben met grote datavolumes. Het woord "groot" is hierbij lastig te kwantificeren, en wat een groot bestand gevonden wordt kan ook veranderen in de loop der jaren. Maar een bestand van bijvoorbeeld 500MB of 1GB kan momenteel toch wel 'groot' genoemd worden en in de keuze van het meest geschikte uitwisselformaat speelt dit een rol.

Het ene formaat is geschikter voor grote datavolumes dan het andere. Het tegenovergestelde geldt ook: sommige formaten hebben relatief veel overhead en zijn daarom minder geschikt voor het uitwisselen van een klein bestandje via een API.

3.1.12 Semantiek

Het vastleggen en uitwisselen van informatie over de betekenis (semantiek) van de data wordt in wisselende mate ondersteund door de verschillende formaten. Of het van belang is hangt af van de situatie; bij data uitwisseling tussen partijen die elkaar kennen speelt dit niet zo, omdat deze kennis bij de ontvanger op de een of andere manier al aanwezig is. Voor onbekende gebruikers is het vaak belangrijker om de betekenis te kunnen achterhalen. Afkortingen of jargon zijn voor hen lastig te doorgronden. Ook voor vindbaarheid in zoekmachines is semantiek belangrijk: zoekmachines nemen dit mee in hun indexering zodat zoektermen die gebruikers invoeren betekenisvolle resultaten opleveren.

3.1.13 Gestructureerde semantiek

Informatie over de betekenis, ofwel semantiek, kan op verschillende manieren worden vastgelegd. Dit kan een simpel PDF document of excel bestand zijn, of een website met uitleg; er zijn ook machineleesbare formaten zoals RDFS en SKOS. In de meeste formaten is er weinig of geen ondersteuning voor het gestructureerd vastleggen van semantiek.

3.1.14 Samenvatting: de aspecten in samenhang

De hierboven uitgelegde aspecten zijn samen te vatten in de volgende vragen, waarbij ook de afhankelijkheden tussen de vragen zijn meegenomen:

1. Gaat het om het aanleveren van data (in ‘keten of tussen systemen), of het uitleveren van data aan eindgebruikers?

In geval van uitleveren:
- Is de gebruiker bekend of onbekend?
- In geval van bekend:
- - Gaat het om GISers of niet-geo developers?
In geval van aanleveren:
- Wordt de data (door de andere partij) gearchiveerd of direct gebruikt?
- In geval van direct gebruikt:
- - Heeft de partij behoefte aan ondersteuning in algemenere tooling?

2. Is validatie erg belangrijk?

Zo ja:
- Is het belangrijk om schema’s te kunnen leveren aan partijen / gebruikers?
- Is het belangrijk om out-of-the-box te kunnen valideren tegen het schema?

3. Is de nauwkeurigheid van de data belangrijk?

4. Welke geometriesoorten worden uitgewisseld – alleen simple features of ook andere ISO 19107 types?

In geval andere ISO 19107 types:
- Zijn bogen of 3D geometrieën aanwezig?

5. Gaat het om grote of kleine datahoeveelheden?

6. Is semantiek belangrijk (gaat het om meer dan de uitwisseling van geometrieën)?

Zo ja:
- Moet de semantiek op gestructureerde wijze worden vastgelegd?

Welk formaat, of welke formaten, de beste keuze zijn, hangt af van de antwoorden op deze vragen. Ze geven inzicht in welke aspecten een belangrijke rol spelen voor de beoogde toepassing. Met deze informatie kan de lezer de tabellen in hoofdstuk 4-8 nagaan, en op basis daarvan een afweging maken over welke formaten het beste aansluiten op de behoeften die uit de antwoorden naar voren zijn gekomen.

Let wel op dat dit geen allesomvattende vragenlijst is. In een praktische situatie kunnen er zaken een rol spelen die niet in de vragenlijst zijn meegenomen. Maar met behulp van de vragenlijst krijgt de lezer in ieder geval een goede indicatie.

3.2 Keuzehulp voor generieke toepassingen

Hoewel elke toepassing tot andere antwoorden kan leiden (en dus andere keuzes), zijn er een aantal generieke toepassingen waarvoor een specifiek uitwisselformaat het meest geschikt is. Om de lezer te helpen bieden we een visuele keuzehulp aan die voor een aantal generieke toepassingen laat zien welk uitwisselformaat daar het beste bij past, aan de hand van de daarbij relevante aspecten.

De generieke toepassingen zijn:

Web pagina's waarop mensen informatie kunnen vinden over geo-objecten
Kaarten of andere visualisaties van geodata die gepubliceerd worden op het web
Data integratie - het combineren van geodata met andere data
Ruimtelijke analyses - het ontdekken van betekenisvolle patronen in geodata
Uitwisselen van geodata tussen systemen

§ 7. Geography Markup Language (GML)

4. HTML

4.1 Introductie

HTML is een specificatie van het W3C [html5] om gegevens gestructureerd aan te bieden, voor ontsluiting op het web. HTML is vooral bekend als de standaard voor webpagina's. Zoekmachines kunnen HTML goed indexeren.

Geodata in HTML kan op verschillende manieren gepubliceerd worden. Een HTML pagina kan de geometrie zelf bevatten en visualiseren. Dit wordt gedaan met de hulp van (gestandaardiseerde) webtechnologie als CSS, JavaScript, SVG / web canvas. Hiermee kan de onderliggende data op dynamische wijze geladen en bekeken worden op een web pagina. En steeds meer APIs leveren ook HTML representaties van geo-objecten op. Zo is in de core van OGC API Features [OAPIF] HTML een aanbevolen formaat voor representatie van geodata. Aangezien HTML zelf geen ondersteuning biedt voor geodata (het kent geen aparte elementen voor geometrieën), zal de data via libraries en tools van tevoren verwerkt moeten worden voor visualisatie doeleinden.

Het is echter wel mogelijk om de geometrie gestructureerd op te nemen in een HTML pagina, door middel van een zogenaamde annotatie. Met een annotatie beschrijf je de geodata op zo'n manier dat het zoekmachines toestaat de data op de pagina te indexeren en mogelijk te combineren met andere data. Om de betekenis van de data te kunnen interpreteren worden vocabulaires gebruikt. Annotaties in HTML zijn vaak volgens het begrippenkader van Schema.org opgesteld, een populair vocabulair waarmee zoekmachines goed overweg kunnen. Slechts enkele eenvoudige geometrietypen kunnen worden beschreven met Schema.org:

punt: schema:GeoCoordinates (met properties schema:latitude en schema:longitude)
lijnen: schema:GeoShape (met property schema:line)
vlak: schema:GeoCircle of schema:GeoShape (met property schema:box, schema:circle of schema:line)

Het is ook mogelijk om een hoogtegetal op te nemen - zowel voor de geometrieën als voor deze elevation geldt dat het in WGS84 moet worden geleverd. De geometrie wordt meestal beschouwd als een vorm van metadata van de HTML pagina. De annotaties die hiervoor nodig zijn kunnen op verschillende manieren verwerkt worden in de HTML. De annotaties kunnen direct verbonden worden met de content die getoont wordt op de pagina (middels microdata of RDFa), of de geodata kunnen apart opgenomen worden in een JSON of JSON-LD fragment.

In HTML kunnen eenvoudig relaties gelegd worden met andere bronnen zoals begrippenkaders of gerelateerde geo-objecten. Als deze geo-objecten op dezelfde manier ook relaties leggen naar andere bronnen, kan dit nieuwe inzichten opleveren.

4.2 Voorbeelden

Voorbeeld 2: Voorbeelden van geometrie voor HTML

De voorbeelden hieronder tonen aan hoe je met geodata om kan gaan in HTML. Het Schema.org vocabulair wordt aangeraden wanneer men data in HTML wil annoteren, omdat de data op deze manier indexeerbaar is door zoekmachines. Echter sluit dit het gebruik van andere vocabulaires niet uit. Wanneer de RDFa of JSON-LD serialisaties worden toegepast, is het ook mogelijk uit de geanoteerde HTML Linked Data te extraheren (zie hier een visualisatie van de data uit de onderstaande voorbeelden).

Je zou de volgende text kunnen bekijken wanneer je de HTML met RDFa annotaties in een browser probeert te renderen (hoe de text er precies uit komt te zien is afhankelijk van de styling regels die worden toegepast).

Dit voorbeeld toont geodata volgens het Schema.org vocabulair, zoals je het in een HTML zou kunnen verwerken (met annotaties in RDFa).

<div vocab="http://schema.org/" 
typeof="LandmarksOrHistoricalBuildings" 
about="http://www.ldproxy.net/bag/inspireadressen/inspireadressen.3329155">
    <span property="name">Anne Frank's House 
    <a property="url" href="http://www.ldproxy.net/bag/inspireadressen/inspireadressen.3329155">(INSPIRE object 3329155)
    </a></span><span property="description"> Museum house where Anne Frank & her family hid from the Nazis in a secret annex, during WWII.</span>
    <span>The postal address of this building is:</span>
    <div property="location" typeof="Place">
    <div property="address" typeof="PostalAddress">
          <span property="postalCode">1016GV</span>
          <span property="streetAddress">Prinsengracht 267</span>
          <span property="addressLocality">Amsterdam</span>
      </div>
      <div property="geo" typeof="GeoShape">
          <meta property="polygon" content="52.375108,4.884235 52.375153,4.884276 
                      52.375159,4.884257 52.375254,4.883981 
                      52.375109,4.883850 52.375075,4.883819 
                      52.374979,4.884104 52.374965,4.884143 
                      52.375035,4.884207 52.375016,4.884263 
                      52.374996,4.884320 52.374926,4.884255 
                      52.374901,4.884329 52.375034,4.884451 
                      52.375108,4.884235">
            <meta>
        </div>
    </div>
</div>

Wanneer je de data liever niet vermengd met de inhoud van de HTML, dan kun je het ook met de JSON-LD serialisatie opnemen, in een script tag. Het voordeel van deze benadering is dat het gebruik maakt van een format waar ontwikkelaars vaker ervaring mee hebben. Wel is het belangrijk om rekening te houden met best practices: Spatial Data on the Web Best Practice 2 raadt aan om HTML representaties van geodata begrijpbaar te maken voor gebruikers, en dus niet alleen voor zoekmachines.

<script type="application/ld+json">         
{
  "@context": [
  "https://schema.org/",
   {"gsp": "http://www.opengeospatial.org/standards/geosparql/",
  "geojson": "https://purl.org/geojson/vocab#",
  "coordinates": {
    "@container": "@list",
    "@id": "geojson:coordinates"
      }
     }
  ],
  "@type": "LandmarksOrHistoricalBuildings",
   "url": "http://www.ldproxy.net/bag/inspireadressen/inspireadressen.3329155",
  "name": "Anne Frank's House",
  "description": "Museum house where Anne Frank & her family hid from the Nazis in a secret annex, during WWII.",
  "location": {
    "@type": "Place",  
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "Prinsengracht 267",
      "addressLocality": "Amsterdam",
      "postalCode": "1016GV"
    },
    "geo": {
      "@type": "GeoShape",
      "polygon": "52.375108,4.884235 52.375153,4.884276 52.375159,4.884257 52.375254,4.883981 52.375109,4.883850 52.375075,4.883819 52.374979,4.884104 52.374965,4.884143 52.375035,4.884207 52.375016,4.884263 52.374996,4.884320 52.374926,4.884255 52.374901,4.884329 52.375034,4.884451 52.375108,4.884235"
    }
  }
}
</script>

4.3 Keuze-aspecten

De volgende tabel geeft aan hoe HTML scoort op de aspecten die een rol spelen bij de keuze voor een bestandsformaat.

Vraag	Antwoord	Toelichting
Is het format geospecifiek?	✕
Is het format gebaseerd op algemene ict standaarden?	✓	Ja, HTML is de standaard voor Web pagina's.
Wordt het format ondersteund in GIS software?	✕	Wanneer we het hebben over HTML voor de uitwisseling van data wordt een dataset (meestal) niet in één webpage gepubliceerd, maar krijgt elk object een eigen pagina. Dit betekent dat verwerking van meer dan één object in een ander systeem (bijvoorbeeld in een GIS of inlezen in een database), lastig is.
Ondersteunt het format het uitdrukken van schema's, en validatie tegen dat schema?	✕
Ondersteunt het format meerdere coordinaatsystemen?	✕	Nee, maar voor het gestructureerd opnemen van geometrie / CRSen kunnen annotaties gebruikt worden, deze worden gedefinieerd in een begrippenkader. Schema.org is een gangbare begrippenkader voor HTML annotaties, en ondersteunt alleen WGS-84. Het is niet de enige mogelijkheid, maar het voordeel van Schema.org annotaties is dat zoekmachines makkelijker met deze informatie overweg kunnen.
Ondersteunt het format 3D?	✕	Nee, maar voor het gestructureerd opnemen van geometrie / CRSen kunnen annotaties vanuit een begrippenkader gebruikt worden. Schema.org is een gangbare begrippenkader, alleen ondersteunt deze geen 3D.
Ondersteunt het format alle simple features geometrieen?	～	Nee, HTML ondersteunt geen geometrietypes vanzelf. Via een begrippenkader zou je een geometrie echter wel op gestructureerde wijze kunnen opnemen. Schema.org ondersteunt het gebruik van coördinaten (zie GeoCoordinates) en een beperkt aantal geometrietypen (zie GeoShape).
Ondersteunt het format andere ISO 19107 geometrie types?	✕
Is het format geschikt voor grote volumes?	✕
Is het format geschikt om semantiek aan te koppelen / in uit te drukken?	✓	Het is eenvoudig om gestructureerde data te combineren met tekst en en men kan linken aan begrippenkaders (zie RDFa Primer voor meer informatie)

5. GeoJSON

5.1 Introductie

JSON [RFC8259] is een codering voor gegevens in een op JavaScript gebaseerd formaat. Vaak wordt JSON als alternatief voor XML gebruikt om gestructureerde gegevens te coderen en uit te wisselen.

GeoJSON [RFC7946] gebruikt JSON om geografische gegevens te coderen. Het is bedoeld om simpele geografische objecten te representeren inclusief hun ruimtelijke en niet-ruimtelijke eigenschappen. GeoJSON ondersteunt de volgende geometrische objecten:

punten: Point en MuliPoint
lijnen: LineString en MultiLineString
vlakken: Polygon en MultiPolygon
multigeometrie: GeometryCollection waarin een mix van de bovenstaande geometrietypen kan voorkomen.

Een GeoJSON object representeert ofwel een losse geometrie, een Geometry; ofwel een enkel geo-object, een Feature; of een lijst van geo-objecten, een FeatureCollection met daarin meerdere features. Elk Feature bevat een geometry eigenschap waarin de geometrie is opgenomen; en een properties eigenschap waarin de niet-geometrische eigenschappen staan.

GeoJSON is ontstaan als informele community standaard, opgesteld in een internet werkgroep. Inmiddels is het een IETF standaard. Ondersteuning voor GeoJSON is er in sommige geografische databases en GIS softwarepakketten, en is breed aanwezig in web mapping libraries en APIs van bijvoorbeeld Google, Yahoo en Twitter.

GeoJSON is een prima formaat voor de meeste toepassingen - zeker in web toepassingen - bijvoorbeeld om iconen of polygonen bovenop een kaart op het web weer te geven. De browser toont dan een basiskaart, haalt de daar bovenop weer te geven geodata op, en combineert deze met de basiskaart met behulp van een JavaScript library.

Een voordeel van dit formaat is dat het te lezen is in een tekst editor, in tegenstelling tot GeoPackage bestanden die binair zijn. Dit maakt GeoJSON wat eenvoudiger in gebruik. JSON is heel geschikt voor web toepassingen, bijvoorbeeld voor publicatie van data in een API of voor visualisatie op het web. Omdat JSON gebaseerd is op JavaScript, is het direct te gebruiken in web toepassingen, zonder dat het eerst geparseerd of geconverteerd moet worden. Het heeft weinig overhead waardoor het goed toepasbaar is binnen een API. Er zijn bovendien veel tools beschikbaar om ermee te werken. Deze voordelen maken GeoJSON goed bruikbaar voor niet-geo experts, die JSON vaak al kennen.

GeoJSON schrijft WGS-84 voor; dit maakt het geschikt voor visualisatie op het web. Een nadeel van WGS-84 is de lagere nauwkeurigheid in vergelijking met RD; maar voor veel toepassingen is data met hoge nauwkeurigheid niet nodig. Op het Geoforum wordt er bijvoorbeeld zelden gevraagd om data met hoge nauwkeurigheid. De Spatial Data on the Web Best Practice raadt aan om geodata, zodra je het aanbiedt op het web, in ieder geval altijd in WGS-84 te publiceren, en daarnaast in andere CRS als daar expliciete behoefte aan is.

De OGC API Features kan in combinatie met zowel GeoJSON als GML worden gebruikt. Dit laatste is alleen nog interessant als er behoefte is aan nauwkeurigere geometrieën of aan bogen of volumes (die in GeoJSON niet worden ondersteund).

5.2 Voorbeelden

Voorbeeld 3: Voorbeelden van geometrie voor GeoJSON

GeoJSON (Polygon)
GeoJSON (3D)

GeoJSON features en collections kunnen eenvoudig gebruikt worden in web toepassingen. Met Leaflet of Mapbox kun je bijvoorbeeld al snel interactieve kaarten ter beschikking stellen. Ook zijn er een meerdere visualisatie en validatie tools beschikbaar (zoals GeoJSONLint en GeoJSON.io).

{
  "type": "Feature",
  "geometry": {
    "type": "MultiPolygon",
    "coordinates": [           
            [
                [
                    [4.884067, 52.375343, 5], [4.883980, 52.375252, 5],
                    [4.884259, 52.375159, 5], [4.884299, 52.375205, 5],
                    [4.884336, 52.375191, 5], [4.884375,52.3752393, 5],
                    [4.884067, 52.375343, 5]
                ]
           ],
           [
               [
                   [4.884196, 52.375238, 5], [4.884169, 52.375212, 5], 
                   [4.884214, 52.375198, 5], [4.884238, 52.375223, 5], 
                   [4.884196, 52.375238, 5]
               ]
           ]
         ]
  },
  "properties": {
    "name": "Anne Frank's House"
  }
}

(Bron: Spatial Data on the Web Best Practice, Coordinates encoded using GeoJSON)

{
  "type": "Feature",
  "geometry": {
    "type": "Polygon",
    "coordinates": [
      [ [4.884235, 52.375108], [4.884276, 52.375153], 
        [4.884257, 52.375159], [4.883981, 52.375254], 
        [4.883850, 52.375109], [4.883819, 52.375075], 
        [4.884104, 52.374979], [4.884143, 52.374965], 
        [4.884207, 52.375035], [4.884263, 52.375016], 
        [4.884320, 52.374996], [4.884255, 52.374926], 
        [4.884329, 52.374901], [4.884451, 52.375034], 
        [4.884235, 52.375108] ]
      ]
  },
  "properties": {
    "name": "Anne Frank's House",
    "description": "Museum house where Anne Frank & her family hid from the Nazis in a secret annex, during WWII."
  }
}

5.3 Keuze-aspecten

De volgende tabel geeft aan hoe GeoJSON scoort op de aspecten die een rol spelen bij de keuze voor een bestandsformaat.

Vraag	Antwoord	Toelichting
Is het format geospecifiek?	✓
Is het format gebaseerd op algemene ict standaarden?	✓	Gebaseerd op JSON (Javascript Object Notation), waardoor het heel eenvoudig is om er native (i.e. zonder te hoeven parsen of converteren) mee te werken in web browsers en veel programmeertalen (in tegenstelling tot XML/GML). Praktische voordelen: het is voor mensen te lezen in een tekst editor, er zijn veel tools en bibliotheken voor beschikbaar en er bestaat een grote community die ermee werkt.
Wordt het format ondersteund in GIS software?	～	GeoJSON wordt deels ondersteund, niet in alle pakketten. In QGIS wordt GeoJSON goed ondersteund, vanuit ArcGIS is vorafgaand een convertie nodig (hier is wel een geoprocessing tool voor ontwikkeld).
Ondersteunt het format het uitdrukken van schema's, en validatie tegen dat schema?	✓	JSON heeft een eigen schema formaat, JSON Schema. Daarnaast zijn er YAML definities beschikbaar.
Ondersteunt het format meerdere coordinaatsystemen?	～	Formeel niet, hoewel er een loophole in de standaard zit en dit in de praktijk wel door tooling ondersteund wordt: als er door alle aanbiedende en gebruikende partijen een afspraak over is, kan GeoJSON in combinatie met een andere CRS gebruikt worden.
Ondersteunt het format 3D?	～	Hoewel GeoJSON 3D geometrieën niet direct ondersteunt, is het wel mogelijk om een hoogtecoordinaat (altitude) op te nemen bij punten, lijnen en vlakken. Hiermee zou je 2D polygonen kunnen optrekken naar 3D.
Ondersteunt het format alle simple features geometrieën?	✓	Ja, GeoJSON ondersteunt alle 7 geometrietypes vanuit Simple Features.
Ondersteunt het format andere ISO 19107 geometrie types?	✕	Geen ondersteuning voor bogen, volumes of andere niet-simpele geometrietypen.
Is het format geschikt voor grote volumes?	～	Het zit een beetje tussen andere formaten in, maar is beter geschikt voor kleine volumes.
Is het format geschikt om semantiek aan te koppelen / in uit te drukken?	✓	Het is mogelijk om GeoJSON met linked data te combineren door gebruik te maken van JSON-LD 1.1.

5.4 Afspraken

5.4.1 3D geometrie

Uit de GeoJSON standaard:

A position is an array of numbers. There MUST be two or more elements. The first two elements are longitude and latitude, or easting and northing, precisely in that order and using decimal numbers. Altitude or elevation MAY be included as an optional third element.

An OPTIONAL third-position element SHALL be the height in meters above or below the WGS 84 reference ellipsoid.

Hierboven wordt een voorbeeld gegeven van een polygoon waarbij de 3D conventie is toegepast. Het representeren van 3D geometrieën beperkt zich daarom tot gevallen waarbij het voldoende is om extrusies te gebruiken van 2D geometrieën (2.5D). Daarnaast wordt er in de praktijk wel eens afgeweken van deze conventie - zo scrhijft MapBox GL voor om een property height op te nemen in GeoJSON, voor het weergeven van 3D geometrieën in interactieve kaarten.

5.4.2 Naamgeving

GeoJSON heeft geen specifieke naamgevingsconventies, echter kunnen de conventies van JSON gebruikt worden:

Attribuut namen dienen betekenisvol te zijn, met duidelijke semantiek.
Attribuut namen dienen camel-cased (ie, wordWordWord) ASCII strings te zijn.
Het eerste teken dien een letter, een underscore (_) of een dollarteken ($) te zijn. Navolgende tekens kunnen letters, cijfers, underscore of dollartekens zijn. Gereserveerde JavaScript keywords moeten vermeden worden. Bron: https://google.github.io/styleguide/jsoncstyleguide.xml
Member namen dienen camel-cased te zijn.
Member namen dienen te beginnen en te eindigen met “a-z” (U+0061 tot U+007A)
Member namen dienen alleen ASCII alphanumerieke tekens te zijn (i.e., “a-z”, “A-Z”, and “0-9”) Bron: https://jsonapi.org/recommendations/

5.4.3 Aantal decimalen

Uit de GeoJSON standaard:

The size of a GeoJSON text in bytes is a major interoperability consideration, and precision of coordinate values has a large impact on the size of texts. A GeoJSON text containing many detailed Polygons can be inflated almost by a factor of two by increasing coordinate precision from 6 to 15 decimal places. For geographic coordinates with units of degrees, 6 decimal places (a default common in, e.g., sprintf) amounts to about 10 centimeters, a precision well within that of current GPS systems. Implementations should consider the cost of using a greater precision than necessary.

Furthermore, the WGS 84 datum is a relatively coarse approximation of the geoid, with the height varying by up to 5 m (but generally between 2 and 3 meters) higher or lower relative to a surface parallel to Earth's mean sea level.

5.4.4 Gebruik in uitwisseling

De OGC heeft een set templates voor YAML schema’s die horen bij de OGC Feature API standaard, waarin ook GeoJSON geometrie beschreven is. YAML is een serialisatie format waarmee men OpenAPI definities vastlegt. Deze definities worden gebruikt om APIs op een eenduidige manier de beschrijven en te documenteren, zodat gebruikers begrijpen hoe ze de APIs kunnen bevragen. De templates van OGC zijn handig te gebruiken in API's waarmee geo-objecten gepubliceerd worden. De templates voor het definiëren van de schema's voor GeoJSON bevragingen zijn te vinden op featureCollectionGeoJSON.yaml en featureGeoJSON.yaml. Uiteraard bevatten deze templates alleen de generieke informatie die van toepassing is voor het definiëren van de geometrie. Specifieke informatie over typeringen en attributen zullen aanbieders zelf moeten toevoegen.

5.4.5 URIs in GeoJSON

JSON (en daarbij GeoJSON) staat maar een beperkt aantal primitieve datatypes toe. Om deze reden worden URIs geregistreerd als strings. Om de URIs alsnog te kunnen interpreteren zijn conventies nodig. Echter is het vanuit GeoJSON niet mogelijk om zulke conventies vast te leggen. Daarom is het belangrijk om informatie over je GeoJSON bestanden (bijvoorbeeld: details over object types, definities, etc) te registreren in de documentatie. Dit wordt verder beschreven in [Spatial Data on the Web Best Practice] 10).

6. GeoPackage

6.1 Introductie

GeoPackage is een OGC standaard voor de uitwisseling van geodata die gebaseerd is op SQLLite. Het wordt wel gezien als vervanger van Shapefiles. GeoPackage is in 2019 aangemeld voor de pas-toe-of-leg-uit lijst (PTOLU) en is inmiddels aan die lijst toegevoegd. Dit format vervangt GML op de PTOLU niet, maar bij het aanbieden van een download moeten Nederlandse overheidsorganisaties naast GML ook GeoPackage kunnen leveren.

GeoPackage is een “licht” formaat om geografische informatie uit te wisselen. Veel geografische software ondersteunt de GeoPackage standaard al, waaronder ook een paar populaire pakketten die moeite hebben met de verwerking van GML. GeoPackage is een binair formaat, en dus niet in een tekst editor te openen. Het ondersteunt een subset van de geometrie types zoals gedefinieerd in [iso-13249-3] - dit is een uitbreiding op het Simple Features data model van [iso-19125-1-2004], welke het opnemen van circulaire interpolaties mogelijk maakt. In de GeoPackage documentatie wordt een overzicht gegeven van de ondersteunde geometrie types.

Moderne datasets zoals de Basisregistratie Grootschalige Topografie zijn zó gedetailleerd, dat bestandsomvang een probleem gaat vormen bij het importeren van data in softwaresystemen. GeoPackage is een geschikt formaat voor het uitwisselen van geodatasets met een grote omvang, bijvoorbeeld wanneer gebruikers een grote dataset of subset daarvan willen downloaden om in hun lokale (GIS) systeem te gebruiken voor ruimtelijke analyses.

Daarnaast biedt GeoPackage ook een voordeel voor nieuwe gebruikers. Doordat GeoPackage gebaseerd is op generiekere ICT-oplossingen als SQLite, wordt geografische informatie beter toegankelijk voor gebruikers buiten het geo-domein.

Veel uitwisseling in het geo-informatiedomein verloopt nu in ketens van bronhouders naar een Landelijke Voorziening, van die Landelijke Voorziening naar een service provider en van de service provider naar een gebruiker. In de levering van bronhouder naar landelijke voorziening is het van belang dat het uitwisselformaat validatie mogelijk maakt. Zo kan je controleren of de informatiemodellen correct zijn toegepast, of de geometrie klopt etc. Daar is GML het meest geschikt voor. In de stap van serviceprovider naar gebruiker is validatie minder van belang dan zaken als performance, bestandsgrootte en ondersteuning in software. In die stap is GeoPackage, net als GeoJSON, een goed formaat om naast GML aan te bieden.

Een ander voordeel van GeoPackage is dat het formaat ook functionaliteit bevat voor visualisatie (in een extensie van de standaard), schema, tiling, metadata etc. Al deze informatie kun je in één GeoPackage bestand bundelen. De overstap van shapefiles naar GeoPackage is niet lastig. Je kan er ook niet-geo data in opslaan. De ETL straat van organisaties kan door gebruik van GeoPackage korter worden; er is goede ondersteuning voor GeoPackage in veel GIS software.

Bestanden worden soms zelfs in GeoPackage wel erg groot, bijvoorbeeld de landelijke set van BGT wegdelen was in een test tijdens de WFS-3 werkweek meer dan 60GB.

GeoPackage werkt doorgaans met platte datastructuren, de vaak complexe informatiemodellen van bijvoorbeeld basisregistraties moeten dus worden 'platgeslagen' zoals beschreven in de basisregels voor transformatie van een SF2 naar een SF0 model [gimeg].

GeoPackage werkt standaard met numerieke ID's. Dit geeft problemen met ID's van basisregistraties, die niet altijd numeriek zijn. Tijdens de WFS-3 werkweek bleek dat de applicatie moest worden aangepast om GeoPackage bestanden te kunnen doorzoeken op basis van het lokaal ID van basisregistraties in plaats van het standaard, numerieke ID.

6.2 Keuze-aspecten

De volgende tabel geeft aan hoe GeoPackage scoort op de aspecten die een rol spelen bij de keuze voor een bestandsformaat.

Vraag	Antwoord	Toelichting
Is het format geospecifiek?	✓
Is het format gebaseerd op algemene ict standaarden?	✓	GeoPackage is gebaseerd op SQLite, en is daardoor toegankelijk voor een grotere doelgroep datagebruikers
Wordt het format ondersteund in GIS software?	✓	In veelgebruikte GIS software (QGIS en ArcGIS pro) werkt het importeren en exporteren van GeoPackage prima - in QGIS is ondersteuning al beschikbaar sinds versie 2.10.1.
Ondersteunt het format het uitdrukken van schema's, en validatie tegen dat schema?	✕	Validatie wordt niet ondersteund. Een praktische oplossing hiervoor is om voor validatie het bestand te converteren naar GML en dat te valideren. Een GeoPackage bestand bevat genoeg informatie om dat mogelijk te maken.
Ondersteunt het format meerdere coordinaatsystemen?	✓
Ondersteunt het format 3D?	✕	Volumes worden niet ondersteund, wel bestaan er een aantal Community extensions voor GeoPackage, waaronder een voor 3D - echter zijn dit geen officiële GeoPackage extensies
Ondersteunt het format alle simple features geometrieen?	✓
Ondersteunt het format andere ISO 19107 geometrie types?	✕
Is het format geschikt voor grote volumes?	✓
Is het format geschikt om semantiek aan te koppelen / in uit te drukken?	✕

6.3 Afspraken

6.3.1 Naamgeving

Voor GeoPackage wordt het gebruik van snake_case aangeraden. Om de interoperabiliteit te stimuleren kunnen de database identifiers (tabel namen, kolom namen, etc.) met lowercase tekens worden opgenomen. Het is in ieder geval handig om alleen lowercase tekens, cijfers en underscores(_) te gebruiken.

7. Geography Markup Language (GML)

7.1 Introductie

Geography Markup Language [gml] is een uitwisselingsformaat voor geografische bestanden met een omvangrijke verzameling XML elementen voor het beschrijven van geografische data. Deze standaard is opgenomen in de pas-toe-of-leg-uit lijst van het Forum Standaardisatie. Het definieert XML-codering voor het overbrengen en opslaan van allerlei geo-informatie, zoals geometrie, topografie, coverages en sensordata. GML kan worden gebruikt voor bestandsuitwisseling tussen systemen maar ook binnen webservices zoals WFS.

GML is een uitgebreide standaard die oplossingen biedt voor uiteenlopende situaties en variaties in het uitwisselen van geo-informatie. Variaties zijn er bijvoorbeeld in geometrietypen, maar ook in complexiteit van datastructuren. Om op verschillende complexiteitsniveaus met GML te werken, heeft het OGC profielen gemaakt. Deze profielen omschrijven elk een subset van de totale GML-set. De standaardprofielen zijn GML Simple Feature Profile level 0, 1 en 2. Hoe hoger het level, hoe meer je ermee kan. Maar ook: hoe complexer en minder generiek het model wordt. Het is daarom altijd van belang voor- en nadelen van het te gebruiken profiel tegen elkaar af te wegen. De Handreiking Geometrie in model en GML beschrijft de toegestane geometrieen voor elk profiel in detail.

GML is gestandaardiseerd bij het OGC en, omdat OGC en ISO met elkaar samenwerken, ook gestandaardiseerd als ISO 19136:2007 [iso-19136-2007]. Inhoudelijk is dit dezelfde standaard. De ISO variant is opgenomen als nationale standaard in de Pas-toe-of-leg-uit-lijst van het Forum Standaardisatie. In Nederland wordt dus GML 3.2.2 gehanteerd, en GML 3.3 (dit is een uitbreiding op GML 3.2). De diverse onderdelen uit de 3.3 versie zijn modulair toe te passen en backwards compatible met versie 3.2. In Nederland wordt GML 3.1.1 ook nog ondersteund, omdat CityGML 2.0 [CityGML20] er gebruik van maakt en daarmee het BGT|IMGeo model. Omdat GML 3.2 een zeer uitgebreide standaard is wordt in Nederland met het Simple Feature Profile level 2 gewerkt.

GML is een uitgebreide standaard, die veel use cases aan kan:

Ondersteunt 3D geometrieën, inclusief volumes (solids).
Ondersteunt bogen (ook in het simple features profiel).
Zeer uitgebreide mogelijkheden voor validatie.
Geen beperking wat betreft coordinaatreferentiesystemen.

Juist de uitgebreidheid van GML geeft problemen bij de toepassing; het is een flinke taak om een goede en volledige implementatie van de standaard te maken. Ook het feit dat GML gebaseerd is op XML is soms een handicap. Tijdens de implementatie kan men tegen de volgende zaken aanlopen:

Hoewel complexe datastructuren mogelijk zijn in GML, is het in de praktijk, vanwege gebrekkige support hiervoor, vaak toch nodig om de structuur 'plat te slaan' zoals beschreven in Basisregels voor transformatie van een SF2 naar een SF0 model.
De support voor GML in (GIS en andere) software is beperkt. Meestal is een conversiestraat (ETL) nodig om GML in te kunnen lezen.
Bij grote datavolumes niet geschikt vanwege de verbositeit van XML.
Minder geschikt voor publicatie op het web vanwege de complexiteit van XML.

7.2 Voorbeelden

Voorbeeld 4: Voorbeelden van geometrie voor GeoJSON

GML - Voorbeeld 1
GML - Voorbeeld 2

Dit voorbeeld toont een fragment GML data in 3D, conform het [CityGML20] model.

(Bron: Open datasets created with 3dfier)
<CityModel xmlns="http://www.opengis.net/citygml/2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:gml="http://www.opengis.net/gml"
xmlns:wtr="http://www.opengis.net/citygml/waterbody/2.0"
xsi:schemaLocation="http://www.opengis.net/citygml/2.0 ./CityGML_2.0/CityGML.xsd">
<gml:name>my 3dfied map</gml:name>
<gml:boundedBy>
  <gml:Envelope srsDimension="3" srsName="urn:ogc:def:crs:EPSG::7415">
      <gml:lowerCorner>84122.824 446278.566 0</gml:lowerCorner>
      <gml:upperCorner>85999.614 447862.988 100</gml:upperCorner>
  </gml:Envelope>
</gml:boundedBy>
<cityObjectMember>
    <wtr:WaterBody gml:id="be551d510-0324-11e6-b420-2bdcc4ab5d7f">
        <wtr:lod1MultiSurface>
            <gml:MultiSurface>
                <gml:surfaceMember>
                    <gml:Polygon>
                        <gml:exterior>
                            <gml:LinearRing>
                                <gml:pos>85530.000 446588.709 -0.010</gml:pos>
                                <gml:pos>85531.832 446605.616 -0.010</gml:pos>
                                <gml:pos>85478.851 446567.507 -0.010</gml:pos>
                                <gml:pos>85530.000 446588.709 -0.010</gml:pos>
                            </gml:LinearRing>
                        </gml:exterior>
                    </gml:Polygon>
                </gml:surfaceMember>
              </gml:MultiSurface>
            </wtr:lod1MultiSurface>
        </wtr:WaterBody>
      </cityObjectMember>
</CityModel>

Een fragment GML voor het voorbeeld uit de andere secties (HTML, GeoJSON, RDF), conform model 'ex'.

<FeatureCollection xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns="http://www.geonovum.nl/IMVoorbeeld"
xmlns:ex="http://www.example.com/ex"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<gml:boundedBy>
  <gml:EnvelopesrsDimension="2"srsName="urn:opengis:def:crs:EPSG::4326">
    <gml:lowerCorner>4.884235 52.375108</gml:lowerCorner>
    <gml:upperCorner>4.884451 52.375034 4.884235</gml:upperCorner>
  </gml:Envelope>
</gml:boundedBy>
  <featureMember>
    <ex:Gebouw gml:id="H10">
     <ex:naam>Anne Frank's Huis</ex:naam>
     <ex:geometrie>
        <gml:Polygon gml:id="geom2">
            <gml:exterior>
                <gml:LinearRing>
                    <gml:posList>4.884235 52.375108 4.884276 52.375153 4.884257 52.375159 4.883981 52.375254 4.883850 52.375109 4.883819 52.375075 4.884104 52.374979 4.884143 52.374965 4.884207 52.375035 4.884263 52.375016 4.884320 52.374996 4.884255 52.374926 4.884329 52.374901 4.884451 52.375034 4.884235 52.375108</gml:posList>
                </gml:LinearRing>
            </gml:exterior>
        </gml:Polygon>
     </ex:geometrie>
    </ex:Gebouw>
  </featureMember>
</FeatureCollection>

7.3 Keuze-aspecten

De volgende tabel geeft aan hoe GML scoort op de aspecten die een rol spelen bij de keuze voor een bestandsformaat.

Vraag	Antwoord	Toelichting
Is het format geospecifiek?	✓	Ja, maar de uitgebreidheid van GML geeft problemen bij de toepassing; het is een flinke taak om een goede en volledige implementatie van de standaard te maken.
Is het format gebaseerd op algemene ict standaarden?	✓	Ja, GML is gebaseerd op XML (wat ook een nadeel kan zijn vanwege de complexiteit van XML)
Wordt het format ondersteund in GIS software?	～	De support voor GML in (GIS en andere) software is beperkt. Over het algemeen is een conversiestraat (ETL) nodig om GML in te kunnen lezen.
Ondersteunt het format het uitdrukken van schema's, en validatie tegen dat schema?	✓	Er zijn zeer uitgebreide mogelijkheden voor validatie vanwege de XML basis.
Ondersteunt het format meerdere coordinaatsystemen?	✓	In GML kan de definitie van een CRS via een URI worden meegegeven, als waarde van het attribuut `srsName`. Er is dus geen beperking wat betreft coordinaatreferentiesystemen.
Ondersteunt het format 3D?	✓	GML ondersteunt 3D geometrieën, inclusief volumes (solids).
Ondersteunt het format alle simple features geometrieen?	✓	Het format ondersteunt alle simple features geometrieën, inclusief bogen.
Ondersteunt het format andere ISO 19107 geometrie types?	✓
Is het format geschikt voor grote volumes?	✕	Bij grote datavolumes niet geschikt vanwege de verbositeit van XML.
Is het format geschikt om semantiek aan te koppelen / in uit te drukken?	✕	Semantiek kan op impliciete wijze worden toegevoegd door het schema af te leiden uit een informatiemodel en eventueel door in annotaties te linken naar een begrippenkader of tekstuele definities in het schema op te nemen.

7.4 Afspraken

7.4.1 Naamgeving

Voor XML elementen geldt dat de naam moet beginnen met een letter of underscore, en dat deze naam nooit mag beginnen met 'xml'. Element namen zijn hoofdlettergevoelig en mogen geen spaties bevatten. Voor GML geldt daarnaast dat UpperCamelCase wordt gebruikt voor XML element namen die betrekking hebben op Objects of Feature Types, en lowerCamelCase voor XML element namen die attributen of relaties representeren. Verder zijn er ook conventies voor GML schema's met als doel de leesbaarheid van deze documenten te verbeteren:

abstracte elementen hebben een prefix 'Abstract' (voor Objects) of 'abstract' (voor attributen) gekoppeld aan hun naam.
de namen van XML Schema complex types zijn in UpperCamelCase, en eindigen op het woord 'Type'. Daarnaast begint een abstracte XML Schema complex type met de prefix 'Abstract'.

8. RDF

8.1 Introductie

RDF wordt steeds meer gebruikt als uitwissel- en publicatiemechanisme voor geo-informatie op basis van Linked Data. RDF vormt de basis voor een set standaarden die bijdragen aan het gebruik en de publicatie van Linked Data. De afkorting RDF [rdf11-concepts] staat voor Resource Description Framework en is een standaard voor het representeren van informatie op het web als linked data, zodanig dat deze beschikbaar gemaakt kunnen worden in machineleesbare vorm op het web, niet als download maar als web pagina's, en daardoor ook beter bruikbaar zijn over sectorale grenzen heen. Het is dus niet een encoding maar een manier om hergebruik van data bij de bron te stimuleren, door koppelingen via persistente URI’s te ondersteunen. Stukjes data uit verschillende bronnen kunnen dan op een eenduidige manier met elkaar worden verbonden - zo'n koppeling wordt ook wel een 'triple' genoemd. Om het visueler te maken: de structuur die onstaat bij het koppelen van triples is dat van een graaf, waarbij de lijnen relaties beschrijven tussen twee dingen (waarvan minstens één een URI heeft).

Er zijn meerdere technische RDF encodings zoals bijvoorbeeld RDF-XML [rdf-syntax-grammar] en [turtle]. Naast deze encodings is ook mogelijk om RDF triples op andere manieren uit te drukken - zoals via JSON-LD of RDFa, bijvoorbeeld. RDFa wordt gebruikt om HTML uit te breiden met annotaties, welke ook als RDF data kan worden geïnterpreteerd. Met JSON-LD kan JSON worden omgezet naar triples middels de toevoeging van een @context tag (waarmee een JSON-LD parser de JSON als Linked Data kan interpreteren). Wanneer een gebruiker data uit verschillende bronnen wil afnemen en combineren kan dit van nut zijn - alle informatie is dan concreet gedefinieerd en vindbaar. En als dit niet nodig is, kan de @context tag genegeerd worden.

Hoe geometrie in RDF moet worden uitgedrukt is beschreven in vocabulaires. De OGC GeoSPARQL standaard [geosparql], zoals de naam al doet vermoeden, specificeert een extensie op de SPARQL query language, zodat gebruikers geodata in RDF kunnen bevragen. Het bevat ook een beknopte vocabulaire voor geo-objecten en geometrie.

8.2 Voorbeelden

Voorbeeld 5: Voorbeelden van geometrie voor HTML

Voorbeeld van een JSON-LD fragment met geometrie conform het GeoSPARQL vocabulair - in zowel WKT als GML, beide worden ondersteund in GeoSPARQL 1.0.

{
  "@context" : {
    "@vocab" : "http://schema.org/",
    "geosparql": "http://www.opengis.net/ont/geosparql#"
  },
    "@type" : "Place",
      "@id" : "http://www.ldproxy.net/bag/inspireadressen/inspireadressen.3329155",
    "name" : "Anne Frank's House",
    "geosparql:hasGeometry" : {
      "@type": "http://www.opengis.net/ont/sf#Polygon",
      "geosparql:asWKT": {
          "@type": "http://www.opengis.net/ont/geosparql#wktLiteral",
          "@value": "POLYGON((52.375108 4.884235, 52.375153 4.884276, 52.375159 4.884257, 52.375254 4.883981, 52.375109 4.883850, 52.375075 4.883819, 52.374979 4.884104, 52.374965 4.884143, 52.375035 4.884207, 52.375016 4.884263, 52.374996 4.884320, 52.374926 4.884255, 52.374901 4.884329, 52.375034 4.884451, 52.375108 4.884235))"
          },
      "geo:asGML": {
          "@type": "http://www.opengis.net/ont/geosparql#gmlLiteral",
          "@value": "
            <gml:Polygon>
               <gml:exterior>
                  <gml:LinearRing>
                     <gml:posList>
                        52.375108 4.884235, 52.375153 4.884276, 52.375159 4.884257, 52.375254 4.883981, 52.375109 4.883850, 52.375075 4.883819, 52.374979 4.884104, 52.374965 4.884143, 52.375035 4.884207, 52.375016 4.884263, 52.374996 4.884320, 52.374926 4.884255, 52.374901 4.884329, 52.375034 4.884451, 52.375108 4.884235
                      </gml:posList>
                  </gml:LinearRing>
               </gml:exterior>
            </gml:Polygon>"
          },
      "geosparql:crs": {
            "@id": "http://www.opengis.net/def/crs/OGC/1.3/CRS84"
        }  
  },
  "description": "Museum house where Anne Frank & her family hid from the Nazis in a secret annex, during WWII.",
    "address" : {
      "@type" : "PostalAddress",
      "streetAddress" : "Prinsengracht 267",
      "addressLocality" : "Amsterdam",
      "postalCode" : "1016GV"
    }          
}

De grafische representatie van de data uit de gebruikte voorbeelden. Voor een interactieve versie kan de data bekeken worden in de JSON-LD playground

Dezelfde data zoals getoond in het JSON-LD voorbeeld, maar dan volgens het veelgebruikte Terse RDF Triple Language (Turtle) formaat.

@prefix schema: <http://schema.org/> .
@prefix geosparql: <http://www.opengis.net/ont/geosparql#> .
<http://www.ldproxy.net/bag/inspireadressen/inspireadressen.3329155>
  a schema:Place ;
  schema:address [
    a schema:PostalAddress ;
    schema:addressLocality "Amsterdam"^^xsd:string ;
    schema:postalCode "1016GV"^^xsd:string ;
    schema:streetAddress "Prinsengracht 267"^^xsd:string
  ] ;
  schema:description "Museum house where Anne Frank & her family hid from the Nazis in a secret annex, during WWII."^^xsd:string ;
  geosparql:hasGeometry [ a <http://www.opengis.net/ont/sf#Polygon> ;
            geosparql:asGML "<gml:Polygon><gml:exterior><gml:LinearRing><gml:posList>52.375108 4.884235, 52.375153 4.884276, 52.375159 4.884257, 52.375254 4.883981, 52.375109 4.883850, 52.375075 4.883819, 52.374979 4.884104, 52.374965 4.884143, 52.375035 4.884207, 52.375016 4.884263, 52.374996 4.884320, 52.374926 4.884255, 52.374901 4.884329, 52.375034 4.884451, 52.375108 4.884235</gml:posList></gml:LinearRing></gml:exterior></gml:Polygon>"^^geosparql:gmlLiteral ;
            geosparql:asWKT "POLYGON((52.375108 4.884235, 52.375153 4.884276, 52.375159 4.884257, 52.375254 4.883981, 52.375109 4.883850, 52.375075 4.883819, 52.374979 4.884104, 52.374965 4.884143, 52.375035 4.884207, 52.375016 4.884263, 52.374996 4.884320, 52.374926 4.884255, 52.374901 4.884329, 52.375034 4.884451, 52.375108 4.884235))"^^geosparql:wktLiteral ;
            geosparql:crs <http://www.opengis.net/def/crs/OGC/1.3/CRS84> ] ;
  schema:name "Anne Franks House"^^xsd:string .

8.3 Keuze-aspecten

De volgende tabel geeft aan hoe RDF scoort op de aspecten die een rol spelen bij de keuze voor een bestandsformaat.

Vraag	Antwoord	Toelichting
Is het format geospecifiek?	✕	Het is een algemene Webstandaard. In combinatie met de GeoSPARQL vocabulaire is er wel ondersteuning voor geo-informatie.
Is het format gebaseerd op algemene ict standaarden?	✓	Ja, het is gebaseerd op W3C Linked Data standaarden
Wordt het format ondersteund in GIS software?	✕
Ondersteunt het format het uitdrukken van schema's, en validatie tegen dat schema?	✓	Ja, via [shacl] shape expressions
Ondersteunt het format meerdere coordinaatsystemen?	✓
Ondersteunt het format 3D?	✕	Je kunt op zich 3D geometrie opnemen in de data, maar GeoSPARQL ondersteunt geen 3D bij ruimtelijke vragen.
Ondersteunt het format alle simple features geometrieen?	✓
Ondersteunt het format andere ISO 19107 geometrie types?	✓	Ja, als je de GeoSPARQL GML serialisatie gebruikt
Is het format geschikt voor grote volumes?	～	In triple stores is goede ondersteuning voor grote hoeveelheden geometrieën in de data, maar bij het uitwisselen is een RDF bestand geen heel geschikt format vanwege verbositeit
Is het format geschikt om semantiek aan te koppelen / in uit te drukken?	✓	Bij uitstek geschikt. Gebruik van RDF voor het publiceren van gestructureerde gegevens op het web maakt het mogelijk dat data over de grenzen van sectoren heen gekoppeld en geïntegreerd worden.

8.4 Afspraken

In Nederland zijn er geen normatieve regels over het gebruik van RDF voor het uitwisselen van geometrie.

Wel zijn er de volgende handvaten:

RDF staat op de lijst met aanbevolen standaarden.
De Aanzet tot een Nationale URI-strategie [NLURIStrategie] beschrijft het in Nederland gehanteerde URI patroon.
Het Linked Data profiel op NEN 3610 [nen3610-linkeddata] beschrijft hoe een linked data model van een NEN 3610 conform informatiemodel kan worden afgeleid.
Voor het uitdrukken van geometrie in RDF gebruiken we de OGC GeoSPARQL Linked Data vocabulaire [geosparql].

8.4.1 Geometrie encodings

Aangezien Linked Data op basis van vocabulaires werkt, kunnen geometrieën op verschillende wijzen worden vastgelegd, zo lang er maar een vocabulair voor is. Uiteraard is de beste oplossing afhankelijk van de toepassing. Schema.org wordt vaak gebruikt voor annotaties en indexatie van data door zoekmachines. GeoSPARQL daarentegendeel is geschikter wanneer ruimtelijke bevragingen gewenst zijn, WGS84 niet voldoet, of verschillende en gestandaardiseerde geometrietypes gebruikt worden (GeoSPARQL wordt ondersteund in een aantal RDF Triplestores). Om deze reden wordt OGC GeoSPARQL aangeraden voor gebruik bij het uitwisselen van geometrie in RDF. De geometrie kan volgens GeoSPARQL op twee manieren worden geserialiseerd:

Als WKT, waarbij de Simple Feature geometrietypen uit ISO 19125 gebruikt kunnen worden (daardoor beperkt: geen 3D, geen bogen etc);
Als GML, waarbij de ISO 19107 geometrietypen gebruikt kunnen worden.

JSON-LD kan wordt gebruikt als RDF encoding door de JSON data te voorzien van een context tag, waarmee RDF data kan worden afgeleid. Echter is er een beperking wanneer je geometrie in JSON opneemt, zoals het geval is met GeoJSON. De JSON-LD 1.0 specificatie staat het namelijk niet toe om 'list of lists' om te zetten naar Linked Data (zie deze note), en deze heb je om bepaalde geometrieën uit te drukken wel nodig. Om deze reden zal een processor conform JSON-LD 1.0 zulke geometrieën overslaan.

Deze beperking is niet meer aanwezig in JSON-LD 1.1 (zie dit voorbeeld). Echter, JSON-LD 1.1 processors worden nog niet overal ondersteund.

A. Referenties

A.1 Normatieve referenties

[CityGML20]: OGC City Geography Markup Language (CityGML) Encoding Standard. Gerhard Gröger; Thomas H. Kolbe; Claus Nagel; Karl-Heinz Häfele. Open Geospatial Consortium. 4 April 2012. URL: https://portal.opengeospatial.org/files/?artifact_id=47842
[geosparql]: GeoSPARQL - A Geographic Query Language for RDF Data. Matthew Perry; John Herring. OGC. 10 September 2012. URL: http://www.opengeospatial.org/standards/geosparql
[gimeg]: Geometrie in model en GML. Linda van den Brink; Paul Janssen; Wilko Quak. Geonovum. URL: https://docs.geostandaarden.nl/nen3610/gimeg
[gml]: Geography Markup Language (GML) Encoding Standard. Open Geospatial Consortium Inc. URL: http://www.opengeospatial.org/standards/gml
[html5]: HTML5. Ian Hickson; Robin Berjon; Steve Faulkner; Travis Leithead; Erika Doyle Navara; Theresa O'Connor; Silvia Pfeiffer. W3C. 27 March 2018. W3C Recommendation. URL: https://www.w3.org/TR/html5/
[iso-13249-3]: Information technology — Database languages — SQL multimedia and application packages — Part 3: Spatial. ISO. 2016-01. Definitief. URL: https://www.iso.org/standard/60343.html
[iso-19107-2019]: Geographic information — Spatial schema. ISO. 2019-12. Definitief. URL: https://www.iso.org/standard/66175.html
[iso-19125-1-2004]: Geographic information -- Simple feature access -- Part 1: Common architecture. ISO/TC 211. ISO. 2004. International Standard. URL: https://www.iso.org/standard/40114.html
[iso-19136-2007]: Geographic information -- Geography Markup Language (GML). ISO/TC 211. ISO. 2007. International Standard. URL: https://www.iso.org/standard/32554.html
[NEN3610]: NEN 3610:2011 nl - Basismodel geo-informatie - Termen, definities, relaties en algemene regels voor de uitwisseling van informatie over aan de aarde gerelateerde ruimtelijke objecten. NEN. 2011-03-01. Definitief. URL: https://www.nen.nl/NEN-Shop/Norm/NEN-36102011-nl.htm
[nen3610-linkeddata]: NEN 3610 - Linked Data. Linda van den Brink; Marco Brattinga; Marinus Vonhof; Niels Hoffmann; Pano Maria; Hans Schevers; Ronald van Lanen; Joep van Genuchten. Geonovum. 23 maart 2020. URL: https://docs.geostandaarden.nl/nen3610/nldp/
[NLURIStrategie]: Aanzet tot een nationale URI-Strategie voor Linked Data van de Nederlandse overheid. Hans Overbeek; Linda van den Brink. Platform Linked Data Nederland. URL: http://www.pilod.nl/wiki/Boek/URI-strategie
[OAPIF]: OGC API - Features - Part 1: Core. Clemens Portele; Panagiotis (Peter) A. Vretanos; Charles Heazel. Open Geospatial Consortium. 14 oktober 2019. URL: http://docs.opengeospatial.org/is/17-069r3/17-069r3.html
[rdf-syntax-grammar]: RDF 1.1 XML Syntax. Fabien Gandon; Guus Schreiber. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-syntax-grammar/
[rdf11-concepts]: RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/
[RFC7946]: The GeoJSON Format. H. Butler; M. Daly; A. Doyle; S. Gillies; S. Hagen; T. Schaub. IETF. August 2016. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc7946
[RFC8259]: The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed.. IETF. December 2017. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc8259
[shacl]: Shapes Constraint Language (SHACL). Holger Knublauch; Dimitris Kontokostas. W3C. 20 July 2017. W3C Recommendation. URL: https://www.w3.org/TR/shacl/
[turtle]: RDF 1.1 Turtle. Eric Prud'hommeaux; Gavin Carothers. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/turtle/