NLExtract 1.5.2 is released - met BAG v2.0 naar PostGIS!
126 views
Skip to first unread message
Just van den Broecke
Apr 2, 2021, 7:19:02 AM4/2/21
to nlextract
NLExtract 1.5.2 is released - met BAG v2.0 naar PostGIS!
Zie ook:
https://geoforum.nl/t/nlextract-1-5-2-released-met-bag-v2-0-naar-postgis/5681
Met vriendelijke groet,
--Just
Zie ook:
https://geoforum.nl/t/nlextract-1-5-2-released-met-bag-v2-0-naar-postgis/5681
Met vriendelijke groet,
--Just
Bas Couwenberg
Apr 2, 2021, 2:28:21 PM4/2/21
to nlex...@googlegroups.com
Wordt BAG v2.0 niet geleverd met een gemeente-woonplaats koppeling?
En zo nee, is dat geen verrijking die in het domein van NLExtract ligt?
"No custom Python code! " impliceerd ook geen gemeentelijke indeling
voor de gemeente-provincie koppeling.
Mvg,
Bas
> --
> --
> Dit is een bericht van de Google Groups "nlextract" group.
> Home pagina: http://www.nlextract.nl
> Groep mailen: nlex...@googlegroups.com
> Afmelden: nlextract+...@googlegroups.com
> Meer opties: http://groups.google.com/group/nlextract?hl=en
>
> ---
> Je hebt dit bericht ontvangen, omdat je je hebt aangemeld bij de groep 'nlextract' van Google Groepen.
> Als je je wilt afmelden bij deze groep en geen e-mails van de groep meer wilt ontvangen, stuur je een e-mail naar nlextract+...@googlegroups.com.
> Ga naar https://groups.google.com/d/msgid/nlextract/72337db0-0bd0-ddae-626d-74ea0a1e14be%40justobjects.nl om deze discussie op het internet te bekijken.
--
Disclaimer: Any errors in spelling, tact, or fact are transmission errors.
En zo nee, is dat geen verrijking die in het domein van NLExtract ligt?
"No custom Python code! " impliceerd ook geen gemeentelijke indeling
voor de gemeente-provincie koppeling.
Mvg,
Bas
> --
> Dit is een bericht van de Google Groups "nlextract" group.
> Home pagina: http://www.nlextract.nl
> Groep mailen: nlex...@googlegroups.com
> Afmelden: nlextract+...@googlegroups.com
> Meer opties: http://groups.google.com/group/nlextract?hl=en
>
> ---
> Je hebt dit bericht ontvangen, omdat je je hebt aangemeld bij de groep 'nlextract' van Google Groepen.
> Als je je wilt afmelden bij deze groep en geen e-mails van de groep meer wilt ontvangen, stuur je een e-mail naar nlextract+...@googlegroups.com.
> Ga naar https://groups.google.com/d/msgid/nlextract/72337db0-0bd0-ddae-626d-74ea0a1e14be%40justobjects.nl om deze discussie op het internet te bekijken.
--
Disclaimer: Any errors in spelling, tact, or fact are transmission errors.
Bas Couwenberg
Apr 2, 2021, 2:34:22 PM4/2/21
to nlex...@googlegroups.com
On Fri, Apr 2, 2021 at 8:28 PM Bas Couwenberg <linux...@gmail.com> wrote:
> Wordt BAG v2.0 niet geleverd met een gemeente-woonplaats koppeling?
>
> En zo nee, is dat geen verrijking die in het domein van NLExtract ligt?
>
> "No custom Python code! " impliceerd ook geen gemeentelijke indeling
> voor de gemeente-provincie koppeling.
https://github.com/nlextract/NLExtract/tree/1.5.2/bagv2/etl/data/cbs/gemeente
> Wordt BAG v2.0 niet geleverd met een gemeente-woonplaats koppeling?
>
> En zo nee, is dat geen verrijking die in het domein van NLExtract ligt?
>
> "No custom Python code! " impliceerd ook geen gemeentelijke indeling
> voor de gemeente-provincie koppeling.
2019 lijkt de oudste data te zijn voor BAG v2.0.
Voor BAG v1.0 bevat gemeentelijke-indeling.xml de data vanaf 1990.
https://github.com/nlextract/NLExtract/blob/1.5.2/bag/db/data/gemeentelijke-indeling.xml
Waarom wordt dat niet ook voor BAG v2.0 gebruikt?
Bevat BAG v2.0 ook zo'n beperkte historie dat oudere
gemeentelijke-indeling data niet relevant is?
Mvg,
Bas
Just van den Broecke
Apr 2, 2021, 3:34:35 PM4/2/21
to nlex...@googlegroups.com
Beste Bas,
Bedankt voor (eerste) inhoudelijke feedback!
Ik had via NLExtract Gitter en andere fora een oproep gedaan aan
ontwikkelaars om mee te denken/doen in NLExtract BAG 2.0 ontwikkeling.
Ik kan mij voorstellen (heb ik zelf weer met andere FOSS-projecten) dat
velen te druk zijn. Maakt niet uit.
Voordeel is dat ik snel ontwerp-beslissingen kon/moest nemen...
Je vraag: de BAG 2.0 wordt zoveel mogelijk forward compatible met BAG
1.0 verwerkt. Waaronder dus de gemeente-woonplaats koppeling en de
verrijking met CBS gemeente-provincie gegevens. "No custom Python code!
" is meer dat bovenstaande geheel geschiedt via Stetl configuraties, dus
reeds bestaande Stetl (Python) code. De uiteindelijke database-structuur
heeft een bijna 1-1 structuur met BAG v1. Bijv de adres-tabellen zijn
ongewijzigd.
Voor de gemeente-woonplaats koppeling moet je kijken in deze regel van
de Stetl config [1]. In kort: via een Stetl standaard GDAL '/vsizip' pad
wordt Gemeente-Woonplaats XML zonder uitpakken, uit de BAG .zip
geextraheerd en omgezet met een XSL script [2] , gebruikmakend van GDAL
GFS [3], in een Postgres tabel. Dus zoveel mogelijk de bestaande tools
(Stetl, GDAL, XSLT via libxsl) laten werken.
Mocht nu de GDAL LVBAG driver niet naar behoren zijn, kunnen alle BAG
bestanden op deze manier verwerkt worden. In verleden deden we dit met
TOP10NL/BGT bijv.
Het principe in de Stetl keten is: XML inlezen, via XSLT omzetten naar
OGC Simple Feature GML, met Stetl ogr2ogr-Output deze omzetten naar
PostGIS (of zelfs ander formaat als GPKG).
[1]
https://github.com/nlextract/NLExtract/blob/master/bagv2/etl/conf/etl-imbag-2.1.0.cfg#L32
[2]
https://github.com/nlextract/NLExtract/blob/master/bagv2/etl/xsl/GEM-WPL-RELATIE2gml.xsl
[3]
https://github.com/nlextract/NLExtract/blob/master/bagv2/etl/gfs/imbag-2.1.0.gfs
Met vriendelijke groet,
Just
Bedankt voor (eerste) inhoudelijke feedback!
Ik had via NLExtract Gitter en andere fora een oproep gedaan aan
ontwikkelaars om mee te denken/doen in NLExtract BAG 2.0 ontwikkeling.
Ik kan mij voorstellen (heb ik zelf weer met andere FOSS-projecten) dat
velen te druk zijn. Maakt niet uit.
Voordeel is dat ik snel ontwerp-beslissingen kon/moest nemen...
Je vraag: de BAG 2.0 wordt zoveel mogelijk forward compatible met BAG
1.0 verwerkt. Waaronder dus de gemeente-woonplaats koppeling en de
verrijking met CBS gemeente-provincie gegevens. "No custom Python code!
" is meer dat bovenstaande geheel geschiedt via Stetl configuraties, dus
reeds bestaande Stetl (Python) code. De uiteindelijke database-structuur
heeft een bijna 1-1 structuur met BAG v1. Bijv de adres-tabellen zijn
ongewijzigd.
Voor de gemeente-woonplaats koppeling moet je kijken in deze regel van
de Stetl config [1]. In kort: via een Stetl standaard GDAL '/vsizip' pad
wordt Gemeente-Woonplaats XML zonder uitpakken, uit de BAG .zip
geextraheerd en omgezet met een XSL script [2] , gebruikmakend van GDAL
GFS [3], in een Postgres tabel. Dus zoveel mogelijk de bestaande tools
(Stetl, GDAL, XSLT via libxsl) laten werken.
Mocht nu de GDAL LVBAG driver niet naar behoren zijn, kunnen alle BAG
bestanden op deze manier verwerkt worden. In verleden deden we dit met
TOP10NL/BGT bijv.
Het principe in de Stetl keten is: XML inlezen, via XSLT omzetten naar
OGC Simple Feature GML, met Stetl ogr2ogr-Output deze omzetten naar
PostGIS (of zelfs ander formaat als GPKG).
[1]
https://github.com/nlextract/NLExtract/blob/master/bagv2/etl/conf/etl-imbag-2.1.0.cfg#L32
[2]
https://github.com/nlextract/NLExtract/blob/master/bagv2/etl/xsl/GEM-WPL-RELATIE2gml.xsl
[3]
https://github.com/nlextract/NLExtract/blob/master/bagv2/etl/gfs/imbag-2.1.0.gfs
Met vriendelijke groet,
Just
Just van den Broecke
Apr 2, 2021, 4:01:45 PM4/2/21
to nlex...@googlegroups.com
Hoi Bas,
CBS koppelingen in NLExtract v2: De opzet is anders, meer een begin:
https://github.com/nlextract/NLExtract/tree/master/bagv2/etl/data/cbs/gemeente
Is idee dat daar alle gemeentelijke indelingen als CSV komen te staan in
conventie:
<jaar>.csv
Via een Stetl configuratie bijv in [1]: kan het jaar gekozen worden.
Die optie kan op Stetl commandline overruled worden via bijv
-a cbs_gemeenten_jaar=2010
Blijft een lastig onderwerp. 99% van het gebruikers wil gewoon "de
huidige BAG".
Historie hadden ze gewoon m.i. helemaal apart moeten houden voor de
specialisten.
(Daarnaast hadden ze ook nooit Adressen en Gebouwen moeten combineren,
is ander verhaal...).
De BAG 2.0 bron bevat nog steeds de volledige historie, alleen zijn er
heel wat historie-, onder huidige naam/begrip "voorkomen"-, attributen
bijgekomen. Zie o.a. vele Q&A met Kadaster BAG Team [2], [3] en meer.
[1]
https://github.com/nlextract/NLExtract/blob/master/bagv2/etl/options/common.args#L57
[2] https://geoforum.nl/t/bag-extract-v2-definitie-van-actueel/5579/5
[3]
https://geoforum.nl/t/lv-bag-extract-inactief-nietbag-en-inonderzoek-zip-bestanden/5661
Mijn mening: van alle Basisregistratiesies is de BAG, zelfs/vooral voor
na jaren ontwerp voor BAG v2, nog steeds een "Complex Mess":
- nog steeds custom XML (geen GML of AppSchema GML zoals de overige
basisregs)
- teveel metadata "voorkomen"/historie/status binnen de XML objecten van
de leveringen
- teveel normalisatie: 7 objecttypen
Maar goed, een brede levering als LV BAG XML maakt dat iedere afnemer
haar selecties kan maken....En voor NLExtract een reden van bestaan!
Groet!
Just
CBS koppelingen in NLExtract v2: De opzet is anders, meer een begin:
https://github.com/nlextract/NLExtract/tree/master/bagv2/etl/data/cbs/gemeente
Is idee dat daar alle gemeentelijke indelingen als CSV komen te staan in
conventie:
<jaar>.csv
Via een Stetl configuratie bijv in [1]: kan het jaar gekozen worden.
Die optie kan op Stetl commandline overruled worden via bijv
-a cbs_gemeenten_jaar=2010
Blijft een lastig onderwerp. 99% van het gebruikers wil gewoon "de
huidige BAG".
Historie hadden ze gewoon m.i. helemaal apart moeten houden voor de
specialisten.
(Daarnaast hadden ze ook nooit Adressen en Gebouwen moeten combineren,
is ander verhaal...).
De BAG 2.0 bron bevat nog steeds de volledige historie, alleen zijn er
heel wat historie-, onder huidige naam/begrip "voorkomen"-, attributen
bijgekomen. Zie o.a. vele Q&A met Kadaster BAG Team [2], [3] en meer.
[1]
https://github.com/nlextract/NLExtract/blob/master/bagv2/etl/options/common.args#L57
[2] https://geoforum.nl/t/bag-extract-v2-definitie-van-actueel/5579/5
[3]
https://geoforum.nl/t/lv-bag-extract-inactief-nietbag-en-inonderzoek-zip-bestanden/5661
Mijn mening: van alle Basisregistratiesies is de BAG, zelfs/vooral voor
na jaren ontwerp voor BAG v2, nog steeds een "Complex Mess":
- nog steeds custom XML (geen GML of AppSchema GML zoals de overige
basisregs)
- teveel metadata "voorkomen"/historie/status binnen de XML objecten van
de leveringen
- teveel normalisatie: 7 objecttypen
Maar goed, een brede levering als LV BAG XML maakt dat iedere afnemer
haar selecties kan maken....En voor NLExtract een reden van bestaan!
Groet!
Just
Bas Couwenberg
Apr 3, 2021, 12:53:12 AM4/3/21
to nlex...@googlegroups.com
On Fri, Apr 2, 2021 at 10:01 PM Just van den Broecke
<ju...@justobjects.nl> wrote:
> CBS koppelingen in NLExtract v2: De opzet is anders, meer een begin:
>
> https://github.com/nlextract/NLExtract/tree/master/bagv2/etl/data/cbs/gemeente
>
> Is idee dat daar alle gemeentelijke indelingen als CSV komen te staan in
> conventie:
> <jaar>.csv
De bron data is niet consistent, de namen van de kolommen en volgorde
<ju...@justobjects.nl> wrote:
> CBS koppelingen in NLExtract v2: De opzet is anders, meer een begin:
>
> https://github.com/nlextract/NLExtract/tree/master/bagv2/etl/data/cbs/gemeente
>
> Is idee dat daar alle gemeentelijke indelingen als CSV komen te staan in
> conventie:
> <jaar>.csv
is sinds 1990 met enige regelmaat gewijzigd.
De parser in gemeentelijke-indeling.py voor BAG v1.0 kan met alle
formaten overweg en normaliseerd de kolom namen.
Op basis van gemeentelijke-indeling.xml kunnen de historische CSV
files toegevoegd worden, maar m.i. moeten die files geen 1-op-1
conversie van de recente CBS spreadsheets zijn.
M.i. moeten de kolomnamen in de CSV genormaliseerd worden zodat
wijzigingen in de CBS speadsheets geen effect heeft op de data die
door NLExtract verwerkt wordt, dat formaat blijft hetzelfde.
> Via een Stetl configuratie bijv in [1]: kan het jaar gekozen worden.
> Die optie kan op Stetl commandline overruled worden via bijv
> -a cbs_gemeenten_jaar=2010
> Blijft een lastig onderwerp. 99% van het gebruikers wil gewoon "de
> huidige BAG".
> Historie hadden ze gewoon m.i. helemaal apart moeten houden voor de
> specialisten.
te kunnen porten zal ook de provincie_gemeente tabel historie moeten
bevatten.
De gemeente_provincie tabel werdt in NLExtract gebruikt voor de
koppeling zonder historie, toen de historie is toegevoegd is het
schema aangepast.
Nu hebben we een tabel met dezelfde naam als BAG v1.0, maar met andere
data. Dat is een bijzonder vervelende regression.
I.v.m. de GDAL dependency kan ik niet eenvoudig testen met de nieuwe
BAG om de gemeentelijke-indeling support van BAG v1.0 te porten naar
BAG v2.0.
De GDAL dependency is problematisch, versie 3.2.1 zal in de aankomende
Debian stable release zitten, ook zal 3.2.2+ pas in de volgende Ubuntu
LTS zijn opgenomen, dus de benodigde GDAL features zullen pas over
zo'n twee jaar breed beschikbaar zijn.
Hopelijk blijft de inspireadresen dataset nog gewoon de oude
vertrouwde BAG v1.0 tot die tijd.
Mvg,
Bas
Just van den Broecke
Apr 3, 2021, 7:55:01 AM4/3/21
to nlex...@googlegroups.com
Hoi Bas,
Bedankt voor de inzichten. Ik zie 3 aspecten in je betoog:
- gemeentelijke-indeling.xml als ik goed begrijp zijn er 2 onderdelen:
1) het Shell/Python script om de .xml te onderhouden. 2) het inlezen van
de volledige xml in een genormaliseerde tabel structuur. Beiden kunnen
in BAG v2 worden meegenomen. Denk wel beter om 1) op gemeenschappelijke
(voor BAG v1 en v2) plek te onderhouden.
Ad 2) de .xml kan zo door Stetl ingelezen worden.
Ik ging ervan uit dat voor een specifieke BAG verwerking met standdatum
een enkel jaar nodig was. Maar uiteraard bevat elke BAG volledige
historie inclusief voor gem-wpl koppeling, dus zinvol om de
gemeentelijke-indeling.xml aan te houden. PR welkom.
- ik begrijp niet goed wat OpenStreetMap met BAG historie moet. Om
zelfde reden als BAG? Ook hier denk ik dat 99% van de afnemers de
"huidige BAG" wil. Dat is al een lastig begrip. Voor onderhoud aan BAG
data in OSM is historie wel van belang, maar m.i. minder om "terug in de
tijd" te gaan. Eerlijk gezegd ontbreekt mijn kennis hoe BAG in OSM
precies werkt.
- ik wilde sowieso in NLExtract BAG v1 en v2 compleet gescheiden houden.
En v2 met Stetl, zodat heel NLExtract straks uniform werkt. Met bijv
enkele Docker file. Zodat ook BAG v1 normaal blijft werken. Behoudens
evt gedeelde gemeentelijke-indeling.xml.
- de LVBAG GDAL afhankelijkheid: dat punt heb ik verschillende malen
opgebracht. Niet echt reacties. Dan neem ik zelf beslissingen. Ik mag
toch hopen dat het grootste deel van de gebruikers met Docker of andere
containers gaat werken. Het handmatig installeren en vooral onderhouden
van GDAL, GEOS, Proj en Python bindings op alle platformen is sowieso
"(DLL/.a/.so-)hell". Denk aan alle vragen op de fora. Maar in mijn
eerdere mail gaf ik al aan hoe met Stetl toch BAG v2 (zonder recente
GDAL) kan worden ingelezen. Als iemand dat wil bijdragen...Snelheid is
nu ook wel goed: op snelle machine duurt inlezen heel NL 10 minuten. 1
uur op 5,- Hetzner VM.
Het was ook een kwestie van deadlines: per 1 April (geen grap) verdwijnt
in principe de BAG v1 levering. Dus de beroemde "inspireadressen" Atom.
Per 1 oktober 2021 stopt BAG v1 definitief. In periode 1 april-1okt is
er alleen "niet-gecontroleerde" BAG v1, whatever that means. De Atom
wordt door Kadaster als "achterdeur" gezien (hun woorden) en komt er
voorlopig niet voor v2. Is natuurlijk laatste woord niet over gezegd...
Met vriendelijke groet,
--Just
Bedankt voor de inzichten. Ik zie 3 aspecten in je betoog:
- gemeentelijke-indeling.xml als ik goed begrijp zijn er 2 onderdelen:
1) het Shell/Python script om de .xml te onderhouden. 2) het inlezen van
de volledige xml in een genormaliseerde tabel structuur. Beiden kunnen
in BAG v2 worden meegenomen. Denk wel beter om 1) op gemeenschappelijke
(voor BAG v1 en v2) plek te onderhouden.
Ad 2) de .xml kan zo door Stetl ingelezen worden.
Ik ging ervan uit dat voor een specifieke BAG verwerking met standdatum
een enkel jaar nodig was. Maar uiteraard bevat elke BAG volledige
historie inclusief voor gem-wpl koppeling, dus zinvol om de
gemeentelijke-indeling.xml aan te houden. PR welkom.
- ik begrijp niet goed wat OpenStreetMap met BAG historie moet. Om
zelfde reden als BAG? Ook hier denk ik dat 99% van de afnemers de
"huidige BAG" wil. Dat is al een lastig begrip. Voor onderhoud aan BAG
data in OSM is historie wel van belang, maar m.i. minder om "terug in de
tijd" te gaan. Eerlijk gezegd ontbreekt mijn kennis hoe BAG in OSM
precies werkt.
- ik wilde sowieso in NLExtract BAG v1 en v2 compleet gescheiden houden.
En v2 met Stetl, zodat heel NLExtract straks uniform werkt. Met bijv
enkele Docker file. Zodat ook BAG v1 normaal blijft werken. Behoudens
evt gedeelde gemeentelijke-indeling.xml.
- de LVBAG GDAL afhankelijkheid: dat punt heb ik verschillende malen
opgebracht. Niet echt reacties. Dan neem ik zelf beslissingen. Ik mag
toch hopen dat het grootste deel van de gebruikers met Docker of andere
containers gaat werken. Het handmatig installeren en vooral onderhouden
van GDAL, GEOS, Proj en Python bindings op alle platformen is sowieso
"(DLL/.a/.so-)hell". Denk aan alle vragen op de fora. Maar in mijn
eerdere mail gaf ik al aan hoe met Stetl toch BAG v2 (zonder recente
GDAL) kan worden ingelezen. Als iemand dat wil bijdragen...Snelheid is
nu ook wel goed: op snelle machine duurt inlezen heel NL 10 minuten. 1
uur op 5,- Hetzner VM.
Het was ook een kwestie van deadlines: per 1 April (geen grap) verdwijnt
in principe de BAG v1 levering. Dus de beroemde "inspireadressen" Atom.
Per 1 oktober 2021 stopt BAG v1 definitief. In periode 1 april-1okt is
er alleen "niet-gecontroleerde" BAG v1, whatever that means. De Atom
wordt door Kadaster als "achterdeur" gezien (hun woorden) en komt er
voorlopig niet voor v2. Is natuurlijk laatste woord niet over gezegd...
Met vriendelijke groet,
--Just
Bas Couwenberg
Apr 3, 2021, 8:47:34 AM4/3/21
to nlex...@googlegroups.com
On Sat, Apr 3, 2021 at 1:55 PM Just van den Broecke <ju...@justobjects.nl> wrote:
> Bedankt voor de inzichten. Ik zie 3 aspecten in je betoog:
>
> - gemeentelijke-indeling.xml als ik goed begrijp zijn er 2 onderdelen:
> 1) het Shell/Python script om de .xml te onderhouden. 2) het inlezen van
> de volledige xml in een genormaliseerde tabel structuur. Beiden kunnen
> in BAG v2 worden meegenomen. Denk wel beter om 1) op gemeenschappelijke
> (voor BAG v1 en v2) plek te onderhouden.
> Ad 2) de .xml kan zo door Stetl ingelezen worden.
> Ik ging ervan uit dat voor een specifieke BAG verwerking met standdatum
> een enkel jaar nodig was. Maar uiteraard bevat elke BAG volledige
> historie inclusief voor gem-wpl koppeling, dus zinvol om de
> gemeentelijke-indeling.xml aan te houden. PR welkom.
Het gemeentelijke-indeling.xml bestand wordt onderhouden met het
> Bedankt voor de inzichten. Ik zie 3 aspecten in je betoog:
>
> - gemeentelijke-indeling.xml als ik goed begrijp zijn er 2 onderdelen:
> 1) het Shell/Python script om de .xml te onderhouden. 2) het inlezen van
> de volledige xml in een genormaliseerde tabel structuur. Beiden kunnen
> in BAG v2 worden meegenomen. Denk wel beter om 1) op gemeenschappelijke
> (voor BAG v1 en v2) plek te onderhouden.
> Ad 2) de .xml kan zo door Stetl ingelezen worden.
> Ik ging ervan uit dat voor een specifieke BAG verwerking met standdatum
> een enkel jaar nodig was. Maar uiteraard bevat elke BAG volledige
> historie inclusief voor gem-wpl koppeling, dus zinvol om de
> gemeentelijke-indeling.xml aan te houden. PR welkom.
gemeentelijke-indeling.py script.
Met de --add-cbs-data optie wordt de CBS spreadsheet geparsed en een
nieuwe indeling aan de XML toegevoegd.
Wanneer het formaat van de CBS spreadsheet wijzigd wordt de parser
bijgewerkt om ook dat formaat te ondersteunen.
Met processGemeentelijkeIndeling() in bag/src/processor.py wordt de
XML geparsed t.b.v. de database tabel. Dit moet op een of andere
manier voor BAG v2.0 ook gedaan gaan worden.
Met Stetl heb ik nog weinig tot geen ervaring, dus het is mij niet
direct duidelijk hoe dat te implementeren.
> - ik begrijp niet goed wat OpenStreetMap met BAG historie moet. Om
> zelfde reden als BAG? Ook hier denk ik dat 99% van de afnemers de
> "huidige BAG" wil. Dat is al een lastig begrip. Voor onderhoud aan BAG
> data in OSM is historie wel van belang, maar m.i. minder om "terug in de
> tijd" te gaan. Eerlijk gezegd ontbreekt mijn kennis hoe BAG in OSM
> precies werkt.
heeft queries voor de actuele data ala de actueelbestaand views, voor
die queries is de historie relevant.
In theorie zou daarmee ook historische data opgehaald worden (e.g. de
woonplaatsen in 1991 ipv dit jaar), maar dat wordt in de praktijk niet
gedaan.
Mijn tooling werkt voornamelijk met de woonplaatsen, met ogr2osm wordt
de data geconverteerd om OSM mee bij te werken.
Daarnaast is er ook de JOSM plugin, ontwikkeld door Gert-Jan Idema,
welke gebruik maakt van de BAG WFS en waarmee de gebouwen en adressen
worden onderhouden.
> - ik wilde sowieso in NLExtract BAG v1 en v2 compleet gescheiden houden.
> En v2 met Stetl, zodat heel NLExtract straks uniform werkt. Met bijv
> enkele Docker file. Zodat ook BAG v1 normaal blijft werken. Behoudens
> evt gedeelde gemeentelijke-indeling.xml.
verwijderd kan worden wanneer het niet meer relevant is omdat iedereen
over is naar BAG v2.0.
Tot die tijd is de gemeentelijke-indeling.xml te gebruiken voor beide.
> - de LVBAG GDAL afhankelijkheid: dat punt heb ik verschillende malen
> opgebracht. Niet echt reacties. Dan neem ik zelf beslissingen. Ik mag
> toch hopen dat het grootste deel van de gebruikers met Docker of andere
> containers gaat werken. Het handmatig installeren en vooral onderhouden
> van GDAL, GEOS, Proj en Python bindings op alle platformen is sowieso
> "(DLL/.a/.so-)hell". Denk aan alle vragen op de fora. Maar in mijn
> eerdere mail gaf ik al aan hoe met Stetl toch BAG v2 (zonder recente
> GDAL) kan worden ingelezen. Als iemand dat wil bijdragen...Snelheid is
> nu ook wel goed: op snelle machine duurt inlezen heel NL 10 minuten. 1
> uur op 5,- Hetzner VM.
ligt het gebruik daarvan voor mij voor de hand.
Docker is niet gepackaged in Debian, en zodoende voor mij persoonlijk
geen optie. Voor de gemiddelde gebruiker is het een prima optie.
Op mijn machine duurt het laden van de BAG v1.0 zo'n 8 uur, ben
benieuwd of BAG v2.0 meer of minder tijd zal kosten.
Heb je een link naar de betreffende mail over hoe met Stetl geen
recente GDAL vereist is voor BAG v2.0?
Dat is iets waar ik naar wil kijken gezien dat een betere oplossing
lijkt voor mijn infrastructuur.
> Het was ook een kwestie van deadlines: per 1 April (geen grap) verdwijnt
> in principe de BAG v1 levering. Dus de beroemde "inspireadressen" Atom.
> Per 1 oktober 2021 stopt BAG v1 definitief. In periode 1 april-1okt is
> er alleen "niet-gecontroleerde" BAG v1, whatever that means. De Atom
> wordt door Kadaster als "achterdeur" gezien (hun woorden) en komt er
> voorlopig niet voor v2. Is natuurlijk laatste woord niet over gezegd...
prima open data.
Betalen voor BAG v2.0 is voor OpenStreetMap doeleinden geen optie.
Was het levereren van de inspireadressen dataset geen wettelijke verplichting?
Mvg,
Bas
Just van den Broecke
Apr 5, 2021, 9:34:45 AM4/5/21
to nlex...@googlegroups.com
Hoi Bas,
Het beste is als je twee issues opent op NLExtract project t.b.v. BAG v2:
- "gemeente-provincie koppeling tabel moet volledige historie krijgen
zoals in BAG v1"
gemeentelijke-indeling.xml kan dan de oplossing zijn, heb ik wel nog een
vraag over, zie onder *.
- "BAGv2 inlezen zonder GDAL LVBAG Driver"
Voorbeeld hiervoor geef ik hier:
https://groups.google.com/g/nlextract/c/8Jt_TfqAFW8/m/4Dj7k2UqCAAJ
was antwoord op een van je eerste mails in deze thread. In feite zelfde
stramien als nu met gemeente-woonplaats.xml koppeling gebeurt.
Beter om dan technische discussies binnen betreffende issue te voeren.
* Als ik kijk naar de code en table-resultaat voor gemeentelijke
indeling wordt volgens mij bij verwerking in
processor.py:processGemeentelijkeIndeling() steeds de entry voor de
combinatie [provinciecode][gemeentecode] in de dict datastructuur
overschreven.
Zie
https://github.com/nlextract/NLExtract/blob/master/bag/src/processor.py#L130
Is dat bewust? Levert daardoor nu 785 records op (355 huidige
gemeenten). Omdat de XML sequentieel/per jaar wordt verwerkt gaat dit
toevallig goed en kun je de indeling voor bepaald jaar opvragen. Alleen
als een status hersteld (gemeente beeïndigd, daarna begonnen) wordt gaat
het niet goed omdat alleen de laatste status (begin/eindtijd) wordt
behouden voor die [provinciecode][gemeentecode]. Maar die situatie komt
mogelijk nooit voor. Maar kan ook spellingswijziging zijn...(?) In BAG
objecten wordt per identificatie wel iedere object wijziging met
begin/eindtijd bijgehouden...
Maar misschien snap ik de code nog niet helemaal.
Met vriendelijke groet,
--Just
Het beste is als je twee issues opent op NLExtract project t.b.v. BAG v2:
- "gemeente-provincie koppeling tabel moet volledige historie krijgen
zoals in BAG v1"
gemeentelijke-indeling.xml kan dan de oplossing zijn, heb ik wel nog een
vraag over, zie onder *.
- "BAGv2 inlezen zonder GDAL LVBAG Driver"
Voorbeeld hiervoor geef ik hier:
https://groups.google.com/g/nlextract/c/8Jt_TfqAFW8/m/4Dj7k2UqCAAJ
was antwoord op een van je eerste mails in deze thread. In feite zelfde
stramien als nu met gemeente-woonplaats.xml koppeling gebeurt.
Beter om dan technische discussies binnen betreffende issue te voeren.
* Als ik kijk naar de code en table-resultaat voor gemeentelijke
indeling wordt volgens mij bij verwerking in
processor.py:processGemeentelijkeIndeling() steeds de entry voor de
combinatie [provinciecode][gemeentecode] in de dict datastructuur
overschreven.
Zie
https://github.com/nlextract/NLExtract/blob/master/bag/src/processor.py#L130
Is dat bewust? Levert daardoor nu 785 records op (355 huidige
gemeenten). Omdat de XML sequentieel/per jaar wordt verwerkt gaat dit
toevallig goed en kun je de indeling voor bepaald jaar opvragen. Alleen
als een status hersteld (gemeente beeïndigd, daarna begonnen) wordt gaat
het niet goed omdat alleen de laatste status (begin/eindtijd) wordt
behouden voor die [provinciecode][gemeentecode]. Maar die situatie komt
mogelijk nooit voor. Maar kan ook spellingswijziging zijn...(?) In BAG
objecten wordt per identificatie wel iedere object wijziging met
begin/eindtijd bijgehouden...
Maar misschien snap ik de code nog niet helemaal.
Met vriendelijke groet,
--Just
Bas Couwenberg
Apr 5, 2021, 10:15:16 AM4/5/21
to nlex...@googlegroups.com
On Mon, Apr 5, 2021 at 3:34 PM Just van den Broecke <ju...@justobjects.nl> wrote:
> Het beste is als je twee issues opent op NLExtract project t.b.v. BAG v2:
>
> - "gemeente-provincie koppeling tabel moet volledige historie krijgen
> zoals in BAG v1"
> gemeentelijke-indeling.xml kan dan de oplossing zijn, heb ik wel nog een
> vraag over, zie onder *.
https://github.com/nlextract/NLExtract/issues/311
> Het beste is als je twee issues opent op NLExtract project t.b.v. BAG v2:
>
> - "gemeente-provincie koppeling tabel moet volledige historie krijgen
> zoals in BAG v1"
> gemeentelijke-indeling.xml kan dan de oplossing zijn, heb ik wel nog een
> vraag over, zie onder *.
> - "BAGv2 inlezen zonder GDAL LVBAG Driver"
> Voorbeeld hiervoor geef ik hier:
> https://groups.google.com/g/nlextract/c/8Jt_TfqAFW8/m/4Dj7k2UqCAAJ
> was antwoord op een van je eerste mails in deze thread. In feite zelfde
> stramien als nu met gemeente-woonplaats.xml koppeling gebeurt.
> Beter om dan technische discussies binnen betreffende issue te voeren.
>
> * Als ik kijk naar de code en table-resultaat voor gemeentelijke
> indeling wordt volgens mij bij verwerking in
> processor.py:processGemeentelijkeIndeling() steeds de entry voor de
> combinatie [provinciecode][gemeentecode] in de dict datastructuur
> overschreven.
> Zie
> https://github.com/nlextract/NLExtract/blob/master/bag/src/processor.py#L130
> Is dat bewust?
Deze worden niet hergebruikt voor zover ik weet.
> Levert daardoor nu 785 records op (355 huidige
> gemeenten). Omdat de XML sequentieel/per jaar wordt verwerkt gaat dit
> toevallig goed en kun je de indeling voor bepaald jaar opvragen.
> Alleen
> als een status hersteld (gemeente beeïndigd, daarna begonnen) wordt gaat
> het niet goed omdat alleen de laatste status (begin/eindtijd) wordt
> behouden voor die [provinciecode][gemeentecode]. Maar die situatie komt
> mogelijk nooit voor.
> Maar kan ook spellingswijziging zijn...(?) In BAG
> objecten wordt per identificatie wel iedere object wijziging met
> begin/eindtijd bijgehouden...
zijn vanaf 1997.
Dit is pas in 2021 in de CBS data gedaan.
Omdat de CBS data altijd Friesland heeft aangehouden is dit niet
aangepast in de XML, waar attributen van de provincies van het
voorgaande jaar worden overgenomen bij het aanmaken van de indeling
voor een nieuw jaar.
De data in gemeentelijke-indeling.xml kan eenvoudig gecorrigeerd
worden wat Friesland betreft.
Omdat voor de provincie tabel geen historie wordt bijgehouden, zal dan
Fryslân als provincienaam gebruikt worden, wat niet geheel juist is
voor de data voor 1997.
Als we het echt goed willen moeten voor de provincie en gemeente
tabellen ook historie bijgehouden gaan worden zodat op basis van de
begin en eind data de relevante records bepaald kunnen worden zoals
voor de BAG objecten.
Dat acht ik echter als onnodige complexiteit, en heb dat daarom niet
voor BAG v1 geimplementeerd toen historie voor de gemeente-provincie
koppeling is toegevoegd.
> Maar misschien snap ik de code nog niet helemaal.
Bas Couwenberg
Apr 5, 2021, 10:18:03 AM4/5/21
to nlex...@googlegroups.com
On Mon, Apr 5, 2021 at 4:15 PM Bas Couwenberg <linux...@gmail.com> wrote:
> > Maar kan ook spellingswijziging zijn...(?) In BAG
> > objecten wordt per identificatie wel iedere object wijziging met
> > begin/eindtijd bijgehouden...
>
> Strict genomen zou de provincienaam voor Friesland, Fryslân moeten
> zijn vanaf 1997.
>
> Dit is pas in 2021 in de CBS data gedaan.
>
> Omdat de CBS data altijd Friesland heeft aangehouden is dit niet
> aangepast in de XML, waar attributen van de provincies van het
> voorgaande jaar worden overgenomen bij het aanmaken van de indeling
> voor een nieuw jaar.
>
> De data in gemeentelijke-indeling.xml kan eenvoudig gecorrigeerd
> worden wat Friesland betreft.
>
> Omdat voor de provincie tabel geen historie wordt bijgehouden, zal dan
> Fryslân als provincienaam gebruikt worden, wat niet geheel juist is
> voor de data voor 1997.
>
> Als we het echt goed willen moeten voor de provincie en gemeente
> tabellen ook historie bijgehouden gaan worden zodat op basis van de
> begin en eind data de relevante records bepaald kunnen worden zoals
> voor de BAG objecten.
>
> Dat acht ik echter als onnodige complexiteit, en heb dat daarom niet
> voor BAG v1 geimplementeerd toen historie voor de gemeente-provincie
> koppeling is toegevoegd.
PS. M.i. moet op korte termijn de gemeentelijke-indeling zoals voor
> > Maar kan ook spellingswijziging zijn...(?) In BAG
> > objecten wordt per identificatie wel iedere object wijziging met
> > begin/eindtijd bijgehouden...
>
> Strict genomen zou de provincienaam voor Friesland, Fryslân moeten
> zijn vanaf 1997.
>
> Dit is pas in 2021 in de CBS data gedaan.
>
> Omdat de CBS data altijd Friesland heeft aangehouden is dit niet
> aangepast in de XML, waar attributen van de provincies van het
> voorgaande jaar worden overgenomen bij het aanmaken van de indeling
> voor een nieuw jaar.
>
> De data in gemeentelijke-indeling.xml kan eenvoudig gecorrigeerd
> worden wat Friesland betreft.
>
> Omdat voor de provincie tabel geen historie wordt bijgehouden, zal dan
> Fryslân als provincienaam gebruikt worden, wat niet geheel juist is
> voor de data voor 1997.
>
> Als we het echt goed willen moeten voor de provincie en gemeente
> tabellen ook historie bijgehouden gaan worden zodat op basis van de
> begin en eind data de relevante records bepaald kunnen worden zoals
> voor de BAG objecten.
>
> Dat acht ik echter als onnodige complexiteit, en heb dat daarom niet
> voor BAG v1 geimplementeerd toen historie voor de gemeente-provincie
> koppeling is toegevoegd.
BAGv1 in gebruik, ook voor BAGv2 geimplementeerd worden zodat dat
hetzelfde blijft wat het database schema en content betreft.
Omdat er ruimte voor verbetering is, kan daarna historie voor de
gemeente en provincie objecten toegevoegd worden ipv alleen voor de
koppeling. Dit is een apart issue, wat later opgepakt kan worden.
Just van den Broecke
Apr 6, 2021, 4:43:25 AM4/6/21
to nlex...@googlegroups.com
Bedankt voor het openen van de issues!
Ja dacht aan bijv Friesland als voorbeeld naamswijziging.
Fryslân werd al hard op Friesland gezet in de SQL nabewerking (met
excuus aan de Friezen):
https://github.com/nlextract/NLExtract/blob/master/bagv2/etl/sql/finalize-tables.sql#L116
Zie verder in volgende mails en technische discussie in issues.
Mvg,
Just
Ja dacht aan bijv Friesland als voorbeeld naamswijziging.
Fryslân werd al hard op Friesland gezet in de SQL nabewerking (met
excuus aan de Friezen):
https://github.com/nlextract/NLExtract/blob/master/bagv2/etl/sql/finalize-tables.sql#L116
Zie verder in volgende mails en technische discussie in issues.
Mvg,
Just
Just van den Broecke
Apr 6, 2021, 4:51:36 AM4/6/21
to nlex...@googlegroups.com
On 05/04/2021 16:17, Bas Couwenberg wrote:
> On Mon, Apr 5, 2021 at 4:15 PM Bas Couwenberg <linux...@gmail.com> wrote:
>>> Maar kan ook spellingswijziging zijn...(?) In BAG
>>> objecten wordt per identificatie wel iedere object wijziging met
>>> begin/eindtijd bijgehouden...
>>
>> Strict genomen zou de provincienaam voor Friesland, Fryslân moeten
>> zijn vanaf 1997.
>>
>> Dit is pas in 2021 in de CBS data gedaan.
>>
>> Omdat de CBS data altijd Friesland heeft aangehouden is dit niet
>> aangepast in de XML, waar attributen van de provincies van het
>> voorgaande jaar worden overgenomen bij het aanmaken van de indeling
>> voor een nieuw jaar.
>>
>> De data in gemeentelijke-indeling.xml kan eenvoudig gecorrigeerd
>> worden wat Friesland betreft.
>>
>> Omdat voor de provincie tabel geen historie wordt bijgehouden, zal dan
>> Fryslân als provincienaam gebruikt worden, wat niet geheel juist is
>> voor de data voor 1997.
>>
>> Als we het echt goed willen moeten voor de provincie en gemeente
>> tabellen ook historie bijgehouden gaan worden zodat op basis van de
>> begin en eind data de relevante records bepaald kunnen worden zoals
>> voor de BAG objecten.
>>
>> Dat acht ik echter als onnodige complexiteit, en heb dat daarom niet
>> voor BAG v1 geimplementeerd toen historie voor de gemeente-provincie
>> koppeling is toegevoegd
>
> On Mon, Apr 5, 2021 at 4:15 PM Bas Couwenberg <linux...@gmail.com> wrote:
>>> Maar kan ook spellingswijziging zijn...(?) In BAG
>>> objecten wordt per identificatie wel iedere object wijziging met
>>> begin/eindtijd bijgehouden...
>>
>> Strict genomen zou de provincienaam voor Friesland, Fryslân moeten
>> zijn vanaf 1997.
>>
>> Dit is pas in 2021 in de CBS data gedaan.
>>
>> Omdat de CBS data altijd Friesland heeft aangehouden is dit niet
>> aangepast in de XML, waar attributen van de provincies van het
>> voorgaande jaar worden overgenomen bij het aanmaken van de indeling
>> voor een nieuw jaar.
>>
>> De data in gemeentelijke-indeling.xml kan eenvoudig gecorrigeerd
>> worden wat Friesland betreft.
>>
>> Omdat voor de provincie tabel geen historie wordt bijgehouden, zal dan
>> Fryslân als provincienaam gebruikt worden, wat niet geheel juist is
>> voor de data voor 1997.
>>
>> Als we het echt goed willen moeten voor de provincie en gemeente
>> tabellen ook historie bijgehouden gaan worden zodat op basis van de
>> begin en eind data de relevante records bepaald kunnen worden zoals
>> voor de BAG objecten.
>>
>> Dat acht ik echter als onnodige complexiteit, en heb dat daarom niet
>> voor BAG v1 geimplementeerd toen historie voor de gemeente-provincie
>> koppeling is toegevoegd
>
> PS. M.i. moet op korte termijn de gemeentelijke-indeling zoals voor
> BAGv1 in gebruik, ook voor BAGv2 geimplementeerd worden zodat dat
> hetzelfde blijft wat het database schema en content betreft.
Volgens mij is dat al het geval. Daarvoor is ook evt de SQL nabewerking:
> BAGv1 in gebruik, ook voor BAGv2 geimplementeerd worden zodat dat
> hetzelfde blijft wat het database schema en content betreft.
https://github.com/nlextract/NLExtract/blob/master/bagv2/etl/sql/finalize-tables.sql
wel best-effort .
>
> Omdat er ruimte voor verbetering is, kan daarna historie voor de
> gemeente en provincie objecten toegevoegd worden ipv alleen voor de
> koppeling. Dit is een apart issue, wat later opgepakt kan worden.
>
be/onderhouden: zie issue https://github.com/nlextract/NLExtract/issues/311
Met vriendelijke groet,
--Just
Reply all
Reply to author
Forward
0 new messages