PDOK is in 2020 begonnen met het 3G-programma, wat staat voor drie belangrijke principes:
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:
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.
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.
Wat gaat PDOK geautomatiseerd verwerken en hoe?
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:
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.
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.
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.
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.
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:
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.
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.
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.
Op deze Github paginaLink naar een externe pagina kun je uitgebreid de actuele technische validaties lezen.
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.
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!
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.
Voor meer informatie over onderstaande onderwerpen, klik op de bijbehorende hyperlink.