DKK download API dataset up-to-date houden

Datasets BRK
#1

Voor het downloaden van percelen maak ik gebruik van de PDOK DKK Download API
Nu heb ik netjes de werkwijze gevolgd voor het downloaden van de delta’s. Dus:

  1. Download van de beginstand zonder delta-id
  2. Download van een dag later met het nieuwe delta-id

Ik heb nu een dataset-inhoudelijke vraag. Ik zie dat ik op basis van het attribuut lokaalid de percelen met elkaar kan vergelijken. Ik kan alleen nergens uit de documentatie herleiden hoe ik nu zorg voor een up-to-date dataset in mijn eigen database. Moet ik bijvoorbeeld voor de delta’s een update statement doorvoeren van bestaande regels in mijn database op basis van het lokaalid, of is het de bedoeling om alle delta’s toe te voegen (insert). En indien dat laatste het geval is, hoe kan ik de meest actuele stand van zaken filteren?

Mijn doel is dus om dagelijks een landsdekkende kaart te kunnen tonen met de meest actuele stand van zaken (zonder een dagelijkse full-download te doen). Wie kan mij aan wat info helpen?

#2

@Terralytics Er staat documentatie over hoe je de mutatieleveringen kan verwerken op GitHub GitHub - PDOK/schemas-mutatielevering: XML-schema's van de generieke mutatielevering. Deze documentatie is algemeen en niet specifiek voor de DKK. Er zijn drie typen mutaties, een toevoeging, een wijziging en een verwijdering. De mutaties hebben een was-wordt formaat. Je kan de was opzoeken in de database en vervangen met de wordt. Het beste kan je hiervoor de id die in de was en wordt envelope zit gebruiken.Tot slot heeft een wijziging een was en een wordt een toevoeging alleen een wordt en een verwijdering alleen een was.

#3

Er is overigens ook nog een referentie implementatie op GitHub GitHub - PDOK/delta-download-ref-impl

#4

ALs toevoeging daarop: het ligt er aan wat je wilt. Wil je de geschiedenis bewaren, of wil je alleen de actuele stand van zaken in je database?

In het eerste geval moet je alle mutaties bewaren (en je tabel partitioneren), en word alles dus een insert. Vervolgens moet je wat slimme SQL bedenken om de actuele toestand op te vragen (even uit m’n hoofd vanuit BRK Levering: Einddatum is leeg, en de laatste Toestandsdatum - maar ik weet niet zeker of dat dezelfde attributen zijn in de DKK, en of ik daarmee volledig ben - dat zou ik even moeten nazoeken).

In het tweede geval moet je alle mutaties toepassen: Dus bij een toevoeging moet je een insert doen, bij een wijziging een update, en bij een verwijdering een delete.

1 like
#5

@sbjager in principe ben ik in 90% van de tijd op zoek naar een actuele status, maar waarbij ik soms ook de mogelijkheid heb om de historie op te vragen. Met andere woorden: de historie heb ik wel nodig. En ik zou dan een view kunnen maken met de filter die jij beschrijft.
Als ik het goed begrijp krijg ik met de Insert van alle delta’s na de initiële levering dus geen dubbele gegevens wanneer ik zou filteren op een lege einddatum (eindgeldigheid) en laatste toestandsdatum? Als ik het zo snel zie bij het beoordelen van één van de delta’s krijg ik alsnog een hoop dubbele percelen. Vreemd genoeg zijn soms ook echt alle attributen, inclusief de geometrie, volledig identiek.
Hieronder één voorbeeld van een perceel van de delta-levering met id 73223de1-9149-4f33-8c8c-9cfbc59ca5d7 (7 juni). In totaal komt dat specifieke perceel trouwens 6x voor in de levering.

namespace lokaalid versie begingeldigheid eindgeldigheid tijdstipregistratie eindregistratie historievolgnummer historiestatus kadgemeentecode kadgemeente sectie perceelnummer akrgemeentecode akrgemeente oppervlakte soortgrootte perceelnummerrotatie deltax deltay plaatsbepalingx plaatsbepalingy
NL.IMKAD.KadastraalObject 50740160770000 2022-06-07T17:42:49.000 2022-06-07T17:42:49.000 0 Geldig 683 Nijehaske K 1607 734 NEK00 253838 Voorlopig 0.0 0.0 0.0 185411.302 552647.379
NL.IMKAD.KadastraalObject 50740160770000 2022-06-07T17:42:49.000 2022-06-07T17:42:49.000 0 Geldig 683 Nijehaske K 1607 734 NEK00 253838 Voorlopig 0.0 0.0 0.0 185411.302 552647.379

Ik heb op dit punt dus geen idee welke regels/filters ik zou moeten hanteren om de juiste data op de kaart te kunnen tonen zonder dubbele records te creëren.
@hulstg , wellicht hebben de dubbele records te maken met de toevoeging, wijziging of verwijdering, maar dat kan ik uit de delta-download niet herleiden.

#6

Ja, dat zie ik ook met enige regelmaat. Ik vermoed dat er dan wel wijzigingen zijn geweest in de gerelateerde gegevens (dus de zakelijke rechten, tenaamstellingen, aantekeningen, stukken enzovoorts).

Dat is wel een vervelend probleem in dit geval.