BRK Percelen filteren op buurt, wijk, stadsdeel ... ipv kadastraleGemeentecode

Naast het filteren op kadastraleGemeentenaam of kadastraleGemeentecode zouden we ook graag filteren op buurt, wijk, stadsdeel etc.

Weet iemand of deze gebieden gestandaardiseerd zijn, een unieke code of nummer hebben, en middels welke API de percelen na BRK selectie op gemeentenaam of gemeentecode verder gefilterd kunnen worden?

Amsterdam kent bijvoorbeeld buurten, wijken, gebieden, praktijkgebieden en stadsdelen. Hoe verhouden die zich tot kadastrale gemeentecodes? Of, gaat dat misschien via postcodes?

Zie Gebiedsindelingen

Inmiddels zie ik dat wijk en buurt beschikbaar zijn via de locatieserver door een geografisch punt te uploaden met afstand 0.

Klopt het dat er geen directe mapping is van kadastrale gemeentecode en sectie naar wijk of buurt?

Kadastrale gemeentes zijn iets heel anders dan bestuurlijke gemeentes, en de wijken en buurten zijn onderdeel van de bestuurlijke gemeentes (of van het CBS, afhankelijk van waar je je gegevens vandaan haalt). De enige koppeling die daar tussen zit is hun ligging, maar meer dan dat heb je eigenlijk ook niet nodig.

Dus als je alleen de percelen voor een specifieke buurt of wijk wil hebben, dan kun je de grens van die buurt of wijk gebruiken om je percelen te filteren. Voor zover ik weet zit er noch in de BRK noch in de Bestuurlijke grenzen, noch in de CBS data een administratieve link tussen percelen en buurten en wijken.

Bedankt voor de uitleg. Welke API zou ik kunnen gebruiken om volgens hal+json of anders json de geometrie van een wijk en buurt op te halen?

De CBS WFS lijkt mij…

https://www.pdok.nl/introductie/-/article/cbs-gebiedsindelingen

Aangezien ik BRK Percelen met kadastraleGemeentenaam of kadastraleCode bevraag doe ik nu een reverse geo lookup via de Locatieserver op zowel buurt, wijk, gemeente en provincie.

Dat levert een gecombineerde locatie string waarop de eindgebruiker met een substring kan matchen.

Dit werkt verassend snel en het lukt om de BRK Percelen met 16 threads parallel te bevragen. Hoger heb ik niet geprobeerd. Zowel BRK server als Locatieserver lijken dit goed bij te kunnen houden.

16 threads parallel? Lijkt mij dat je dan niet meer onder de fair use policy valt, als ik eerlijk ben.
Wat probeer je te doen? Waarom heb je een dergelijke hoeveelheid data nodig?

Even voor testen opgeschaald. Normaal zitten we lager. We worden vanzelf afgekapt door de quota bewaking. Het betreft een search waarbij allerlei bronnen binnen het kadaster en daarbuiten geraadpleegd worden.

Zie de andere thread BRK v1 Percelen paginering volgens application/hal+json nog steeds onjuist - #4 door RobinTopper - BRK - Geoforum over het typisch gebruik en de vraag of op termijn een klant specifieke SLA mogelijk is.

Als je percelen wilt streamen, zou ik de DKK WMS gebruiken, geen WFS.
Of uberhaupt een andere benadering kiezen, maar om daar iets over te roepen zou ik de business case moeten kennen (en nog minstens 5 keer “waarom” moeten vragen :wink: ). Er zijn altijd meer wegen naar Rome…

De BRK Percelen worden nu in chunks (page=index, page_size=20) opgehaald en worden binnen de search intra chunk gestreamed. Na uitputting van de chunk wordt de volgende chunck (page=index+gap, page_size=20) opgehaald. Gap is gelijk aan het aantal parallelle threads.

Voldoende grote chunks over HTTPS connecties die hergebruikt en gedeeld worden moeten het TCP/IP transport efficiënt houden.

Heb van het perceel alleen de geografie nodig om BAG Panden, BAG Verblijfsobjecten en Ruimtelijke Plannen te bevragen. Daarnaast nog kadastrale gemeentenaam, kadastrale code, sectie, perceelnummer etc ter identificatie en inperking van het zoekdomein.

Wat kan DKK WMS mij extra bieden?