Voor de verkiezingen is het van zeer groot belang dat in de
basisregistraties van de gemeenten bij elk bewoond verblijfsobject
bekend is wat het waterschap is waar dat object binnen valt.
Voor het bepalen van hoeveel stemlocaties worden ingericht en waar
binnen de gemeente, wil de gemeente ook tellingen doen van kiezers
per wijk en buurt, dus ook die gegevens zouden idealiter aan een
verblijfsobject moeten zijn gekoppeld.
PDOK levert die gegevens op afroep met een maximumaantal results van 100 via de API
De WFS ondersteunt echter niet de bevraging als in de PDOK API voor het opvragen van VBO gegevens. Voor wat WFS biedt kan ik ook een volledige set van heel Nederland opvragen, maar ook die voldoet niet aan de data als geleverd in de PDOK API.
Navraag via telefoon en e-mail verwijst me naar WFS. Ik voel dit als een spagaat waarin rondjes worden gelopen en kastje-muur
Vraag is dus in basis of dat
OF de limiet kan worden verhoogd in de API
OF paginering kan worden ondersteand in de API
OF een complete PDOK adresset kan worden opgevraagd per gemeente
De locatieserver ondersteunt zeker paginering. Zie de API specificatie voor meer details over wat er mogelijk is.
Kort gezegd werkt het als volgt: als je op het free endpoint een geldige query uitvoert, inclusief de parameter rows=100, krijg je de eerste (maximaal) 100 resultaten terug. In de response zit ook het attribuut numFound, wat aangeeft hoeveel resultaten er gevonden zijn voor de opgegeven zoekterm(en). Als er meer dan 100 resultaten zijn, kan de volgende pagina met resultaten worden opgevraagd door de query opnieuw uit te voeren, met toevoeging van de start parameter.
Praktisch voorbeeld: er wordt een query uitgevoerd met rows=100, welke als resultaat o.a. teruggeeft "numFound": 250. Deze eerste bevraging heeft de eerste 100 resultaten opgeleverd. De volgende pagina’s worden dan bevraagd met rows=100&start=100 (tweede 100 resultaten) en rows=100&start=200 (laatste 50 resultaten).
Als ik opvraag op basis van gemeentecode, stopt het steevast bij start=10100. De documentatie meldt inderdaad dat er een maximum is van 10000, maar dat is altijd te weinig als een request is gebaseerd op (toegestanen) gemeentecode. Voor gemeentecode 0396 is het aantal in numFound gelijk aan 21396 maar die kan ik niet allemaal ophalen:
Werk je liever met een API, dan zou je gebruik kunnen maken van de BAG OGC API Features. Deze ondersteunt uitgebreide paginering (zie dit voorbeeld, in het links attribuut bevindt zich een link van type "rel": "next", waarmee de volgende pagina kan worden opgevraagd).
Hierbij moet wel rekening gehouden worden met twee zaken: ten eerste bevat de OGC API Features alle verblijfsobjecten inclusief historie. Ten tweede heb je niet direct de mogelijkheid om te filteren op bijvoorbeeld gemeentecode - de beste benadering is waarschijnlijk om alle verblijfsobjecten binnen de bounding box van de gemeente op te vragen, en deze zelf te filteren op basis van de attributen.
Ik vraag me af of een bevraging van de PDOK locatieserver -of de BAG API- leidt tot een antwoord op deze vragen. Op z’n best leidt zo’n bevraging -in combinatie met een kaart van waterschapsgrenzen- tot het aantal verblijfsobjecten per woonplaats/waterschap. Maar dat zegt natuurlijk niks over aantallen inwoners, laat staan kiesgerechtigden.
Een beter vertrekpunt lijkt me de CBS Postcodegebieden, hoewel die geen inzicht geeft in het aantal 18+ inwoners.
Uit mijn eigen gemeentelijke verleden weet ik dat gemeenten in staat moeten zijn om aantallen 18+ inwoners per wijk/buurt af te leiden uit de “eigen” Basisregistratie personen.
Met de waterschapsgrenzen kan vervolgens worden bepaald welke wijk binnen welk waterschap valt.
Ben het volledig eens met Bart. Inwoners en hun kiesgerechtigheid kan (moet!) de gemeente afleiden uit hun eigen GBA, waarin ook vastgelegd is op welk VBO die inwoner geregistreerd staat. Gemeenten zijn daarnaast zelf ook verantwoordelijk voor de inhoud van de BAG, en dus ook de VBO’s. Dus dat deel van de vraag kunnen ze intern beantwoorden.
Gemeenten zijn ook verantwoordelijk voor Wijk- en Buurt-indelingen, dus ook die gegevens hebben zij zelf in huis - zonder dat ze daarvoor bij PDOK of het CBS langs hoeven te gaan. Wederom zijn zij zelf daar bronhouder.
Om te zien welke wijken, buurten en VBO’s binnen welk waterschap vallen, is een eenvoudige overlay met de waterschapsgrenzen, die door de waterschappen zelf aan PDOK geleverd worden, het enige wat dan nog nodig is.
Dus voor het beantwoorden van de gestelde vragen in de eerste post, is de Locatieserver niet de juiste dienst. Bovendien levert de locatieserver in veel gevallen vereenvoudigde geometrie, en zijn ruimtelijke queries gebaseerd op die geometrie dus niet betrouwbaar.
Wel grappig dat Bart, Stefan en ikzelf de oplossing zien in “je doet een eenvoudige GIS-overlay” , terwijl de dataset achter de locatieserver een adressentabellen is met een enorme verrijking (met gegevens over gebiedsindelingen (incl. waterschap!) , kadastrale info etc.
|Deze mate van verrijking kom je volgens mij nergens anders tegen (@JBak, @Just_OSGeo of @jwva moet maar corrigeren als ik iets voer het hoofd zie).
Alleen kun je deze tabel niet tbv bulkbewerkingen downloaden, maar kun je 'm alleen via de API benaderen (wat @Tux wil doen). @korpem : Zou een download van deze tabel een optie zijn?
Aangezien “wij” de beheerder zijn van de BRP gegevens van de betreffende gementen is het verkrijgen van de informatie m.b.t. kiesgerechtigden hier niet het probleem. Die gegevens hebben we allemaal beschikbaar en we hebben zeer regelmatig overleg met de Kiesraad en het RvIG.
Omdat wijken en buurten (en waterschappen) (nog) geen onderdeel uitmaken van de geregistreerde gegevens op een persoonslijst, is dit “aanvullende” informatie die niet kan/mag leiden tot uitval van een kiezer
Deze extra informatie is vooral van belang voor de gemeente zelf bij het maken van stembureau-indelingen, rapportages en tellingen
Is het vraagstuk dan: "welke VBO’s | standplaatsen | ligplaatsen ligt in welk(e) buurt | wijk | waterschap? In dat geval zou ik aan de slag gaan met de BAG GeoPackage:
Met de adresgegevens van deze VBO’s | stand- | ligplaatsen kan vervolgens een koppeling worden gelegd met BRP gegevens.
