BAG Extract v2: definitie van "actueel"

[Just_OSGeo]

Ik werk momenteel aan de verwerking van BAG Extract versie 2 in NLExtract. Daarbij maken we, net als voor versie 1, zogenaamde PostgreSQL/PostGIS VIEWs om wat we noemen “actueel” en “actueelbestaande” BAG objecten uit te filteren.

“actueel” in v1 was als volgt gedefinieerd op basis voorkomen-attributen:

begindatumtijdvakgeldigheid <= now()
AND (einddatumtijdvakgeldigheid is NULL OR einddatumtijdvakgeldigheid >= now())
AND aanduidingrecordinactief = FALSE;

In gewone taal: begindatum object is in verleden of nu EN einddatum in toekomst of leeg EN het object moet actief zijn.

In versie 2 zijn de “voorkomen” attributen behoorlijk uitgebreid, maar als ik het equivalent als hierboven “actueel” definieer, denk ik dat dit als volgt is:

 begingeldigheid <= now()
 AND (eindgeldigheid is NULL OR eindgeldigheid >= now())
 AND (tijdstipinactief is NULL OR tijdstipinactief >= now())

hetzelfde idee, alleen bestaat aanduidingrecordinactief als boolean niet meer. Ik vermoed dat dit tijdstipinactief (datum-tijd attribuut) is (?). De “geldigheid”-condities zijn als in versie 1 alleen moet tijdstipinactief leeg zijn of nu of in toekomst liggen. In feite zou (identificatie,begingeldigheid,eindgeldigheid,tijdstipinactief) een unieke sleutel moeten zijn.

Dan zijn er ook geen “meerdere objecten met zelfde identificatie”, de unieke set. Daarnaast op basis status kan vervolgens nog de Actueel & Bestaand uitgefilterd, maar dat is naast paar nieuwe statussen hetzelfde idee. Kom ik misschien apart op terug. Ik heb het “BAG Historie Model” PDF Document [1] doorgenomen, wel taaie kost, maar bovenstaande haalde ik daar ook uit.

[1] https://www.kadaster.nl/-/specificatie-bag-historiemodel

[nathalievosBAG]

Hallo Just,

Ter aanvulling op jouw definitie van een actueel voorkomen dient er ook gekeken te worden naar het tijdstip NietBAG.
Een tijdstipNietBAG wordt gegeven aan voorkomen dat door middel van een synchronisatie buiten de geldige levenscyclus is geplaatst. In de Praktijkhandleiding is uitgebreide toelichting over het ontstaan van NietBAG en Inactieve voorkomens opgenomen.

Zowel het tijdstip inactief als het tijdstip niet BAG kunnen overigens nooit in de toekomst liggen. Het gaat namelijk om het moment waarop een voorkomen inactief of Niet BAG is geworden. Je hoeft dus niet te kijken of dit tijdstip in de toekomst ligt. Als een voorkomen een tijdstip inactief of tijdstip Niet BAG heeft, ligt dat tijdstip altijd in het verleden en is het dus nooit actueel.

Het verschil tussen Inactief en NietBAG is wel dat bij Inactief er altijd een nieuw voorkomen met een nieuw voorkomenID wordt aangemaakt. Bij NietBAG hoeft dit niet.

Kortom de sleutels voor BAG 2.0 zijn dus:

1. BAG Identificatienummer (BAG ID)
2. Voorkomen identificatie
3. Tijdstip Niet BAG (als dan niet gevuld)

Met vriendelijke groet,

Nathalie Vos

[Just_OSGeo]

Bedankt Nathalie,

Na paar keer lezen, denk ik het te snappen. Het gaat in NLExtract BAG vooral om de conditie waarin je van “actueel” “huidige” geldige objecten kunt spreken. In SQL zou dat met jouw aanvulling deze condities zijn:

begingeldigheid <= now()
AND (eindgeldigheid is NULL OR eindgeldigheid >= now())
AND (tijdstipinactief is NULL)
AND (tijdstipnietbaglv is NULL)

Dus naast de begin/eindgeldigheid: als zowel tijdstipinactief en tijdstipnietbaglv niet ingevuld zijn, is het object actueel (en omgekeerd als minimaal een van de twee een waarde heeft, is object niet-actueel).

Ik zie dat er ook nog een attribuut tijdstipinactieflv is. Moet die niet ook meegenomen worden, of is die afgeleid van andere attributen?

Ter info: Daarnaast heeft NLExtract ook nog “actueelbestaand” filtering via Postgres VIEWs. Dat is naast “actueel” zoals hierboven met een object-type-specifieke “status” waarbij het object moet bestaan bijv ‘Pand in gebruik’ etc.

[nathalievosBAG]

Hallo Just,

Het tijdstipinactief is het moment waarop de bronhouder het voorkomen in de eigen applicatie inactief heeft gemaakt. Het tijdstipinactiefLV is het moment waarop het voorkomen in de LV BAG inactief is geworden.
Beide tijdstippen zijn bij een inactief voorkomen altijd gevuld. Het is voldoende om rekening te houden met een van de twee tijdstippen.
Aangezien er theoretisch gezien enige tijd kan zitten tussen het moment dat de bronhouder het voorkomen inactief maakt en het moment dat dit geregistreerd wordt in de LV BAG, zou mijn advies zijn om het tijdstipinactiefLV mee te nemen in de verwerking.

Met vriendelijke groet,

Nathalie Vos

[Just_OSGeo]

Dank weer Nathalie,

Heel formeel zou dan m.i. de “actuele” conditie zijn:

begingeldigheid <= now()
AND (eindgeldigheid is NULL OR eindgeldigheid > now())
AND (tijdstipinactief is NULL and tijdstipinactiefLV is NULL)
AND (tijdstipnietbaglv is NULL)

Naar mijn begrip is begin/eindgeldigheid een Datum (date) zonder tijdstip. Als er dan meerdere, zeg 3 en hoger, mutaties op een dag (datum) zijn hebben die m.i. dezelfde eindgeldigheid en soms begingeldigheid.
Of is daar weer de Voorkomen identificatie voor? Die is denk ik vnl bij mutatie-verwerking (komt later) van belang, niet voor onderwerp hier: “wat is actueel BAG object”?

voorkomenidentificatie en meer heb hier thread met @PieterDijkstraBAG over.

In NLExtract wordt op basis van bovenstaande tijdstip* condities in NLExtract een, intern, attribuut aanduidingrecordinactief gemaakt m.n. voor ‘forward compatibility’, om die in in VIEWs efficient te gebruiken. Voor wie wil reviewen de VIEWs SQL staat voorlopig hier.
Maar goed dat is applicatie-specifiek.

Ik ga even alle informatie verwerken, koffie helpt ;-), en hopelijk tot juiste ontwerp beslissingen komen.
Bedankt, geweldige support BAG-team!