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?
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.
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.
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 ). 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.
). Er zijn altijd meer wegen naar Rome…