Kan iemand me uitleggen wat de betekenis is van het attribuut identificatieLokaalID voor percelen in BRK-DKK? Is deze waarde op een of andere manier gekoppeld aan de perceelcode (gemeente+sectie+nummer, zoals SLU00 I 02250)? Het lijkt in elk geval alsof het perceelnummer ook altijd terugkomt in LokaalID, 3680225070000
Ik kan hier nergens informatie over vinden.
Ik denk ook niet dat die er is, tenzij je in de documentatie van de BRK gaat graven. Maar anyway: de combinatie van identificatieNamespace en identificatieLokaalID is, voor zover ik kan zien, de unieke BRKId zoals je die ook tegenkomt in bijvoorbeeld de BRK Leverings producten. Oftewel: dat is de unieke identifier van dat object. In jouw geval dus NL.IMKAD.KadastraalObject.3680225070000, en dat is de unieke ID waarmee bijvoorbeeld de Zakelijke Rechten aan dat object worden gekoppeld.
Hoe dat nummer opgebouwd en/of samengesteld word weet ik niet, en doet er ook niet zoveel toe lijkt mij: het is de unieke identifier, en kan dus van alles zijn (een tellertje bijvoorbeeld). Misschien dat iemand van het Kadaster je daar antwoord op kan geven, maar de vraag die ik dan direct heb is: waarom heb je dat nodig (behalve nieuwsgierigheid - daarom zou ik het willen weten ;-))
De reden is dat ik probeer de ArcGIS service te bevragen op perceelcode. Deze drie velden zijn echter niet geĆÆndexeerd, waardoor de query behoorlijk traag is. Lokaal ID is daar wel geĆÆndexeerd, maar die waarde heb ik zelf niet.
Ik heb wel alternatieven (WFS bevragen is wel snel, Lokale IDās eenmalig van tevoren ophalen voor enkele tienduizenden percelen zou kunnen, ā¦) maar dat maakt mijn proces wat omslachtiger. Ook wil ik dan wel zeker weten of die lokale IDās inderdaad uniek zijn, hoewel het daar wel alle schijn van heeft.
Ter info, er wordt gekeken naar toevoegen van extra indexes.
Joris, dank voor de aanvulling, het zou mooi zijn als dat kon worden toegevoegd.
Waarom niet direct de WFS bevragen op gemeente, secrtie, perceelnummer? Ik neem althans aan dat dat is wat je bedoelt met āperceelcodeā? Dan heb je in 1 keer alles te pakken. Aan de andere kant: je praat over tienduizenden percelen. Voor een database is dat peanuts, voor een WFS een beetje veel - dus waarom de DKK niet downloaden?
Zo een paar dingen die bij mij op komen, maar ik weet niet wat je wilt bereiken, dusā¦
Nee, die ZIJN landelijk uniek, dat weet ik zeker. Als dat niet zo zou zijn, dan zou ik een heel groot probleem hebben 
Begrijp ik goed dat er geen index zit op gemeentecode, sectie, perceelnummer in jullie service? Dat verbaast me niet een klein beetjeā¦
Edit: kwam net bij me op, dat ik twee indexen zou maken. 1 op (kadastrale) gemeentenaam-sectie-perceelnummer, en 1 op (kadastrale) gemeentecode-sectie-perceelnummer. Want dat zijn de combiās die gebruikt worden om kadastrale percelen op te zoeken.
Om percelen te zoeken is meest snelle service om een daarvoor geoptimaliseerde āgeocoderā te gebruiken. Want ook al voeg je indexes toe, hoe snel je het ook maaktā¦ er is altijd wel een nog interessantere query te verzinnen die impact heeft op de database. Dus hoe meer je faciliteert, hoe groter je het probleem ook in theorie kan maken. Bijvoorbeeld een upper like query met een stukje van de zoekwaarde ipv het hele perceelnummer (ja gebeurt echt, en veel). Ik kan je meenemen in details die we daarvoor implementeren, maar niet alles is oplosbaar met een index. Voor het realiseren van een zoekfunctie is advies dus iets anders te gebruiken dan de service die meer gericht is op visualisatie. Neemt niet weg dat indexen toegevoegd gaan worden, maar mijn nuance blijft dat er verschillende services zijn voor verschillende doeleinden. Daar kunnen mensen van PDOK vast over meepraten of performance impact op databases voor (suggest) bevragingen die ook op een zoekfunctie (zoals locatieserver) uitgevoerd kunnen worden. Neemt niet weg dat @bveldkamp iets anders probeert te doen en daarvoor kunnen de indexen wel bijdragen.
@sbjager Ik zit al in een ArcGIS omgeving, dus is het voor mij veel handiger om ook een ArcGIS service te bevragen. Ten eerste omdat ik dan geen WFS filter hoef te bouwen, en ten tweede hoef ik de gml response dan niet te parsen. Dus wat ik al zei, er zijn alternatieven, maar het wordt omslachtiger.
@JBak Ik heb gekeken naar de DKK geocoder van Esri, maar dan kan je maar 1 perceel tegelijk bevragen, en het resultaat bevat alleen een punt locatie, niet de volledige perceelgeometrie.