Functionele eisen bij aanlevering van datasets

Inleiding

PDOK is in 2020 begonnen met het 3G-programma, wat staat voor drie belangrijke principes:

  1. Geautomatiseerd
  2. Gestandaardiseerd
  3. Generiek

Daarmee benaderen wij elke dataset gelijk en niet als maatwerk. Dit komt de beheerbaarheid ten goede en ondersteunt de groei en stabiliteit van de PDOK infrastructuur.

Ook biedt PDOK daarom een vast aantal productcombinaties aan, zoals bijvoorbeeld voor INSPIRE geharmoniseerde datasets gebaseerd op vectordata:

  • View-service: WMS
  • Download-service: Atom
  • Optioneel eventueel een WFS met als service type ‘Other’, waarmee het niet de officiële downloadservice is voor INSPIRE.

3G-nieuwsbrief

PDOK verstuurt nieuwsbrieven over dit 3G-programma. Klik hierLink naar een externe pagina om die te lezen.

Bent u data-aanbieder en wilt u deze 3G-nieuwsbrieven ook ontvangen in uw eigen mailbox? Dan kunt u zich daarvoor hier aanmelden.

Gestandaardiseerd

Wat betekent ‘gestandaardiseerd’ voor u als data aanbieder? PDOK wil de data op een standaard manier aangeleverd krijgen zodat deze geautomatiseerd, generiek verwerkt kan worden. Naast de dataset aanlevering heeft PDOK ook per dataset een ingevuld intakeformulier nodig. Dit intakeformulier wordt door PDOK samen met de data aanbieder ingevuld, die daar uiteindelijk ook zijn akkoord op geeft.

Aanlevering:

Dataset gebaseerd op vectordata:

  • Aanlevering via Geopackage
  • Wat betreft de naamgevingen van zip-bestanden en geopackages:
    • De bestandsnaam van de zip zelf mag een dynamisch naam zijn.
    • De bestandsnamen van bestanden in de zip moeten elke levering hetzelfde zijn.

AS-IS INSPIRE dataset:

  • Aanlevering via Geopackage

Geharmoniseerde INSPIRE dataset:

  • Voor realisatie WMS en optionele WFS moet de dataset als Geopackage aangeleverd worden.
  • Voor realisatie Atom moet de dataset als gevalideerde GML aangeleverd worden.
  • Wanneer een aanbieder voor INSPIRE zowel GML en een Geopackage aanlevert verwachten wij 1 Zip-bestand

Een dataset met rasterdata heeft ook specifieke kenmerken en aanlevering. Op dit moment wordt dit nog uitgewerkt door PDOK en daarom is de aanlevering hiervan nog niet opgenomen in dit document.

In dit document zijn hierna de functionele eisen samengevat die PDOK aan een vector-data Geopackage stelt en hoe wij de data met behulp van een intakeformulier gaan verwerken.

Uitgangspunten

Wat gaat PDOK geautomatiseerd verwerken en hoe?

Controle aan de poort

Geopackages voor een WMS/WFS worden binnen PDOK gevalideerd met de PDOK Geopackage validator. De validatie regels worden door PDOK ter beschikking gesteld en op termijn ook het gebruik van de validator.

De aan PDOK aangeleverde data moet voldoen aan een aantal regels die in het kort neerkomen op:

Metadata

Het metadata record van de dataset is door de data aanbieder aangemaakt in het Nationaal Georegister (NGR) (www.nationaalgeoregister.nLink naar een externe pagina). De provider kent immers de inhoud van de dataset. PDOK is verantwoordelijk voor de metadata van de services in het Nationaal Georegister welke gelinkt wordt naar het metadata record van de dataset.

Dataset

Data is beperkt tot de relevante data die gewenst is om te ontsluiten via de services. De data aanbieder is verantwoordelijk voor de data inhoud / kwaliteit en voor de aanlevering van de data in het juiste formaat. De data opbouw (tabellen, naamgeving, kolommen etc.) die wordt gebruikt bij implementatie van een nieuwe service wijzigt niet bij een update van een dataset. Een wijziging kent een apart traject (los van updates). Dat data aan de specificatie voldoet, is de verantwoordelijkheid van de data aanbieder. Naamgeving wordt aangehouden over de dataset in de verschillende bestanden. Dus een laagnaam die gewenst is in de service en tabelnaam komen overeen. Stijlnamen worden eenduidig gebruikt. Als laag en stijl overeenkomen wordt een vergelijkbare naam gebruikt. Als het dataschema verandert of de service verandert krijgt de data een nieuwe versie. Zie het kopje intakeformulier voor invulling van het versienummer.

Aanvullende uitgangspunten bij een dataset die aangemerkt is als INSPIRE geharmoniseerde dataset:
INSPIRE geharmoniseerd vectordata dataset:
Indien een dataset als INSPIRE geharmoniseerd is aangemerkt, wordt naast de Geopackage die nodig is voor de realisatie van de WMS en optionele WFS met servicetype other ook een dataset als gevalideerde GML verwacht. Naamgeving van tabellen en kolommen moet overeenkomen met het bijbehorende INSPIRE model wat hoort bij het thema van de dataset.

Aanleveringen

  • De bronhouder is verantwoordelijk voor de styling, maar voorkeur heeft wel het aantal stijlen tot een minimum te beperken;
  • Indien beschikbaar ontvangen we een schema van de dataset of een specificatie waarin anderszins de structuur van de dataset wordt omschreven;
  • Bij grote en complexe datasets zal PDOK deze gaan tilen (WMTS vs WMS) in verband met de performance;
  • Datasets voor WMS worden aangeleverd via een Geopackage;
  • Het Geopackage moet na afstemming foutloos door de PDOK validator komen (de exacte validatie wordt hierna uitgelegd).

Formaat

  • Data wordt aangeleverd in een geopackage (m.u.v. de geharmoniseerde datasets waarvoor we voor de Atom gevalideerde GML willen ontvangen).
  • Informatie over de aanlevering wordt vastgelegd in een intakeformulier wat momenteel een vastgesteld formulier (door PDOK) in Excel is en waarvan het gebruik hierboven is beschreven.

Styling

  • Stylen worden aangeleverd per stijl in mapfile, SLD of PDF formaat.
  • SLD-namen komen overeen met de geopackage-kolomnamen waar de SLD styling voor gebruikt wordt.
  • Stylen zijn genamespaced (dus [Service ID]:[Laagnaam])

Inhoudelijk kan PDOK de data niet valideren, maar wel de datastructuur en kaartlagen in het Geopackage, deze hebben namelijk een 1 op 1 relatie bij het gebruik van Geopackages in Mapserver.

Geopackage validatie (WMS)

Voor een WMS-service worden eisen gesteld aan de performance, index, kaartlagen en geometrieën. PDOK heeft daarom naast de OGC eisenLink naar een externe pagina aanvullende eisen gesteld aan Geopackages. Bron: Github public.

Wat valideert PDOK?

PDOK gebruikt GeoPackages als bestandsformaat voor het aanleveren van vector-data voor webservices (WMS, WFS en WMTS). Voor Atomfeeds zijn zowel GML als GeoPackage de opties (beide kan ook). Op dit moment wordt alleen in het kader van de webservices (WMS, WFS en WMTS) de geopackage gevalideerd. Het standaard aanleverformaat voor raster data wordt aan gewerkt.

Op dit moment valideert PDOK GeoPackages voor haar webservices GeoPackages valideren wij op basis van een set validatieregels. Deze regels dienen vier samenhangende doelen, op volgorde van belangrijkheid:

  1. Op een geautomatiseerde wijze kunnen aanleveren en verwerken van deze datasets.
  2. Op een geautomatiseerde wijze deze datasets uitleveren in onze webservices.
  3. at op een efficiënte manier kunnen doen (met behoud van performance bij aanlevering en het uitserveren van data). 4. Daarbij vormt het GeoPackage een standaard transportmiddel tussen data leverancier en PDOK.

Aanleveren en verwerken los van service

Hierbij staat de wijze van aanleveren en verwerken in principe los van de verwerking en het uitserveren van de data. Wanneer dit kan wordt er echter wel voor gekozen om zo veel mogelijk gebruik te maken van de vorm en de opzet van de aangeleverde data. Het loskoppelen van aanlevering en verwerking enerzijds en de uitlevering anderzijds zorgt ervoor dat wij de manier van uitleveren kunnen wijzigen zonder daarbij de aanlevering te moeten wijzigen. Dit heeft een positief effect op de stabiliteit van de aanleverregels.

Geopackage als transportmiddel

We zetten een geopackage als transportmiddel in, waarbij we de metadata uit de geopackage standaard gebruiken om controles uit te voeren. Daarnaast is het correct toepassen van die standaard voor ons belangrijk voor een correcte levering en verwerking.

Regels in detail

Naast de eisen die voortkomen uit de GeoPackage specificatie toetsen we een geopackage op PDOK specifieke eisen. We gaan hieronder in detail in op de verschillende validatieregels en de reden waarom we hierop controleren.

# Geopackage validatie eis Omschrijving
RQ1 Laagnamen zijn snake_case: ze moeten met een letter beginnen. Geldige karakters zijn a-z, nummers en underscores. Om op een generieke en gestandaardiseerde manier GeoPackages te kunnen verwerken, verwachten wij één type casing. Dit betreft snake_case (https://en.wikipedia.org/wiki/Snake_caseLink naar een externe pagina conform het advies van de GeoPackage standaard (zie “Creating a GeoPackage” in https://www.geopackage.org/guidance/getting-startedLink naar een externe pagina). In output van webservices leveren wij daar waar nodig de data uit in casing volgens de standaard van het outputformaat. Voor bijvoorbeeld INSPIRE output (bijvoorbeeld WMS laagnamen) wordt deze casing omgezet naar CamelCase.
RQ2 Lagen moeten ten minste één feature bevatten. Datasets worden geautomatiseerd verwerkt. Deze regel is opgenomen om vooraf te controleren of er wel degelijk data wordt aangeleverd (voor iedere laag). Geen features kan leiden tot klachten van gebruikers.
RQ3 Elke geometriekolom heeft als geometrietype 1 van de volgende: POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, or MULTIPOLYGON Dit is een oude regel die wordt ingevuld door RQ14 en RQ15.
RQ4 GeoPackages bevatten geen views. is ten behoeve van de performance. Een view kan complexe queries bevatten die door ons niet te controleren zijn op performance. Waardoor deze de performance van het verwerken en/of het uitlezen van de GeoPackage in onze services sterk kunnen drukken. We willen data met zo min mogelijk tussenstappen kunnen uitlezen. Indien de brondata views bevat, dienen deze eerste in tabellen gematerialiseerd te worden om aangeleverd te kunnen worden.
RQ5 lke geometrie is geldig volgens de OGC OpenGis specificaties. Data moet geldig zijn voor een correcte verwerking en/of het uitserveren in onze services. PDOK gebruikers verwachten ook OGC standaarden.
RQ6 Kolomnamen moeten snake_case zijn. ze moeten met een letter beginnen. Geldige karakters zijn a-z, nummers underscores. Om op een generieke en gestandaardiseerde manier GeoPackages te kunnen verwerken, verwachten wij één type casing. Dit betreft snake_case (https://en.wikipedia.org/wiki/Snake_caseLink naar een externe pagina) conform het advies van de GeoPackage standaard (zie “Creating a GeoPackage” in https://www.geopackage.org/guidance/getting-startedLink naar een externe pagina). Voor bijvoorbeeld GML output wordt deze casing omgezet naar CamelCase.
RQ7 Een tabel bevat een primary key kolom met index. Indices hebben een grote positieve impact op de performance op het uitlezen en het uitserveren van de data in de webservices van PDOK.
RQ8 Het bij PDOK bekende datamodel mag niet wijzigen. De GeoPackage moet voldoen aan de gegeven tabel-definities. Deze regel heeft betrekking op inhoud van de data zelf. Hiermee controleren we de consistentie tussen de leveringen. Dit borgt de consistentie van de services door de tijd (dat de naamgeving en datatypen die wij uitserveren consistent blijft). Wijzigingen in het datamodel kunnen in overleg met PDOK doorgevoerd worden waarbij de impact van de wijzigingen beoordeeld kunnen worden.
RQ9 Elke tabel met geodata heeft een bijbehorende R-tree (index). R-tree indices zijn geo-indices. Deze indices hebben een grote positieve impact op de performance op het uitlezen en het uitserveren van de data in de webservices van PDOK.
RQ10 Alle R-tree-indexen van de geometrietabel moeten geldig zijn. Aanvullend op RQ9, controleren wij de r-tree index zelf middels sqlite (de rtreecheck functie).
RQ11 De aantallen in de OGR contents tabel (gpkg_ogr_contents) moeten up-to-date zijn. Dit helpt ons de integriteit van de levering te controleren. Deze metadata tabel helpt bij grotere GeoPackages en heeft een grote positieve impact op de performance op het uitlezen (paging) en het uitserveren van de data in de webservices van PDOK.
RQ12 Alleen de volgende ruimtelijke projecties zijn toegestaan: 28992, 3034, 3035, 3038, 3039, 3040, 3041, 3042, 3043, 3044, 3045, 3046, 3047, 3048, 3049, 3050, 3051, 4258, 4936, 4937, 5730, 7409. Dit is de subset van projecties die PDOK hanteert voor datasets. Nederland valt binnen deze projecties. De lijst bevat 3034-30XX: verschillende UTM zones van ETRS89 (het Europees Terrestrisch Referentiesysteem 1989), RD (rijksdriehoek), RD+NAP, en veelgebruikte projecties als Web Mercator en WGS84 (World Geodetic System 1984).
RQ13 Alle geometrie features moeten van het zelfde ruimtelijke referentie systeem zijn in een GeoPackage. In de service moeten alle lagen (of featuretypes/coverages) dezelfde bronprojectie hebben. Dit helpt bij de eenduidige uitlevering van de dataset.
RQ14 Alle geometrietypen in de GeoPackage geometrie metadata tabel (gpkg_geometry_columns) moeten van één type zijn uit de set: POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, of MULTIPOLYGON. Dit betekent ook dat er in een tabel maar één uniek geometrietype mag zitten. Bijvoorbeeld het mixen van MULTIPOINT en POINT is niet toegestaan. Dit helpt ons bij de verwerking. Zo zijn de geometrietypen duidelijk en direct in het GeoPackage terug te vinden. Dit helpt tevens voor afnemers dat zij er van uit kunnen gaan dat deze altijd gelijk is. Een combinatie van MULTI- en “single” geometrieën leidt in de GeoPackage tot het generieke GEOMETRY (het basis geometrietype) waarmee deze informatie niet beschikbaar is.

Daarnaast sluit deze beperktere set aan geometrietypen aan bij simpele implementaties zoals beschreven in de geopackage implementatie handleidingLink naar een externe pagina. En helpt daarmee bij een zo breed mogelijk gebruik van deze data indien deze middels geopackage worden ontsloten. Hierom staan we GEOMETRY als geometrietype niet toe.
RQ15 Alle geometrieën in een tabel moeten een geometrietype hebben wat overeenkomt met het geometrietype uit de GeoPackage geometrie metadata tabel (gpkg_geometry_columns). Dit is onderdeel van de GeoPackage specificatie. We controleren dit om ervoor te zorgen dat de verwerking en uitlevering van data foutloos en correct gebeurt.
RC1 Voor een uniforme uitlevering adviseren wij alle geometrie kolommen de naam 'geom' te geven. PDOK-aanbeveling: voor uniforme verwerking en uitlevering.
RC2 Voor een uniforme uitlevering adviseren wij alle de geometrie kolommen van alle tabellen in een GeoPackage dezelfde naam te geven. PDOK-aanbeveling: voor uniforme verwerking en uitlevering.
RC3 We raden aan om alleen multidimensionale geometriën (3D of 3D + een meting) te gebruiken wanneer deze nodig zijn. Indien een dataset niet uit 3D geometrieën bestaat raden wij aan om deze als 2D geometrieën aan te leveren. Daarnaast raden wij het gebruik van de M waarde af in coördinaten. Het is beter deze als attribuut (kolom) in een geopackage tabel op te nemen.
RC4 Voor een uniforme uitlevering adviseren wij alle (multi)polygon geometrieën een tegen-de-klok-in-oriëntatie te geven. Dit betekent een oriëntatie die tegen de klok in is voor de buitenste ring en met de klok mee voor de binnen ringen (enz. voor diepere nesting). De OGC GeoPackage specificatie dwingt dit niet af. INSPIRE schrijft een richting voor. Voor de consistentie van alle PDOK services, en voor uniforme verwerking en uitlevering, adviseren wij de INSPIRE richtlijn voor datasets en webservices te volgen.
 

Op deze Github paginaLink naar een externe pagina kun je uitgebreid de actuele technische validaties lezen.

Geopackage

Een GeoPackage (GPKG) is een open, niet-gepatenteerd, platformonafhankelijk en op standaarden gebaseerd gegevensformaat voor een geografisch informatiesysteem geïmplementeerd als een SQLite-databasecontainer. Gedefinieerd door het Open Geospatial Consortium (OGC) met de steun van het Amerikaanse leger en gepubliceerd in 2014, heeft GeoPackage brede steun gekregen van verschillende overheids-, commerciële en open source-organisaties.

Ondanks tientallen bestandsindelingen en services voor het uitwisselen van georuimtelijke gegevens, was er geen open formaat dat zowel raster- als vectorgegevens kon ondersteunen, terwijl het efficiënt kon worden gedecodeerd door software, vooral op mobiele apparaten. Deze behoefte werd formeel uitgedrukt tijdens de OGC in 2012. De kandidaat-standaard werd in februari 2014 door de OGC goedgekeurd.

Een GeoPackage is opgebouwd als een uitgebreid SQLite 3 databasebestand (*.gpkg) met data- en metadatatabellen met gespecificeerde definities, integriteitsverklaringen, formaatbeperkingen en inhoudelijke beperkingen. De GeoPackage-standaard beschrijft een reeks conventies (vereisten) voor het opslaan van vectorkenmerken, tegelmatrixsets met afbeeldingen en rasterkaarten op verschillende schalen, schema's en metagegevens. Een GeoPackage kan worden uitgebreid met behulp van de uitbreidingsregels zoals gedefinieerd in clausule 2.3 van de standaard. Aanvullende (leveranciersspecifieke) extensies kunnen ook worden toegevoegd door de regels voor GeoPackage-extensies te volgen, maar dit kan de interoperabiliteit beïnvloeden. GeoPackage is ontworpen om zo licht mogelijk te zijn en te zitten in één kant-en-klaar enkel bestand. Dit maakt het geschikt voor mobiele applicaties in niet-verbonden modus en snel delen op cloudopslag, USB-drives, enz. De GeoPackage-extensie F.3 RTree Spatial Indexes specificeert hoe SQLite ruimtelijke indexen moeten worden gebruikt om de prestaties op ruimtelijke zoekopdrachten te versnellen. vergeleken met traditionele georuimtelijke bestandsindelingen.

Service output

Bij het opvragen van een WMS getfeatureinfo of WFS getfeature request in het GML,XML of (Geo) JSON formaat wordt in de output niet altijd op een consistente en gestandaardiseerde manier omgegaan met de naamgevingen. Zo kan het zijn dat je features of attributen in snake_caseLink naar een externe pagina en in een ander geval CamelCaseLink naar een externe pagina terugkrijgt van de services. Omdat we onze services consistent en gestandaardiseerd willen aanbieden, gaat PDOK alle nieuwe of gewijzigde WMS en WFS services (daar waar er sprake is van nieuwe URL’s) voorzien van consistente en gestandaardiseerde naamgevingen (cases). Na overleg met Geonovum over deze standaardisatie betekent dit concreet dat in de output van een getfeature(info) request een feature in UpperCamelCase door PDOK wordt geretourneerd en een attribuut in lowerCamelCase. Bij het opvragen van een feature (WFS) of laag (WMS) wordt dezelfde naamgeving (dat wil zeggen UpperCamelCase) gebruikt ten behoeve van consistentie. Na wat onderzoek gedaan te hebben verwachten we geen problemen voor afnemers bij het bevragen van onze webservices, maar mocht dit onjuist zijn dan hoort PDOK dit natuurlijk graag!

Aanleveringen door data-aanbieders

Bovenstaande betreft de output. Voor wat betreft de input (aanlevering van de geodata) blijft PDOK haar data-aanbieders vragen (in het kader van het 3G programma) om naamgevingen van lagen/features en attributen in GeoPackages als snake_case aan te leveren. Dit is conform het advies in de GeoPackage standaard. Vanwege deze eenduidige en gestandaardiseerde manier van aanleveren kan PDOK eenvoudig en eenduidig de gestandaardiseerde output leveren aan afnemers.

Output Feature/Laag Attributen
GML UpperCamelCase LowerCamelCase
XML UpperCamelCase LowerCamelCase
(Geo)JSON UpperCamelCase LowerCamelCase
  Voorbeeld - Feature/Laag Voorbeeld - Attributen
  Verblijfsobject typeAdresseerbaarobject
  BeschermdeGebieden beginLifeSpanVersion

Juridische context

Voor meer informatie over onderstaande onderwerpen, klik op de bijbehorende hyperlink.