BRT API gebruiken voor download type gebouw

Datasets BRT
#1

Hallo,

Graag vraag ik jullie om wat hulp om een type gebouw, bijvoorbeeld fabriek uit de TOP10NL te kunnen downloaden mbv de BRT API (1). Ik heb al een API key. Wat ik probeer dmv CURL is het volgende, alleen krijg ik 10 polygonen terug terwijl er toch veel meer fabrieken in de TOP10NL zitten.

curl -s -X POST "https://brt.basisregistraties.overheid.nl/api/v2/gebouwen?typeGebouw=fabriek" -k -H "Accept: application/hal+json" -H "Content-Type: application/json" -H "X-Api-Key: %%MIJNKEY%%" -H "Accept-Crs: epsg:28992" -H "Content-Crs: epsg:28992" -d "{\"geometrie\":{\"intersects\":{\"coordinates\":[[[10426.282,306846.198],[10426.282,621876.3],[278026.09,621876.3],[278026.09,306846.198],[10426.282,306846.198]]],\"type\":\"Polygon\"}}}"

Kunnen jullie mij verder helpen hoe ik dit aan de praat kan krijgen? Ook zou ik de data indien mogelijk als punten terug krijgen.

Alvast bedankt!

Met vriendelijke groet,

Jelmer Oosthoek

(1) https://www.pdok.nl/restful-api/-/article/basisregistratie-topografie-brt-topnl#/paths/~1gebouwen/post

#2

Er zitten query parameters voor paginering op dat endpoint: page en pageSize. Standaard krijg je 10 resultaten op de eerste pagina, maar dit kan je aanpassen door een andere waarde voor pageSize op te geven. De volgende pagina kan je opvragen door ?page=2 achter je request te plakken of de links te volgen die onderin de respons staan (voorbeeld uit IHR API):

   "_links": {
        "next": {
            "href": "https://ruimte.omgevingswet.overheid.nl/ruimtelijke-plannen/api/opvragen/v3/_zoek?pageSize=50&page=2"
         },
        "prev": {
            "href": null
        },
        "self": {
            "href": "https://ruimte.omgevingswet.overheid.nl/ruimtelijke-plannen/api/opvragen/v3/_zoek?pageSize=50&page=1"
        }
    }

Bij deze API heb je niet de vrijheid om zelf te bepalen wat je in de respons wilt hebben. Dus opvragen als punten zal niet gaan.

1 like
#3

Dank voor het antwoord, ik heb het werkende gekregen!

#4

Als ik het goed zie, is de polygon in je requestbody een vierkant om heel Nederland heen. Als je gebouwen gaat opvragen waar er meer dan 10.000 van bestaan in Nederland, loop je tegen de limieten van de paginering op (page x pageSize <= 10.000).

Komen we meteen op het punt dat ik eerder had moeten maken: de BRT REST API is geen download service. Voor downloads van de Top10NL moet je hier zijn: Downloads - PDOK

1 like
#5

Ah ok, goed om te weten! Ja ik heb ook ervaring met de TOP10NL GMLs inderdaad.

#6

Ik zie dit toch met enige regelmaat terugkomen. Zou het misschien een idee zijn om dat aantal van 10.000 wat terug te schroeven tot 5000 of 1000 of zo, en er na dat aantal een foutmelding van te maken waarin staat dat voor ophalen van alles of meer dan het maximum aantal de download gebruikt moet worden?

Het probleem met die 10.000 (zoals ik het zie, althans) is dat het er zoveel zijn dat mensen al gauw denken: “oh, da’s zoveel, nu heb ik alles wel” terwijl dat niet zo is. En dat kan heel verwarrend werken. Als je het tot een aantal beperkt waarvan duidelijk is dat het nooit alles kan zijn wat je zoekt, en er vervolgens een foutmelding terugkomt met vermelding naar de downloadservice, is het misschien van het begin af aan duidelijker.

Overigens heb ik geen idee of zoiets mogelijk is hoor, maar het is misschien het overwegen waard.

1 like
#7

Had de hoop dat een niet-ontwikkelaar hier nog een antwoord op zou willen geven … :disappointed:

Als ontwikkelaar vind ik een limiet van 10.000 objecten/features/dingen helemaal niet zo hoog. Het aantal objecten in de gemiddelde dataset is vele malen hoger.
Het belangrijkste doel van de limiet is het tegengaan van het “harvesten” van de service (het downloaden van de hele dataset via de API). Of de hoogte van de limiet dan 1.000 of 10.000 moet zijn, is zeker een punt waarover discussie mogelijk is. Ik kan een paar voorbeelden bedenken waar een limiet van 1k-5k niet voldoende is voor “normaal” gebruik van één van onze APIs. Een wisselende limiet instellen op de verschillende APIs kan, mijns inziens, alleen maar leiden tot verwarring bij gebruikers vanwege een gebrek aan consistentie.

De foutmelding die je momenteel krijgt bij het overschrijden van de limiet in de BAG/BRK-DKK/Top10NL/IHR/RCE/RVO/DUO REST APIs is heel onduidelijk. Heb een story op ons backlog gezet om daar verbetering in aan te brengen.

Gezien het aantal vragen over paginering, lijkt het me ook goed om de documentatie van de APIs nog eens langs te lopen en dit duidelijker te vermelden. Heb ik ook op ons backlog gezet.

1 like