Koppeling tabel BRK-BAG via Data Labs Kadaster

Datasets BRK
#1

Goedemorgen,

Onderstaande vraag heb ik eerder hier gepost Op zoek naar de koppeling tussen BRK en BAG - #11 door jhpoosthoek - BRK - Geoforum. Het gaat om een koppeling tabel tussen BRK en BAG. Na heen en weer gemail kwam ik uit bij Koppeling BRK/BAG - Data Science Team (DST) - Kadaster Triple Store . Het lukt mij via Python de data te downloaden, een totaal van 8786223 koppelingen. Als ik deze data vervolgens koppel aan de percelen uit de BRK kom ik echter veel percelen tegen zonder koppeling terwijl weergave in QGIS laat zien dat er een BAG pand en adres aanwezig is. Een voorbeeld is perceel (lokaal) ID 29340221970000. In QGIS heeft dit perceel een BAG pand met bouwjaar 1919 en drie adressen (eentje heeft nummeraanduiding 0344200000126891). Nu is dus mijn vraag waarom hier en voor vele andere percelen de koppeling niet gelukt is?

Hartelijke groet,

Jelmer Oosthoek
Ps. richting geoforum.nl: het zou handig zijn om meerdere datasets te kunnen selecteren, nu kon ik alleen BAG Ăłf BRK selecteren.

#2

Hi Jelmer,

Ik was destijds de aanstichter van de ontwikkeling achter het (wederom) beschikbaar stellen van de desbetreffende dataset. Bij toeval zie ik nu je bericht. Omdat ik zelf niet langer werkzaam ben voor het Kadaster kan ik je hier echter niet meer van een zinnig antwoord voorzien. Ik heb wel de huidige beheerders van de koppeling geattendeerd op dit bericht. Ik vermoed dat zij hier wel op terug zullen komen.

Groeten,

Rob

1 like
#3

Hmmm. Da’s een rare
 de locatieserver heeft aan dat adres vier percelen gekoppeld: ZLN02-C-2217, ZLN02-C-2218, ZLN02-C-2219 en ZLN02-C-2220. lokaalID 29340221970000 is 2219, maar da’s niet de eerste in het lijstje van lokatieserver. Ik zie ook geen enkele reden waarom dat adres die 4 percelen gekoppeld zou moeten hebben, tenzij het 1 enkel WOZ-object is of zoiets. Dus dit:

verbaast me eigenlijk niets
 Ik zie uit de locatieserver wel vaker onbegrijpelijke adres-perceel koppelingen komen, dus dat ze er af en toe ook niet zijn vind ik niet zo gek - als het de ene kant op fout gaat, dan gaat het ook de andere kant op wel eens mis.

Heeft er bij mij toe geleid dat ik de relatie tussen percelen en panden alleen nog ruimtelijk bepaal, en niet meer vertrouw op administratieve koppelingen. Hoewel dat ook weer leuk word als het pand op twee of meer percelen staat (die ben ik ook al vaker tegen gekomen :smiley: )

1 like
#4

Hoi Jelmer, excuses voor de wat latere reactie. We zijn het binnen ons team bij het Kadaster aan het uitzoeken. Ik kom uiterlijk begin volgende week bij je terug met een reactie

1 like
#5

Dank Bob, Rob en Stefan voor jullie antwoorden.

Ik zie verschillende (wellicht te combineren) mogelijkheden om een goede koppeling voor elkaar te krijgen. Allereerst, wellicht als basis de Kadaster Data Labs koppeling (hopelijk wordt deze uitgebreid). Vervolgens ben ik benieuwd of het mogelijk zou zijn om de koppeling tabel gebruikt voor de PDOK locatieserver te ontvangen? En daarnaast zou ik zoals Stefan noemt een geografische analyse kunnen doen (die ik vanwege een pand op meerdere percelen hoopte te vermijden :wink: al zou ik alleen naar adressen kunnen kijken (bijv. de adres_plus tabel uit NLExtract BAG)).

Maar als de koppeling toch volledig via Kadaster Data Labs gedownload zou kunnen worden zou natuurlijk het mooist zijn! Zodoende, Bob ik hoor graag van je terug!

Hartelijke groet,

Jelmer

#6

Hoi Jelmer,

Excuus dat een antwoord wat langer duurde. Eerst even wat context: Rob (in het verleden), Bob en ikzelf zijn allen actief in het Data Science Team; we doen data gedreven (tijdelijke) experimenten in het Data Science Team, en 1 zo’n project is de Knowledge Graph. De knowledge graph heeft de intentie om een productie-dienst te worden, maar is dat op dit moment nog niet. Dat betekent eigenlijk dat we er maar zeer beperkt support op kunnen leveren. Daarnaast is je vraag ook specifiek in de inhoud van de datasets, en dan moeten we al snel doorverwijzen naar de inhoudelijke experts van de betreffende datasets. Maar in dit geval is dat ook lastig. In de knowledge graph maken we enerzijds gebruik van de officiĂ«le dataset producten van Kadaster (BAG, BRT, BRK-DKK, BGT), en daarnaast ook koppeltabellen die geen formele Kadaster producten zijn, maar noodzakelijk zijn voor integrale bevragingen. Inhoudelijke support wordt alleen geleverd op de officiĂ«le producten, daar wordt ook de kwaliteit van gemonitord, etc
 De koppeltabellen hebben geen status.

Maar goed, natuurlijk hebben we wel even gekeken, en dan lijkt het een complexe situatie te zijn waarvoor de koppeling niet gelegd is.

Een oplossing voor de korte termijn zou kunnen zijn om de relatie geometrisch te leggen zoals Sbjager al aangeeft, maar dat kent ook wel weer issues. Ik denk dat de meeste gebruikers dat nu doen. Voor de lange termijn hoop ik dat we de (geo) datasets echt integraal kunnen aanbieden, dus met sleutels
(en uiteraard in een hoge kwaliteit). Maar zover zijn we helaas nog niet.

Groeten Erwin

1 like
#7

Dank @erwinfolmer voor je reactie en check. Volgende stap is inderdaad dmv geometrie koppelen zoals @sbjager aangaf. Alleen vroeg ik mij af, de koppeling doet het wel in de locatieserver, bijvoorbeeld
https://geodata.nationaalgeoregister.nl/locatieserver/v3/free?q=gekoppeld_perceel:ZLN02-C-2219. Is het mogelijk daar de achterliggende koppeltabel van te ontvangen? @wouter.visscher (ik zie op GitHub - PDOK/locatieserver dat jij betrokken bent bij de locatieserver) kun je me misschien verder helpen?

#8

Maar daar zitten wel vreemde links tussen, zoals ik eerder al aangaf. Ik weet niet hoe die koppeling tot stand is gekomen (voor zover ik weet is daar geen beschrijving van), maar daar zit meer achter dan puur “op welk perceel ligt dit pand”. Het antwoord op die vraag beantwoord ik altijd ruimtelijk, in sommige gevallen via de pand-geometrie, soms een punt in het pand, soms de vbo (is afhankelijk van de onderliggende informatievraag).

1 like
#9

Hoi @jhpoosthoek zoals de richting van dit topic je doet vermoeden, is dat (helaas) allemaal niet zo eenvoudig.

De BRK-BAG koppeling die wij gebruiken voor de locatieserver is een intern "product’ van Kadaster wat voor ons (PDOK) ook een blackbox is in hoe deze wordt opgebouwd (combinatie van spatial/administratief). Zoals @sbjager al aangaf zitten hier “vreemde links tussen”, de koppeltabel is voor 90-95% (?) gevuld/gekoppeld en dat is dan ook het probleem. Kort door de bocht de kwaliteit te laag om dit als “volwassen” product aan te bieden.

Dat we het wel gebruiken voor de locatieserver is:

  1. Dat een PDOK geen ‘data producerent team is’ (wat de BAG en/of BRK wel is), dus een stukje “separation of concerns”.
  2. Voor de locatieserver is doel om van tekst naar een locatie te gaan, waar bij je kan afvragen hoe precies/exact die locatie moet zijn. (Natuurlijk is nauwkeuriger beter/fijner)

Samengevat is de BRK-BAG koppeling, en hoe deze is opgenomen in de locatieserver, is op basis van best-effort.

1 like
#10

Als aanvulling op de reactie van Wouter;
Als Kadaster maken we de koppeltabel BRK-BAG uitsluitend voor de locatieserver. Van onze aanbieders krijgen wij de BAG-koppeling niet meegeleverd met de aktes. O.b.v. adres of geometrie legt het Kadaster achteraf geautomatiseerd koppelingen met kadastrale percelen. Dit is met name in het geval van appartementsadressen niet zuiver uit te voeren waardoor we de kwaliteit (nog) niet voldoende vinden om dit als product aan de markt aan te bieden.

3 likes
#11

Waar ik dan vreselijk nieuwsgierig naar ben, is waar die meerdere percelen per adres vandaan komen

Met name het lijstje percelen dat bij adres 0344200000126891 terug komt (zie mijn eerdere post in dit draadje), en waar komt bij adres 1696200000078826 (Noordereinde 60, 's-Graveland) vandaan dat perceel GVL00-A-1202 daar ook bij hoort? Daar zit voor mij althans geen zichtbare reden achter - en als die reden er wel is, dan zou ik ook de percelen 298, 299, 300, 301 en 302 (zelfde gemeente/sectie) er bij verwachten (dan heb je het hele landgoed namelijk te pakken in dit geval - dan zie ik nog een reden). Maar bijvoorbeeld bij Noordereinde 60 is de ruimtelijke relatie tussen perceel 1202 en pand Disjoint


1 like
#12

Dank voor alle antwoorden! Ik ga het probleem nu allereerst geometrisch aanpakken.