Kompakte Datenbankschemata
für
dynamisch
erweiterbare
GML Application Schemas
GML Application Schemas erweiterbare
dynamisch
für
Datenbankschemata
Kompakte
Attribute
+
Austausch Simple Features
GIS
CSV
GeoDB
WebGIS
Web
~ C h r o n o l o g i s c h ~
- Der Quatsch mit den 4-6 Dateien pro Layer
- Tabellen mit Koordinatenspalten
- Das Web spricht XML, also Geography Markup Language
- Google Earth Woaaah, KML!
- Das Web spricht doch lieber JSON, also GeoJSON
- Es lebe GeoPackage! (und alle so ...)
Austausch (Vektor-)Geodaten
+
Warum will man das?!
Sauberere Modellierung
Konsistenz
Weniger Redundanz
Austausch Complex Features
???
Standard reden?!
ETL
OGC
Nutzer von OGC-Compliant Software
Application Schema
Warum?!
- Zu komplex. Gib mir JSON.
- Gibt doch Metadaten.
- Wer nutzt das denn überhaupt?
- MVP, Hallo?! Auf in den Sprint!
- Ist dem Kunden doch egal.
Darum
- Interabl-interoperabilili- ihr wisst schon
- Raus aus der Integrationshölle
- Datenproduzenten an den Pranger!
- Ja, es gibt dennoch viele Fehler ... aber irgendwann stehen die Tests!
- Schutzschild vor Start Ups
- Standardisiertes Labeling von Daten >> Stichtwort Machine Learning (denkt mal drüber nach...)
@potree
Anforderungen
vs. Standard
Was, wenn kein Standard genügt?
Option 1 - DIY
https://xkcd.com/927/
Option 2 - Muss ja
-
Generische Erweiterungen von Standards nutzen
-
Pro: Vorhandene Software kann verwendet werden
-
Contra: Inhalte können nicht validiert werden
Option 3 - Join SWG
http://dilbert.com/strip/2011-08-02
Option 4 - Get hooked
FeatureType
properties
AbstractFeature
New Type
properties
properties
<CityGML>
<CityGML>
properties
FeatureType
<ADE>
<ADEElement>
New Type
properties
<Feature>
Neue Attribute
Neue Klassen
Neue Subklassen
CityGML
Namespace
ADE
Namespace
Hook
_GenericApplicationPropertyOf<Featuretypename>
Validierung
Wie war das mit der Datenbank?
Objekt <-> Relational
-
Aaaaltes Thema (impedence mismatch) ...
-
Eine Tabelle pro Klasse, Complexer Typ etc.?
-
Abbilden von Hierachien und Vererbung?
-
Grad der Normalisierung (Vermeidung von JOINs)?
-
Einmaliges Mapping eines erweiterten XML Schemas
- vs. Iteratives Erweitern vom DB-Schema?
3D City Database
-
Manuelle Anpassungen an UML
-
Manuelle Anpassungen an DB-Schema
-
~ 60 Tabellen für CityGML v2.0
-
Hard-coded Im/Exporter
-
WFS-to-SQL anhand von XML Config
-
Ab nächster Version mit ADEs erweiterbar
-
Repo: github.com/3dcitydb
-
hub.docker.com/r/tumgis/3dcitydb-postgis
http://www.dgpf.de/src/tagung/jt2017/proceedings/proceedings/papers/30_DGPF2017_Yao_Kolbe.pdf
Atributed Graph Grammar
Homepage: http://www.user.tu-berlin.de/o.runge/agg/index.html
Repo(?): https://github.com/de-tu-berlin-tfs/Henshin-Editor/tree/master/de.tub.tfs.agg
ADE Management
ade
3DCityDB CORE Schema
Noise ADE
Energy ADE
Dynamizer ADE
- Andocken an Kern-Schema
- Registrierung in Metadaten
- Keine Änderungen am Core
- Imp/Exp & WFS Support
- Importer/Exporter Plugin: https://github.com/3dcitydb/plugin-ade-manager.git
deegree Feature Store
http://download.deegree.org/documentation/3.3.0/html/featurestores.html#application-schemas
- Einmaliges Mapping via CLI (ab v3.4)
- CityGML = 422 Tabellen (ggf. mehr)
- BLOB-Modus für schnellen Export
- Mapping über XML konfigurierbar
- Support für weitere GMLAS (XPlan Toolbox, AIXM)
- PostGIS, Oracle, MS-SQL und (bald) GeoPackage
deegree Feature Store
CLI interface: https://github.com/lat-lon/deegree-cli-utility
Stenger 2017, FOSSGIS Passau
Geoserver app-schema
Doku: http://docs.geoserver.org/latest/en/user/data/app-schema/tutorial.html
- Separate Extension für Geoserver
- Datenbankschema muss schon existieren
- 1:n Beziehungen: Feature Chaining und Joining
- n:m Beziehungen: Denormalized Views
- Mapping am besten in Hale bauen und als app-schema exportieren
- PostGIS, Oracle, MongoDB
Geoserver app-schema
Tutorial: https://geoserver.geo-solutions.it/edu/en/complex_features/index.html
BRGM QGIS GMLAS Toolbox
GDAL: http://www.gdal.org/drv_gmlas_mapping_examples.html
BRGM: https://github.com/BRGM/gml_application_schema_toolbox
- Basiert auf GDAL GMLAS Driver
- Wenig Konfigurationsmöglichkeiten
- CityGML = 1412 Tabellen
- Modi: Create, Update, Append, Overwrite
- PostGIS, SQLite
Weitere OS Lösungen
UML zu DB Schema:
ShapeChange: https://github.com/ShapeChange
xmi2db: https://github.com/pkorduan/xmi2db
ETL:
stetl: https://github.com/geopython/stetl
Kennt ihr mehr? Sagt es mir!
NoSQL
- Kein Problem mit erweiterbaren GMLAS, da "schemalos"
- Rein und Raus unzwar schnell!
- Gut als Mittelschicht zwischen DB und Anwendung
- Vertreter z.B. GeoRocket (MongoDB)
- Bisher untersucht: MongoDB, BaseX, Neo4j, ArangoDB
Fazit GMLAS und DBs
-
Schema-Durchblick mit Graphen
-
Nach wie vor komplexes Thema
-
Einstieg ist leichter geworden
-
ADEs: Unabhängiger und validierbar
-
Was wollt ihr mit der Datenbank tun?
-
CityGML? > 3DCityDB
-
GML zu DB? > GDAL
-
GML zu DB + WFS > deegree
-
DB zu GML > HALE + Geoserver
-
Nix, nur speichern > NoSQL
-
Das Wars. Fragen?
Felix Kunde
Beuth Hochschule
@FlxKu
Slides: https://slides.com/fxku/gmlas_db
Kompakte Datenbankschemata für dynamisch erweiterbare GML Application Schemas
Kompakte Datenbankschemata für dynamisch erweiterbare GML Application Schemas
By fxku
Kompakte Datenbankschemata für dynamisch erweiterbare GML Application Schemas
- 3,106
