Input van afnemers over OGC API’s van PDOK gevraagd (historie en geometrieën)

Standaarden
,
1

PDOK heeft Inmiddels een aantal OGC API’s beschikbaar gesteld. Naast Tiles en 3D Geovolumes sinds kort ook OGC API Features. Om tot een duurzame implementatie te komen willen we graag twee vragen voorleggen aan afnemers en leveranciers van applicaties.

Historie (standaard meeleveren of niet)

Sinds kort is het mogelijk om, indien er sprake is van een feature met historie, een datum (+ tijd; datetime) in een OGC API Features op te geven (bijvoorbeeld https://api.pdok.nl/lv/bgt/ogc/v1_0-demo) waarmee gebruikers:

  • Eén of meerdere features inclusief volledige historie van features op kunnen vragen.
  • De stand van één of meerdere features op een specifieke peildatum op kunnen vragen.

In de huidige implementatie krijg je default de volledige historie terug (optie 1). Wanneer je alleen interesse hebt in de geldende situatie dan kun je de datum van vandaag opgeven of je kunt een datum in het verleden opgeven met als resultaat de stand van het feature op die datum.

We vragen ons of af hoe gebruikers (eventueel vanuit client perspectief) naar bovenstaande inrichting kijken?

Geometrie types (in één feature of opsplitsen)

Momenteel leveren we in de OGC API Features demo variant (https://api.pdok.nl/lv/bgt/ogc/v1_0-demo) meerdere geometrietypes in één feature uit. Dat wil zeggen dat je in één response meerdere geometrietypes terug kunt krijgen. In WFS services doen we het omgekeerde (per geometrie type een feature). We zijn erg benieuwd naar wat de voorkeur geniet en om welke redenen (en indien van toepassing welke client gebruikt wordt).

1 like
2

Na gesprekken met gebruikers hebben we besloten om de huidige situatie in stand te houden voor de historie. De OGC APIs Features geven dan nu dus standaard (default) de volledige historie terug als er geen peildatum wordt opgegeven in het request. Zo sluiten we dicht aan bij de specificatie.

Voor de geometrietypes gaan we een wijziging doorvoeren. We hebben besloten dat we de collecties voor de door ons ontsloten OGC API Features op gaan splitsen op geometrietype. Zo leveren de OGC API Features iedere respons een vast type uit en is er een zo breed mogelijk aantal clients (ook de clients die dus één geometrietype per collection verwachtten) dat de OGC API features kan tonen.

Bovenstaande zullen we ook voor de BGT OGC API features toepassen als we de v1 ontsluiten, collecties worden daar opgesplitst op geometrietypen.

1 like