Zoals op 18 juni aangekondigd wil PDOK slimmere zoekmogelijkheden voor de OGC API Features beschikbaar stellen. Deze mogelijkheden gaan we voor alle datasets invoeren. Voor de BAG (Basisregistratie Adressen en Gebouwen) OGC API Features stellen we alvast een demoversie beschikbaar waar de filtering hebben aangezet. Dit bericht is bedoeld om op te roepen deze nieuwe functionaliteit tot 5 oktober 2026 te testen en ons via het Geoforum te voorzien van jullie opmerkingen.
Wil je per collectie weten wat mogelijk is? Via het schema is zichtbaar welke Queryables zijn te gebruiken, kijk bijvoorbeeld hier voor de adrescollectie. Om per dataset direct alle mogelijkheden te zien, laat je dan informeren via de Conformance. Onder Features is zichtbaar gemaakt welke definitieve OGC specificaties van Features part 3 zijn geïmplementeerd. Ten aanzien van de CQL2-specificatie zijn de toegepaste mogelijkheden opgenomen onder het kopje CQL.
Gemelde vragen en antwoorden onder dit topic zullen we als nodig meenemen in onze FAQ. Heb je een uitbreiding voor de leermodule met een goede use case? Stuur ons een verbetervoorstel.
Uitleg of meer lezen?
Voor uitleg van afkortingen en begrippen die gaan over webservices en OGC API’s, klik hier
Zijn jullie van plan om naast GET ook POST te ondersteunen voor het opvragen en filteren van features?
Bij het gebruik van S_INTERSECTS kan een polygon veel coördinaten bevatten, zeker wanneer deze ook holes bevat. Hierdoor kan de maximale URL-lengte van een GET-request worden overschreden.
De use case is het zoeken naar de verblijfsobjecten (VBO’s) die binnen een kadastraal perceel liggen. De geometrie van zo’n perceel kan te groot om als CQL2-filter in de URL mee te sturen.
Ondersteuning van POST, waarbij het filter en de geometrie in de request body kunnen worden opgenomen, zou dit probleem oplossen.
We gaan er op dit moment vanuit dat GET-requests voor regulier gebruik voldoende zijn. De maximale URL-lengte is tegenwoordig bovendien veel minder beperkend dan vroeger.
Mocht je toch tegen problemen aanlopen met specifieke requests, laat het ons dan weten.
Houd er daarnaast rekening mee dat binnen enkele maanden de open dataset Kadastrale Objectlocaties beschikbaar komt. Deze dataset bevat geografische objecten waarin kadastrale percelen en appartementsrechten zijn opgenomen. Optioneel zijn deze objecten gekoppeld aan BAG-adresseerbare objecten en de bijbehorende nummeraanduidingen. Deze dataset integreert gegevens uit de Basisregistratie Kadaster (BRK) en de Basisregistratie Adressen en Gebouwen (BAG), zodat per perceel of appartementsrecht inzichtelijk wordt welke BAG-objectlocaties zich daarop bevinden. De OGC-API features van deze dataset is denk ik exact wat je zoekt voor jullie use case.
Mooi dat CQL2 eraan komt! Ik heb de demo getest (ik ben gelijk begonnen het in mijn R-package te implementeren) en loop tegen een paar dingen aan.
BETWEEN op huisnummer vergelijkt als tekst in plaats van als getal
Collectie adres: bij het filteren op huisnummer:
filter=... AND huisnummer > 15 werkt zoals verwacht: je krijgt 16, 18, 20, enzovoort.
filter=... AND huisnummer BETWEEN 1 AND 3 geeft ook 10, 12, 13, 122, 137, … terug in plaats van alleen 2 en 3. De waarden worden hier blijkbaar als tekst vergeleken, niet als getal.
Als workaround heb ik het geprobeerd met aanhalingstekens (huisnummer BETWEEN '1' AND '3'), maar dat geeft de foutmelding “expecting NumericLiteral”. Je moet dus getallen invullen, maar ze worden behandeld als tekst.
Ik denk dat dit komt door de typering van adres in de queryables, daar staat huisnummer als string, maar in de Catalogus BAG staat het als Integer gedefinieerd. In de collecties ligplaats, standplaats en verblijfsobject van de demo-API staat huisnummer wél als integer. Zou het in de collectie adres ook integer kunnen worden?
Reproductie: .../v2-demo/collections/adres/items?filter=openbare_ruimte_naam='Amsterdamseweg' AND woonplaats_naam='Amersfoort' AND huisnummer BETWEEN 1 AND 3
Een te lang filter breekt de verbinding af zonder foutmelding
Voor het binnenhalen van schoolgebouwen (koppeling aan het Register Onderwijs Instellingen) wil ik enkele duizenden objecten op identificatie ophalen. Dat kan alleen met een lange IN (...)-lijst in de URL, en bij een aantal tests werd duidelijk dat een URL-lengte van boven de ± 33 kb de verbinding wordt verbroken zonder een HTTP-respons (bv een 414 URI Too Long). In mijn geval ging het bij 1300 BAG-identificaties in één lijst gewoon goed maar bij 1400 niet meer. Een 414-foutmelding zou al veel helpen; POST-ondersteuning (zoals ook door @thijs1 gevraagd) zou ook goed helpen.
Grote wens: toegestane waarden opnemen in de queryables
Voor velden met een vaste waardenlijst uit de Catalogus BAG — zoals gebruiksdoel en status — vermelden de queryables nu alleen "type": "string". Ik wilde zoeken op onderwijslocaties en probeerde gebruiksdoel = 'onderwijs', maar krijg dan een geldig maar leeg antwoord, want het moet de waarde 'onderwijsfunctie' zijn. Dit kun je nu alleen niet via de API ontdekken. Zouden jullie de enum in het JSON Schema voor dit soort domeinvelden kunnen vullen?
Dank voor de feedback, fijn dat jullie ermee aan de slag gaan. We hebben deze inhoudelijk vraag binnen het Kadaster aan de BAG voorgelegd. Maar ik lees meer vragen, we zullen eea even onderzoeken. Een antwoord blijven we nog even schuldig.
Hoi Coen, we hebben besloten om de fix met een volgende major upgrade mee te nemen. Deze wijziging is namelijk een breaking change. We zullen alvast voorbereidingen treffen zodat we het met een volgende versie mee kunnen nemen.