BAGv2 changes

[Bas Couwenberg]

Bij het in gebruik nemen van BAGv2 in mijn NLExtract setup tbv
OpenStreetMap ben ik tegen de nodige issues aangelopen.

Voor de bulk van deze issues heb ik changes in mijn lokale working
copy, en initieel zijn deze ook omgezet in pull requests. Gezien de
weerstand tegen de gemeentelijke indeling changes welke ook in BAGv1
ondersteunt waren betwijfel ik hoeveel vraag er naar deze changes is
in de NLExtract community. Indien er mensen zijn die behoefte hebben
aan bepaalde changes kunnen deze alsnog naar GitHub gepushed worden.

De issues tot dusver:

* GDAL 3.4.0 is vereist, maar is niet breed beschikbaar. (#312)

In GDAL 3.3.0 & 3.4.0 zitten changes die vereist zijn voor het
ondersteunen van het BAG 2.0 Extract XML schema.

Mogelijk zijn meer changes vereist voor het ondersteunen van meerdere
geometrie types (VlakOfMultivlak, PuntOfVlak).

Het zou m.i. beter zijn om in stetl een BAG 2.0 Extract processor toe
te voegen zodat verwerking met oudere GDAL versies ook gewoon werkt.

* provincie_gemeente schema wijkt af van BAGv1 (#311)

Slechts een jaar wordt ondersteunt in de initiele BAGv2 implementatie,
een regression ten opzichte van BAGv1.

Fix beschikbaar in #319 maar Just in huiverig die changes te mergen.
Mogelijk omdat het impact heeft op zijn dataset verkoop business.

* Gebruik van public schema wordt niet ondersteunt (#316)

create-schema.sql maakt het schema opnieuw aan, hierdoor gaat de postgis
extensie verloren indien het public schema is geconfigureerd.

Gebruik van een non-default schema vereist search_path aanpassing voor
roles die gebruik maken van de betreffende database. E.g.:

ALTER ROLE <username>
IN DATABASE <database>
SET search_path TO <schema>, public;

Dit is niet gedocumenteerd.

* Vereist stetl changes welke nog niet zijn gereleased. (#317)

De ETL scripts werken out of the box alleen met de stetl module welke
via een git submodule is geinclude in the NLExtract repo.

Er is nog geen Stetl release met de changes vereist voor BAGv2.

* bin/stetl gebruikt python interpreter maar python3 zou gebruikt moeten worden.

bag-extract.sh voor BAGv1 checked of python bruikbaar is,
en probeert python3 indien dat niet zo is.

Deze logica onbreekt in stetl.sh voor BAGv2.

* stetl negeerd errors. (geopython/stetl#123)

Wanneer errors optreden in een chain worden deze ignored gaat de verwerking
gewoon verder.

Dit is problematisch omdat vervolgen stappen afhankelijk zijn van
succesvolle uitvoering van eerdere stappen.

* BAGv1 compatibilty is niet optioneel (#331)

finalize-tables.sql wordt standaard uitgevoerd om de tables aan te passen
zodat deze nagenoeg gelijk zijn als die voor BAGv1.

Het database schema voor BAGv1 was echter nagenoeg een 1-op-1 match met het
XML schema van de betreffende data.

De LVBAG driver in GDAL voor BAGv2 match ook nagenoeg 1-op-1 met het XML
schema voor de betreffende data.

In create-tables.sql worden een aantal tabellen niet aangemaakt en wordt
dit overgelaten aan ogr2ogr ivm performance overwegingen. Maar vervolgens
worden de kolommen in die tabellen wel aangepast in finalize-tables.sql.
Zoals geconstateerd in #331 vereist dit veel extra disk space wat niet
altijd aanwezig is (60 GB is niet voldoende).

M.i. moet het database schema voor BAGv2 met de default configuratie
nagenoeg gelijk zijn aan het XML schema, i.e. finalize-tables.sql wordt
optioneel.

* Geen levering_xml record in nlx_bag_info table (#332)

Voor BAGv1 werkt de content van Leveringsdocument-BAG-Extract.xml in de
database opgeslagen zodat die data ook beschikbaar is.

Voor BAGv2 wordt dit niet gedaan.

Om alle BAG 2.0 Extract data in de database beschikbaar te hebben moet dit
wel gedaan worden.

* Inactief, InOnderzoek, NietBag data wordt niet verwerkt.

Alleen de data voor de geldige levenscylus wordt ondersteunt door de LVBAG
driver (in GDAL 3.4.0).

De Inactief, InOnderzoek, en NietBag data wordt niet verwerkt. Deze data
zou ook in de database opgenomen moeten worden om alle BAG 2.0 Extract data
via de database beschikbaar te hebben.

BAGInput & BAGOuput classes zijn ontwikkeld welke alle data in
lvbag-extract-nl.zip verwerkt.

* Hardcoded bag_xsd_versie waarde in nlx_bag_info table (#333)

create-meta.sql insert het bag_xsd_versie record met hardcoded waarde.

De waarde uit Leveringsdocument-BAG-Extract.xml zou gebruikt moeten worden
zoals extract_datum dat al is.

* Stand datum wordt niet gebruikt voor actueel bepaling (#336)

Dit is een longstanding issue wat ook BAGv1 betreft.

Wanneer de data niet maandelijks geupdate worden of bij de overgang naar
een nieuw jaar kunnen issues optreden met de actueel VIEWs omdat de
actuele datum/tijd gebruikt wordt ipv de stand datum van de BAG data.

* Pand en Verblijfsobject coördinaten kunnen 3D zijn, database is 2D

Volgens 'Catalogus BAG 2018' sectie '3.3.1 Geometrie' kunnen Pand en
Verblijfsobject coördinaten 2D of 3D zijn. De geometrie is echter 2D
(of 0D voor Verblijfsobject).

De geometry types in de database zijn allen 2D, 3D coördinaten moeten
naar 2D converteerd worden.

* adres-tabel.sql gemarkeerd als obsolete, maar gebruikt door adres.sh

adres-table.sql is gemarkeerd als obsolete:

OBSOLETE: we gebruiken nu adres-plus2adres-tabel.sql

input_sql_address_tables in conf/adres.cfg (gebruikt via adres.sh)
gebruikt echter gewoon adres-table.sql.

Mvg,

Bas

--
Disclaimer: Any errors in spelling, tact, or fact are transmission errors.