Ontbrekende mutaties?

[BartAtWork]

Ik zie vast iets over het hoofd, dus laat ik de experts maar om raad vragen

We zijn bezig met het verwerken van BAG data.

Het complete extract van 2024-03-08 is ingeladen in een database.

Ik download dagelijks automatisch de mutatiebestanden en werk de database bij.

Nu wil ik graag de stand op een datum bepalen. Ik kom nu meerdere Voorkomens tegen van dezelfde identificatie zonder einddatum.

Een voorbeeld is Verblijfsobject ID: 0398010000007540

BAG Viewer

In het extract zijn Voorkomens 1 t/m 4 aanwezig. 4 heeft beginGeldigheid 2023-01-31 en geen eindGeldigheid.

Nu worden de mutaties verwerkt.

In bestand “9999MUT19032024-20032024-000002.xml” staan de volgende mutaties voor dit verblijfsobject

was/wordt voorkomen 4: eindGeldigheid wordt 2024-03-18
toevoeging voorkomen 5: beginGeldigheid 2024-03-18 en geen eindGeldigheid

In het volgende mutatiebestand “9999MUT20032024-21032024-000002.xml” staan de volgende mutaties voor dit verblijfsobject

was/wordt voorkomen 6: beginGeldigheid 2024-03-18, eindGeldigheid wordt 2024-03-20
toevoeging voorkomen 7: beginGeldigheid 2024-03-20

Volgens mij mis ik een mutatiegroep met was/wordt voorkomen 5 (eindGeldigheid wordt 2024-03-18) en toevoeging van voorkomen 6

[Just_OSGeo]

Ik zie hier op zich niets vreemds aan. Wat ik weet is dat je de mutatie-bestanden op datum en volgnummer moet sorteren. Er wordt nooit iets uit de BAG weggegooid. In de tijdspanne tussen begin-eind geldigheid gelden de waarden van de overige attributen. De huidige/actuele toestand heeft dan alleen een beginGeldigheid (heel soms een eindGeldigheid in de toekomst). Wanneer er iets moet veranderen wordt eerst die toestand “afgesloten”, bijv voorkomen 5, met een eindGeldigheid bijv in voorkomen 6. Die 2024-03-20 is dan ook meteen de beginGeldigheid in voorkomen 7. Zodoende zitten er ook geen “gaten” in de levens-tijdlijn van het object.

Maar ik ben niet van de BAG-groep Kadaster, die weten er veeel meer van.
Heb ooit in BAG v1 mutaties ontwikkeld in NLExtract. Er ligt een PR voor mutaties in v2, maar we missen een extra reviewer.

Misschien kun je de software vermelden die jullie gebruiken?

[BartAtWork]

We gebruiken geen bestaande software, dit is een eigen dotnet project.

Logisch gezien begrijp ik dat het nieuwe vookomen het vorige record afsluit. Ik had alleen óók een mutatie verwacht dat 5 een eindGeldigheid krijgt en een toevoeging van vookomen 6.
Nu krijgen we alleen een mutatie door van voorkomen 6 en een toevoeging van voorkomen 7. (Dus een mutatie van voorkomen 6 dat bij ons nog niet bekend was)

Ik heb ondertussen nog een ander voorbeeld gevonden.

Verblijfsobject ID: 0717010000006635

BAG Viewer

In het extract heeft deze als laatste voorkomen volgnummer 4. Status “Verbouwing verblijfsobject” met een beginGeldigheid 2023-04-06 en geen eindGeldigheid.

In de mutatiebestanden vanaf het extract kom ik dit verblijfsobject pas weer tegen in “9999MUT26032024-27032024-000002” (mutataties van 26 maart, geleverd op 27 maart)

Hier krijgen we een mutatie door van voorkomen 5 (eindGeldigheid wordt 2024-03-26) en een toevoeging van voorkomen 6. Voorkomen 5 hebben we nooit eerder doorgekregen. In de Historie in de BAG Viewer en in de XML blijkt dat voorkomen 5 op 2024-03-19 geregistreerd is.

Ik had in bestand “9999MUT19032024-20032024-000002.xml” een mutatie verwacht waarin voorkomen 4 een eindGeldigheid van 2024-03-19 zou krijgen en het toevoegen van voorkomen 5 met een beginGeldigheid 2024-03-19 en nog geen eindGeldigheid. Status “Verblijfsobject in gebruik (niet ingemeten)”

Op (bijvoorbeeld) 22 maart zou de bij ons bekende status (Verbouwing verblijfsobject, uit voorkomen 4) anders zijn dan bij BAG, omdat we de statuswijziging nog niet hebben gehad.

[nathalievosBAG]

Hallo Bart,

Zo te lezen ben je al helemaal op de hoogte van de werking van het BAG Extract en het verwerken van de mutaties.

In de levering van 20 maart (met de mutaties van 19 tot 20 maart) zitten er 3 xml bestanden. Het eerste bestand bevat altijd metadata over de levering en de daaropvolgende bestanden bevatten de data.

De mutaties van beide voorbeelden zitten in het bestand “9999MUT19032024-20032024-000003.xml”. Ik vermoed dat er iets is mis gegaan met het verwerken van het derde xml bestand.

Ik denk dat je hiermee het issue op kunt lossen. Laat het vooral weten als dit niet zo blijkt te zijn of als je nog vragen hebt.

[BartAtWork]

Ik ga me in een hoekje zitten schamen

Ik zag dus inderdaad iets over het hoofd. Meerdere mutatiebestanden.

Hartelijk dank voor de hulp allebei!