Eisen en aanbevelingen aan een vectordata levering

PDOK heeft voor de validatie van Geopackages een selfservice gebouwd die de bestanden controleert op een aantal eisen en waar nodig aanbevelingen doet over de data. Hieronder wordt uitgelegd op welke eisen en aanbevelingen de Geopackage wordt gecontroleerd.

De eisen en aanbevelingen komen voort uit de OGC standaarden en aanvullende PDOK standaarden.

Eisen aan de hand van de Quickcheck validatie

# 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 verwerken, verwachten wij één type casing. Dit betreft snake_case (https://en.wikipedia.org/wiki/Snake_caseLinkLink 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.
RQ4 GeoPackages bevatten geen views. Dit 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.
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 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-startedLinkLink 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.
RQ13 Alle geometrie features moeten van hetzelfde 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 vanuit 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 door middel van 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.
RQ21 Alle laagnamen en kolomnamen mogen niet langer zijn dan 57 tekens. Aanbevelingen aan de hand van de selfservice.
RQ22 Alleen de volgende ruimtelijke projecties zijn toegestaan: 28992, 3034, 3035, 3040, 3041, 3042, 3043, 3044, 3045, 3046, 3047, 3048, 3049, 3857, 4258, 4326, 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).
RQ23 Elke geometrie is geldig en simpel volgens de OGC OpenGis specificaties. De inhoud van de dataset moet volgens OGC standaarden.
RC17 Voor een uniforme uitlevering adviseren wij alle geometrie kolommen de naam 'geom' te geven. PDOK-aanbeveling: voor uniforme verwerking en uitlevering.
RC18 Voor een uniforme uitlevering adviseren wij alle geometrie kolommen van alle tabellen in een GeoPackage dezelfde naam te geven. PDOK-aanbeveling: voor uniforme verwerking en uitlevering.
RC19 We raden aan om alleen multidimensionale geometrieë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.
RC20 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.