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 hier 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:
    o De bestandsnaam van de zip zelf mag een dynamisch naam zijn.
    o 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.nl). 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 eisen aanvullende eisen gesteld aan Geopackages. Bron: Github public.

Wat valideert PDOK?

Validatie Omschrijving
Tabelnamen komen overeen met de laagnamen voor de betreffende service (exclusief de namespacing). Namen van tabellen in geopackages worden as-is toegepast
Geopackages bevatten alleen tabellen die nodig zijn, geen tabellen zonder records (tabellen met data en de geopackagespecifieke tabellen zoals de tabellen met informatie van de rtrees)
Geopackage tabellen bevatten alleen relevante kolommen Voor weergave in WMS GetFeatureInfo
Kolommen die getoond dienen te worden (bij getfeatureinfo) performance in WMS
Kolommen met een primary key of index performance in WMS
Geopackages bevatten geen views performance in WMS
Elke tabel heeft een feature id kolom, een aanvullende kolom die uniek is en geïndexeerd is t.b.v. performance in WMS
Elke tabel met geodata heeft een bijbehorende RTREE (index) Geopackage.org
Elke geometriekolom heeft als geometrietype 1 van de volgende:
ο POINT
ο LINESTRING
ο POLYGON
ο MULTIPOINT
ο MULTILINESTRING
ο MULTIPOLYGON
Geopackage.org
featuretabelnaam bevat alleen kleine letters conform geopackage.org
featuretabelnaam bevat geen leestekens anders dan underscores conform geopackage.org
Elke geometrie is valide volgens de OGC OpenGis specifcaties te testen met een ST_IsValid() functie" Data Schema is stabiel conform OGC Geen wijzigingen in kolomnamen en attribuutnamen bij data updates

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.

Juridische context

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

• Producten- en Dienstencatalogus (PDC) van PDOK: klik hier
• Privacy: klik hier
• Open data: klik hier
• Cookies: klik hier
• Algemene voorwaarden: klik hier
• Copyright: klik hier
• Toegankelijkheid/webrichtlijnen: klik hier
• FAQ, instructiefilmpjes & support: klik hier