opengeogroep/BAG-Extract — Issue #18: Maak best of both worlds van Objecten.py en libBAG.py
Author: justb4
Created: 2011-12-20 11:59:38+00:00
State: open

Objecten.py is momenteel het lichtgewicht data object model om BAG objecten te parsen, attributen op te slaan en SQL voor inserts te genereren.

- libBAG.py m.i. zit op zich qua basis-model goed in elkaar, echter de classes hebben teveel verantwoordelijkheden (bijv. tabellen aanmaken en andere database acties). De classes moeten "passiever" worden, pure data objecten. (IO-)Processing moet in andere classes plaatsvinden.

- andere zaken zoals inlezen xml zijn juist robuust in libBAG.py en moest ik langzamerhand in Objecten.py toevoegen (zie bijv. text node issue)

- het omgaan met relatie-objecten 3x voorkomend is elegant opgelost in libBAG.py (multipliciteit, zie ook andere open issues)

- geometrie: ik begrijp het idee achter gebruik native OGR maar het genereren van een WKT op basis XML parsing is lightweight en heeft minder installatie-problemen (was bijna uur bezig om Python bindings voor GDAL goed te krijgen op m'n Mac). Ook een Centroid operatie kun je PostGIS laten doen. Als we ooit OGR/Shape export willen doen kunnen we altijd GDAL weer invoegen.

Ik zie een merge mogelijk van libGDAL en Objecten.py waarbij het lichtgewicht karakter van Objecten.py en het basis model van libBAG.py behouden blijft. Of waren er specifieke problemen met libBag (geheugen?) ?