BRK v1 Percelen paginering volgens application/hal+json nog steeds onjuist

Het buiten de page index adresseren van BRK v1 Percelen leek onlangs opgelost voor kadastraleGemeentecode maar faalt nu ook voor kadastraleGemeentenaam. Bij testen op kadastraleGemeentecode lijkt willekeurig sommige out-of-range pagina waarden wel goed [] te retourneren terwijl andere waarden in een exception stranden.

Het volgende request …

curl -X GET -H “Accept-Crs: epsg:28992” -H “Accept: application/hal+json” “https://brk.basisregistraties.overheid.nl/api/v1/percelen?page=516&pageSize=20&kadastraleGemeentenaam=Apeldoorn

resulteert in een exception en geeft een 400 bad request resultaat …

{“timestamp”:1602494881577,“path”:"/percelen",“status”:400,“error”:“Bad Request”,“message”:"[OpenApi] An Exception occurred [Validation of request parameters failed] resulting in [400] reason [Error while obtaining request parameters.]",“requestId”:“19b2a244-284707”}

De reden hiervoor staat vrij duidelijk in de OpenAPI specificatie bij de page parameter

Paginanummer voor paginering. Deze is gelimiteerd zodat het totaal aantal op te vragen resultaten niet hoger is dan 10000`

Dit is een service die niet bedoeld is als downloadservice, dus er is een limiet op het aantal op te vragen resultaten gezet. Het vertoonde gedrag is dus geen bug, en ook niet iets dat we gaan aanpassen.

Kreeg wisselende resultaten met hogere page index waarden. Is dit een limiet per tijdseenheid?

Heb je voor mij een link naar de documentatie voor de page index? Gekeken bij swagger.io maar kan het niet zo direct vinden.

Staat vrijwel onderaan in https://brk.basisregistraties.overheid.nl/api/v1 .

Nee, dit is geen limiet per tijdseenheid. Het is een harde limiet op een combinatie van page en pageSize:

page x pagesize < 10000

Oeff … dat is lastig. Ons gebruik is niet zo zeer download maar streaming. Filters met de hoogste negatives ratio worden als eerste gedraaid om zoekruimte en server load te beperken. Typisch gebruik is dat eindgebruikers binnen een stadswijk of stadsbuurt willen zoeken. Dit gebeurt nu door eerst BRK Percelen op gemeentenaam te bevragen en vervolgens op buurt of wijk te filteren.

Moet ik nu zelf bijhouden welke kadastrale gemeente codes eventueel aangevuld met secties binnen een wijk of buurt vallen? Om vervolgens over die collecties te itereren om per iteratie op een lager page index bereik uit te komen? Heeft een kadastrale gemeentecode eventueel aangevuld met een sectie letter altijd gegarandeerd minder dan 10000 hits?

We zitten nu nog in de ontwikkelfase en kunnen nu met deze limiet wel uit de voeten. Sluit niet uit dat onze eindgebruiker bij acceptatie over wil gaan tot commerciële exploitatie en daartoe een SLA met jullie wil afsluiten met allerlei performance criteria waaronder mogelijk ook deze 10000 items limiet.

Kan jij mij per pm in contact brengen met een business account manager waarmee we dit kunnen gaan bespreken?

Beste John,

Ik heb geen persoonlijke gegevens van jou en kan jou niet op een andere manier bereiken dan via het Geoforum. Zou jij mij willen bellen op 06 52481894 of email Fons.sanders@kadaster.nl.

Vriendelijke groet,

Productmanager PDOK,
Fons Sanders

Heb inmiddels met Fons gesproken. We pakken dit op met het aangaan van een SLA op het moment dat we in produktie gaan.

Dit onderwerp kan wat mij betreft gesloten worden.