LV BAG Extract: Inactief, NietBag en InOnderzoek zip bestanden

Datasets BAG
#1

Gerelateerd aan mijn vraag over “wat is een actueel BAG object”.

Het viel mij op dat in de reguliere object zipfiles bijv 9999PND<datum>.zip nooit een waarde voor tijdstipinactief, tijdstipnietbaglv of tijdstipinactiefLV voorkomt. Nu zijn er ook aparte zipfiles, Inactief, NietBag en InOnderzoek. Ok, dan zullen inactieve objecten daar in geleverd worden.

Is dat een belangrijk verschil met BAG v1 waar aanduidingrecordinactief wel in de reguliere object .zip files geleverd werd? En hebben reeds in v1-bestaande aanduidingrecordinactief objecten in v2 een tijdstipinactief gekregen?

De meeste toepassingen zullen ook niet in de inactieve objecten geinteresseerd zijn. Maar moeten we die voor volledige verwerking (in NLExtract) toch meenemen? Ik kan mij voorstellen als je een stand van bepaalde datum wil terughalen uit een verwerkt extract (bijv met Postgres VIEWS) dat je daarin objecten wil die op die datum actief waren (en kunnen dus op latere datum inactief zijn geworden).

9999STA08022022 - Ontbrekende gegevens in de BAG source
#2

Hallo Just,

Je hebt het goed gezien. In BAG 1.0 werd uitsluitend een aanduidingrecordinactief geleverd. Deze werden inderdaad in de reguliere object.zip geleverd. De aanduiding maakte alleen duidelijk dat een object inactief was, maar het was niet duidelijk op welk moment dat is gebeurd. Dat maakt de reconstructie van de historie lastiger. Daarom leveren we de indicatie in BAG 2.0 als een tijdstip. Een aanduidingrecordinactief kan in BAG 2.0 zowel een een tijdstipNIetBAGLV als een TijdstipinactiefLV zijn. Dat hangt af van de manier waarop een voorkomen buiten de geldige levenscyclus is geplaatst.

Het tijdstipNietBAGLV wordt gevuld als een gemeente aangeeft dat een eerder opgevoerd voorkomen in de LV BAG (toch) geen onderdeel uitmaakt van de gemeentelijke registratie.
Het tijdstipInactiefLV wordt gevuld als een voorkomen met een begindatum in de toekomst inactief wordt gemaakt, waardoor het nooit geldig zal worden.

Dit onderscheid was in BAG 1.0 niet zichtbaar in het extract. Beide situaties leidden tot een aanduidingrecordinactief.

Zoals je zelf aangeeft zijn voorkomens met een tijdstipNietBAGLV of een TijdstipInactief LV voor de meeste toepassingen niet relevant. Door deze voorkomens in aparte zips te leveren, kun je deze nu veel makkerlijker negeren.

Het klopt inderdaad ook als je op elk moment in de tijd wilt weten wat het geldige voorkomen was, je deze voorkomens wel nodig hebt. Een voorkomen met een tijdstipNietBAG of een tijstipInactief, maakte tot dit tijdstip deel uit van de geldige levenscyclus van het object.

1 like
#3

Bedankt @PieterDijkstraBAG ! Duidelijk dat als je wilt inlezen met behoud historie ook de “niet actuele” bestanden moet inlezen. Komen die 3 bestanden (Inactief, NietBag en InOnderzoek) dus overeen met de 3 attributen tijdstipinactief, tijdstipnietbaglv of tijdstipinactiefLV ?

Begrijp dit deel nog niet helemaal: je noemt “aanduidingrecordinactief kan in BAG 2.0 zowel een een tijdstipNIetBAGLV als een TijdstipinactiefLV zijn.” Je bedoelt een fictieve aanduidingrecordinactief ? Want bij mijn weten komt aanduidingrecordinactief niet in BAG v2 voor (alleen in BAG v1). Of bedoel je het BAG v2 attribuut tijdstipinactief?

Zijn nogal wat vragen van mij. Zullen anderen in toekomst ook tegenaan lopen. Dan handig als deze dan zoek/vindbaar zijn via geoforum.nl!
NLExtract lijkt echter op dit moment de enige Open Source tool die de BAG v2 “kan kraken” (?). Komt nu op deze details aan.

#4

Ik bedoelde aan te geven hoe het BAG 1.0 gegeven ‘AanduidingRecordinactief’ wordt geleverd in BAG 2.0 data.

In het BAG 1.0 extract is er geen onderscheid tussen een inactief voorkomen en een voorkomen met een tijdstip NietBAG. Deze worden in BAG 1.0 met aanduidingrecordinactief = ‘J’ geleverd. In BAG 1.0 weet je dus niet of het een inactief voorkomen is of een Niet BAG voorkomen. Dit is wel opgeslagen in de BAG 1.0 database.

Een voorkomen dat in BAG 1.0 aanduidingrecordinactief ‘J’ heeft, krijgt in BAG 2.0 dus een tijdstip inactief of een tijdstip Niet BAG (en heel soms allebei, dan leveren we het voorkomen in de NietBAG zip). Inactief en NietBAG bevatten samen dus alle voorkomens waarde de aanduidingrecordinactief in BAG 1.0 ‘J’ was. Uiteraard staan voorkomens die in BAG 2.0 inactief of NietBAG zijn geworden ook in deze mappen.

De InOnderzoek map staat hier helemaal los van. Inonderzoek was in BAG 1.0 een gegeven van een object. Een voorkomen van een object kon in zijn geheel in onderzoek staan. Het in onderzoek zetten van een object leverde in BAG 1.0 ook altijd een nieuw voorkomen op. In BAG 2.0 is Inonderzoek geen gegeven meer van een object.

In BAG 2.0 is in onderzoek een metagegeven bij een gegeven van een object. Per gegeven van een object is er een eigen tijdlijn met een verwijzing naar het object waarop het onderzoek betrekking heeft. Er kan bijvoorbeeld sprake zijn van een onderzoek naar het bouwjaar van een pand. De historie van het onderzoek staat los van de tijdlijn van het object zelf. Het in onderzoek zetten van een gegeven, levert dus ook geen mutatie van het object zelf op. Alleen als uit het onderzoek blijkt dat het gegeven aangepast moet worden, zie je dit terug in de historie van het object zelf.

Omdat de levenscyclus van het object en de levenscyclus van het onderzoek naast elkaar bestaan en geen invloed hebben op elkaar leveren we InOnderzoek ook in een aparte map. Afnemers die het niet relevant vinden dat een gegeven in onderzoek staat (mogelijk onjuist is) kunnen deze map makkelijk negeren.

#5

Bedankt @PieterDijkstraBAG ! Nu helder zo.