Voor een nieuwe applicatie dat ik wil ontwikkelen ben ik momenteel bezig met het ontdekken van de verschillende PDOK api’s.
Laat ik op de eerste plaats zeggen dat ik het geweldig mooi (en leuk) “spul” vind om mee te werken.
Nu heb ik twee vragen waar ik niet direct het antwoord op kan vinden en wellicht zijn ze gerelateerd aan mijn onervarenheid met het onderwerp.
Vraag 1:
Waarom is het niet mogelijk om de API’s te bevragen met een POINT ipv een Boundingbox? In mijn usecase klikt een gebruiker op een kaart en dan wil ik informatie tonen zoals: adres, perceel, pand(en), verblijfsobject(en).
Echter: de API’s werken allemaal met BBox als geo-afbakening. Nu kan ik natuurlijk een lat,lng met wat kunstgrepen omvormen tot een kleine BBox maar je loopt er dan altijd tegen aan dat dit niet exact het punt is waarvan je de informatie wilde opvragen.
Nu doe ik het daarom als volgt:
na klik doe ik een reverse geocoding request mbv de Locatieserver. Dan kan ik met behulp van de geocoding-response de BBox van het adres of perceel pakken.
Met de gevonden BBox kan ik vervolgens de BAG-api van het kadaster bevragen.
Vraag 2:
Als ik via de BAG api (Basisregistratie Adressen en Gebouwen (OGC API)) informatie over een adres opvraag dan geeft deze een adresseerbaar_object_identificatie mee (voor bijvoorbeeld een verblijfsobject) maar deze id is vervolgens niet te gebruiken als “Feature ID” om via dezelfde API de informatie over dit verblijfsobject op te vragen. Dit moet dan weer via een BBox.
Ligt het aan mij of is het niet veel handiger als die ID’s die je via adres terug krijgt direct kan gebruiken om informatie over andere collections te bevragen.
Alvast bedankt voor de reacties en ik ga vol goede moed verder met ontdekken.
Betreffende vraag 1: momenteel is inderdaad alleen een filter op bounding box mogelijk. Er wordt echter gewerkt aan ondersteuning voor de filter parameter (OGC API Features part 3) en daarmee kan je wel een point intersects doen op basis van een zogenaamde CQL expressie.
Dat zou er dan bijvoorbeeld als volgt uitzien: /items?filter=S_INTERSECTS(geometry,POINT(379213.87 3610774.16)). Dit is allemaal nog even onder voorbehoud maar weet dat er ontwikkelingen zijn. Verder is de aanpak die je nu hanteert (via locatieserver) prima.
Een kleine aanvulling: het leggen van relaties tussen de collecties wordt door de data-aanbieder aan PDOK verstrekt. Ook de huidige geimplementeerde ‘filters’ is in afstemming met data-aanbieder vormgegeven. Ik lees verder dat je functionaliteit mist. We zijn bijvoorbeeld nu met uitbreiding van filtering bezig. Houdt de nieuwsberichten in de gaten dt gaat je zeker verder helpen. Weet dat we nog niet klaar zijn met alle ontwikkelingen en er nog steeds doorontwikkeld wordt.
Ook ten aanzien van gebruik reverse geocoderen en de Locatieserver. Volgende week lanceren we de nieuwe Location API, check die ook. Maar weet dat reverse gecoderen nog onderwerp van onderzoek is.
Je bent eigenlijk met je vraag net iets te vroeg. Toch denk ik dat je met het antwoord van mijn collega al meters kunt maken. Wij vinden het geweldig: dank voor je post!