Trage filters in versie 4.0 van de BRK

Datasets BRK
1

Ter voorbereiding op een migratie naar versie 4.0 van de BRK ben ik al even aan het testen geslagen. De nieuwe indeling van de feature types en de verbeteringen in styling verheugen mij zeer. Het enige waar ik wel tegenaan loop is de veranderde filterfunctionaliteit.

Ik denk dat er grofweg twee vragen zijn waarvoor ik de BRK webservices inzet:

  1. Welk perceel ligt er tpv een coördinaat?
  2. Wat zijn de coördinaten van een perceel (op basis van kadastrale aanduiding)?

Nummer 1 werkt in versie 4 een goed als in versie 3. Er is alleen een andere filternotatie nodig.

Het beantwoorden van vraag 2 levert in mijn tests problemen op, de WFS is dan heel traag. Een verzoek op versie 3 ziet er bijvoorbeeld zo uit:

https://geodata.nationaalgeoregister.nl/kadastralekaartv3/ows?outputformat=application/json&request=GetFeature&service=WFS&typenames=kadastralekaartv3:perceel&version=2.0.0&cql_filter=kadastraleGemeenteCode = 'AMF00' AND sectie = 'E' AND perceelnummer = '8241'

Gewoonlijk duurt zo’n verzoek zo rond de 30 a 50 ms.

Op de nieuwe wfs met de nieuwe api krijg ik zo’n url:

https://geodata.nationaalgeoregister.nl/kadastralekaart/wfs/v4_0?outputformat=application/json&request=GetFeature&service=WFS&typenames=kadastralekaartv4:perceel&version=2.0.0&filter=<Filter><AND><PropertyIsEqualTo><PropertyName>AKRKadastraleGemeenteCodeWaarde</PropertyName><Literal>AMF00</Literal></PropertyIsEqualTo><PropertyIsEqualTo><PropertyName>sectie</PropertyName><Literal>E</Literal></PropertyIsEqualTo><PropertyIsEqualTo><PropertyName>perceelnummer</PropertyName><Literal>8241</Literal></PropertyIsEqualTo></AND></Filter>

Dit duurt echter heel lang, minimaal zo’n 1 minuut. Soms wel 2. Dat maakt zo’n request eigenlijk ontoepasbaar in een interactieve applicatie.

Mijn vraag nu is denk ik tweeledig:

  1. Is het uitvoeren van dit soort queries een ondersteunde use case?
  2. Zo ja, bestaat er vanuit het pdok de mogelijkheid om de performance van versie 4 voor dit soort verzoeken te verbeteren?
2

Beste Ynte,

Het uitvoeren van de specifieke query die je aangeeft, dus op AKRKadastraleGemeenteCodeWaarde, sectie en perceelnummer is een use case die we ondersteunen. Ik heb een index toegevoegd om je query te versnellen. Ik krijg de response nu in een paar milliseconden. Als je nog meer langzame filters hebt, dan hoor ik die graag. Wij kunnen dan de afweging maken of we hiervoor een index toevoegen.

3

Bedankt! De snelheid voelt nu weer vergelijkbaar met de vorige versie.

Volgens mij gebruik ik nergens andere filters, en kan ik de komende weken langzaam alle relevante producten updaten. :muscle:

4

Kan de index iets anders worden opgebouwd, dus perceelnummer+sectie+akrkadastralegemeentecodewaarde?
Dan kun je ook snel zoeken/filteren op perceelnummer zonder dat je sectie opgeeft.

5

De indexen zijn toegevoegd, morgen zullen deze geëffectueerd zijn.

6

De laatste dagen lijkt het alsof de indexen hun werk niet meer doen. Mijn testqueries doen er weer 50+ seconden over. Zien jullie dat all jullie kant ook? Of is er een sprake van een tijdelijke hiccup?

edit: Het lijkt weer over