BAGv2 geen identificatie voor woonplaats records (met GDAL 3.2.2)

[sebastic]

De records in de woonplaats tabel hebben geen waarde in de identificatie column waardoor deze niet gejoined kunnen worden met de gemeente_woonplaats tabel:

bagv2=# SELECT gid, identificatie, naam, status, geconstateerd, documentdatum, documentnummer, voorkomenidentificatie, begingeldigheid, eindgeldigheid, tijdstipregistratie, eindregistratie, tijdstipinactief, tijdstipregistratielv, tijdstipeindregistratielv, tijdstipinactieflv, tijdstipnietbaglv FROM woonplaats;
-[ RECORD 1 ]-------------+------------------------
gid                       | 1
identificatie             | 
naam                      | Doesburg
status                    | Woonplaats aangewezen
geconstateerd             | f
documentdatum             | 2009-01-20
documentnummer            | BRA/WPL20080001
voorkomenidentificatie    | 1
begingeldigheid           | 2009-01-20 00:00:00
eindgeldigheid            | 
tijdstipregistratie       | 2010-12-15 10:57:22
eindregistratie           | 
tijdstipinactief          | 
tijdstipregistratielv     | 2010-12-15 11:02:20.608
tijdstipeindregistratielv | 
tijdstipinactieflv        | 
tijdstipnietbaglv         | 

Bovenstaande is met de data in bagv2/etl/test/data/lv/BAGNLDL-15092020-small.zip en GDAL 3.2.2 op Debian bullseye.

In GDAL 3.3.0 zitten changes in de lvbag driver (https://github.com/OSGeo/gdal/pull/3324) waarmee wel identificatie waardes worden geladen, maar ook de column names worden aangepast:

bagv2=# SELECT gid, identificatie, woonplaatsnaam, woonplaatsstatus, geconstateerd, documentdatum, documentnummer, voorkomenidentificatie, begindatumtijdvakgeldigheid, einddatumtijdvakgeldigheid, tijdstipregistratie, eindregistratie, tijdstipinactief, tijdstipregistratielv, tijdstipeindregistratielv, tijdstipinactieflv, tijdstipnietbaglv FROM woonplaats;
-[ RECORD 1 ]---------------+------------------------
gid                         | 1
identificatie               | 2142
woonplaatsnaam              | Doesburg
woonplaatsstatus            | Woonplaats aangewezen
geconstateerd               | f
documentdatum               | 2009-01-20
documentnummer              | BRA/WPL20080001
voorkomenidentificatie      | 1
begindatumtijdvakgeldigheid | 2009-01-20 00:00:00
einddatumtijdvakgeldigheid  | 
tijdstipregistratie         | 2010-12-15 10:57:22
eindregistratie             | 
tijdstipinactief            | 
tijdstipregistratielv       | 2010-12-15 11:02:20.608
tijdstipeindregistratielv   | 
tijdstipinactieflv          | 
tijdstipnietbaglv           | 

Bovenstaande is met dezelfde test data en GDAL 3.3.3 op Debian unstable.

Zou de minimum versie in bagv2/etl/README.md niet naar 3.3.0 moeten?

In GDAL 3.4.0 zitten changes voor woonplaatsRef (num) en verkorteNaam (opr), mogelijk moet de geadviseerde GDAL versie daarom zelfs 3.4.0 zijn?

[fsteggink]

Ik ben het met je eens. Ik heb het gevoel dat de LV BAG driver te overhaast ontwikkeld is, gezien de vele fixes. Helaas moet wel steeds GDAL weer worden geupgrade, om gebruik te kunnen blijven maken van de meest recente wijzigingen.

[justb4]

@fsteggink @sebastic gedeeltelijk mee eens: de LVBAG Driver is ontwikkeld door Laixer uit Delft en voldoet voor hun toepassing (iets met Panden). De verdere ontwikkeling is ook aan de community, en/of gesponsorde ontwikkeling. Voor NLExtract is inderdaad de situatie niet ideaal:

• er is niet met alle BAG bijzonderheden bijv mutatieverwerking rekening gehouden
• het een behoorlijke tijd kost voordat fixes in standaard GDAL versies op OS-es beschikbaar komen.
• er nogal wat "omheen ge-(SQL)script" moet worden, hoewel tot nu toe geen custom Python code nodig is

Het alternatief was om BAGv2 als custom ETL met Python/Stetl te ontwikkelen. Dat kan nog steeds. Voor mij persoonlijk was dit de snelste weg, goede samenwerking o.a. meetings, met Laixer, en werkt de huidige versie via de "latest" Docker Image voldoende. Heb zelf 2 PRs gesubmit/merged naar GDAL. Dat bleek behoorlijk mee te vallen: zelfs zonder multi-platform compilatie-keten, alles via GH Workflows.

Dit is eigenlijk meer een discussie voor de NLExtract mailing lijst/Gitter. m.i. is het nodig om een PSC te formeren, om meer richting/structuur te geven voor NLExtract/BAGv2 evolutie en te stemmen voor architecturele wijzigingen.

[sebastic]

Laten we dit issue beperken tot welke GDAL versie (in de documentie) aangeraden wordt.

Met de recent opgedane kennis blijkt 3.2.2 niet meer te voldoen, daarom is de betreffende documentatie aangepast naar 3.4.0 (#335).

Omdat ik geen Docker infrastructuur op wil zetten tbv mijn gebruik van NLExtract, heb ik de betreffende changes in GDAL 3.4.0 in de Debian package in unstable opgenomen zodat dit nu al gebruikt kan worden tot de gdal transition (Debian Bug #998887) is afgerond. Ook heb ik een stable update van GDAL 3.2.2 Debian package voorbereid met de relevante changes in 3.3.0 & 3.4.0. Gebruikers van NLExtract op andere distributies zijn daarmee echter niet geholpen.

Verdere discussie wat BAGv2 support in NLExtract betreft is via de mailinglist of gitter inderdaad beter. Een PSC is denk ik nog niet nodig, de mensen die het werk in NLExtract uitvoeren bepalen de richting.

[fsteggink]

Een speciale update van GDAL 3.2.2. met de LV-BAG fixes is wel heel erg fijn. Geweldig! Voor mijn eigen verwerking ben ik laatst overgestapt naar Bullseye, maar ik liep tegen issues aan m.b.t. het gebruik van GDAL 3.3 op Bullseye, omdat er verschillende versies van libproj werden gebruikt, nl. één via GDAL zelf en één via libspatialite (zie https://github.com/OSGeo/gdal/issues/4731).