Max startindex voor kadastrale kaart WFS 10000, beetje laag?

Hoi, bij het fixen van https://github.com/rduivenvoorde/pdokservicesplugin/issues/45 kwam ik er achter dat het ophalen van bv alle gebouwen van een plaats mbv QGIS (en pdokservicesplugin) niet meer gaat als je meer dan 10000 features op wilt halen.

Je krijgt dan de melding:

2021-11-09T18:17:57     CRITICAL    Layer perceel : Download of features for layer kadastralekaartv4:perceel failed or partially failed: WFS exception report (code=InvalidParameterValue text=
              It is not possible to use a 'startindex' higher then 10.000. When you 
              need to scrape the WFS I kindly refer you to the extracts available 
              for this dataset.
              ). You may attempt reloading the layer with F5

Zie:

https://geodata.nationaalgeoregister.nl/kadastralekaart/wfs/v4_0?SERVICE=WFS&REQUEST=GetFeature&VERSION=2.0.0&TYPENAMES=kadastralekaartv4:bebouwing&STARTINDEX=11000&COUNT=1000&SRSNAME=urn:ogc:def:crs:EPSG::28992&BBOX=103911.39476094619021751,488441.57337842142442241,106290.58905758152832277,492463.74275752349058166,urn:ogc:def:crs:EPSG::28992

Ik vind het wel jammer dat het ‘maar’ 10000 zijn, ik weet dat er extracten zijn, maar het is vaak handig om even snel de gebouwen of percelen van een plaats op te halen. En dan is 10000 wat aan de lage kant.

Ik zou liever 100.000 of 1.000.000 hebben :wink:

Of doe ik iets fout? Of is er een slimmere manier?

(ik begrijp ook wel dat er grenzen moeten worden gesteld, maar zeker als we de WFS toch willen blijven gebruiken/promoten als ‘haal altijd verse data op’ dan moeten we ook niet te streng worden… toch?

Je kan kleinere zoekgebieden defineren door bijv de BBOX op te delen.

Of de download API van de kadastralekaart gebruiken
OAS → PDOK API - Swagger UI
UI → PDOK download viewer

De download API is specifiek gemaakt om ‘grotere’ gebieden en grote hoeveelheden features snel/efficient op te halen.

Gelukkig :+1:

Om eerlijk te zijn kunnen wij bij PDOK haast niet wachten om over te stappen naar OAF :smiley: Gezien wij vanuit ons perspectief daarmee een betere dienstverlening kunnen bewerkstelligen, er een beter gedefineerd koppelvlak is voor afnemers. Door o.a. heldere alternativen (bijv GPKG) te kunnen adverteren aan gebruikers.

De ervaring is nu dat hogere limiten scrapping in de hand werkt met alle gevolgen van dien. Zeker wanneer er geen BBOX (voor een spatialindex) in het request zit, na mate men dieper gaat je tegen “deep paging” issues aanloopt.

Ik weet bijna zeker dat ie vorige week nog op 50.000 stond. Heeft iemand dat de afgelopen dagen dan bewust teruggeschroefd?

Dat durf ik niet zo direct te zeggen,… zal rond vragen of er een ticket o.i.d. m.b.t dit onderwerp recent is langsgekomen.

Ik heb rond gevraagd en commits voor je langsgelopen, maar voor de DKK is de limit 10.000 geweest.
De laatste commits op de DKK stack waren in juli m.b.t. liveness probes.

Misschien dat je de BAG bedoelde? Maar daar zijn we recent juist van 10.000 → 50.000 gegaan.

We hebben het er nu ook intern over, of we dit op termijn ook voor de DKK kunnen doen.

Hoewel dit technisch snel geregeld is :slight_smile: , is dit niet een beslissing die wij bij PDOK alleen kunnen nemen en moet er o.a. met de bronhouder het een en ander worden kortgesloten.

Sorry, ja ik bedoelde de BAG (panden)

@raymondnijssen, we hebben dit nu gelijk getrokken met de BAG (50.000)

1 like

Dit topic is 180 dagen na het laatste antwoord automatisch gesloten. Nieuwe antwoorden zijn niet meer toegestaan.