Abwasser-Datenformate in QGIS

Damit QGIS ein effektives Werkzeug für die Verwaltung von Abwasserinfrastrukturen werden kann, ist es notwendig, dass QGIS die verbreiteten de-facto Standards an Abwasserdatenformaten, wie ISYBAU XML oder DWA-M 150 konsumieren kann.

Ausgehend von der Grundidee die Strukturiertheit und Schema-Konformität von XML-Daten direkt für Zugriff und Interaktion zu nutzen, wurde der OGR Treiber GMLAS sowie das darauf basierende das QGIS Plugin GML Application Schema Toolbox entwickelt: Anstatt für bestimmte Inhalte vorprogrammiert zu sein, sollen XML-Daten generisch und anpassbar auf Grundlage jedweden Schemas gelesen werden.

Versionen

Hinweis für QGIS 2

Das Plugin GML Application Schema Toolbox wurde durch BRGM (den französischen Geologischen Dienst) und das Copernicus Programm der EU finanziert und von Oslandia und Camptocamp entwickelt. Der verwendete OGR GMLAS Treiber ist von Spatialys entwickelt worden. Die hier beschriebene Software ist sämtlich als Free and Open Source lizensiert.

weitere Materialeien

„Die ISYBAU-Austauschformate Abwasser dienen dem standardisierten, DV-orientierten Datenaustausch zwischen Auftraggeber und Auftragnehmer oder anderen Projektbeteiligten. Die ISYBAU-Austauschformate im XML-Format wurden im Oktober 2006 eingeführt und im Februar 2013 erstmalig fortgeschrieben. Das Format hat aktuell die Bezeichnung ISYBAU XML-2013 (Stand 12/2015).“

„Alle Inhalte sind im XML-Format der Version 1.0 beschrieben. XML ermöglicht die Trennung von Struktur und Daten. Struktur und Inhalte der einzelnen Datenbereiche sind jeweils in einem unabhängigen XML-Schema eindeutig definiert, die ebenfalls zur Verfügung gestellt werden.“

Beispieldaten (s. Arbeitshilfen Abwasser), sowie die einzelnen Vorbereitungs- und Verarbeitungssritte und notwendige SQL-Scripte sind auf GitHub beschrieben!

Verwendebare Beispieldaten, hier: isybau_xml-2006-stammdaten_sanierung_abnahme.xml

Datenvorbereitung

ISYBAU XML verfügt zwar über Schemas, diese sind jedoch nicht aus Repositories online abrufbar, wie z.B. die OpenGIS Appication Schemas — (http://www.ofd-hannover.la/Identifikation ist eine Fake-URL).
Man kann die ISYBAU Schemas aber lokal nutzen. Damit das funktioniert, muss im einzulesenden XML-Dokumemt darauf verwiesen werden1) und der Anfang der Datei ergänzt werden:

fixed_header_ISYBAU_XML.xml
<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
<Identifikation xmlns="http://www.ofd-hannover.la/Identifikation"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
            xsi:schemaLocation="http://www.ofd-hannover.la/Identifikation schema/1302-metadaten.xsd"> 

Oder man spezifiziert die Schemadatei mit der GMLAS Open Option XSD=filename, wenn man den Treiber in OGR verwendet.

$ ogrinfo GMLAS:Q:\HOMEOFFICE\ISYBAU_XML-2006-Stammdaten_Sanierung_Abnahme.xml -oo XSD=Q:\HOMEOFFICE\schema\1302-metadaten.xsd

Der Verweis auf das Schema des Metadaten-Bereiches ist ausreichend, da in diesem alle weiteren Schema eingebunden werden.

Die QGIS GML Application Schema Toolbox bietet zwei Herangehensweisen mit unterschiedlicher Datendarstellung in QGIS:

Import as XML

Zum einen können die Daten direkt in ihrer normalen, hierarchischen XML-Baumstruktur verwendet werden („XML mode“). Dabei wird jedes „Complex Feature“ als eine Zeile eines Vektor-Layers gespeichert. Mit den üblichen QGIS Werkzeugen kann auf jeden Unterabschnitt der Baumstruktur zugegriffen werden.

  • auf diese Weise kann der gesamte Inhalt eingesehen werden.
  • erweiterte Interaktionen, wie die Auflösung externer Ressourcen, stehen mangels xlink:href-Elementen mit ISYBAU nicht zur Verfügung.
  • der entsehende temopräre Layer Identifikation kann z.B. als SpatiaLite abgespeichert werden.
  • der mit dem xml_tree_widget übersteuerte Layerstil zur XML-Baum-Anzeige sollte als Vorgabe mit in der SpatiaLite gespeichert werden.

Import using GMLAS driver

Der andere Ansatz besteht darin, das XML zunächst in ein relationales SQL-Modell zu verwandeln, dass in einer Datenbank wie PostGIS oder SpatiaLite gespeichert wird und mit dem dann in QGIS interagiert werden kann. Dazu werden die im XML angegebenen XSD Schemata durch den OGR GMLAS Treiber analysiert, um aus dem zugrunde liegenden Objektmodell alle Elementtypen und Attribute sowie die Verknüpfungen zwischen den Elementen abzuleiten. Letztere werden in Beziehungen zwischen den Datenbanktabellen der Elemente umgesetzt, die mit den Werten aus dem XML gefüllt werden.

In QGIS lassen sich 1:N-Beziehungen zwischen Vektorlayern deklarieren, die in der Formularansicht eines Layers das Navigieren in der Modellstruktur ermöglichen. Abschließend erzeugt das Plugin automatisch ein QGIS-Projekt mit allen geladenen Layern und Beziehungen.

GMLAS Konfigurationsdatei

Der OGR GMLAS Treiber, der Teil der weit verbreiteten Geospatial Data Abstraction Library (GDAL) ist und der die beschriebene Konvertierung übernimmt, wird anhand einer XML-Datei konfiguriert, deren Struktur und Inhalt im zugehörigen Schema gmlasconf.xsd dokumentiert sind. Dies eröffnet weitreichende Konfigurationsmöglichkeiten durch Anpassung dieser Dateien.

Layernamen

  • die gebildeten Layernamen sind Zusammenfassungen aus den XML-Elementen (Tabellen), zwischen denen nur 1:1-Relationen bestehen. — evt. läßt sich das mit der Konfigurationsdatei beeinflussen? T. Schüttenberg 2017-11-10 19:44
    • der Treiber versucht immer eindeutige Layernamen aus maximal 64 Zeichen zu bilden (mittels Abkürzungs-Logik und laufenden Nummern, falls doch Duplikate auftreten). (vgl. #38)
    • mit ein und dem selben Eingangsschema führt das natürlich immer zum selben Ergebnis.
  • d.h. die Layerbezeichnungen eines ISYBAU-Importes werden immer gleich sein, (vgl. unten).

Nach dem Import der ISYBAU XML-Datei besteht der Datenbankinhalt ausschließlich aus geometrielosen Tabellen. Die Geomerie der Abwassertechnischen Anlagen muss in einem weiteren Schritt mittels SQL aus den vorhandenen Koordinaten gebildet werden. Das Ergebnis kann in QGIS als Vektorlayer geladen werden und auch wieder mit den importierten, untereinander referenzierten Tabellen verknüpft werden.

v_objektgeometrien_p.sql
--Knoten: Bildung der Punktgeometrien, Achtung: nicht deckungsgleich mit Abwassertechnischen Anlagen, mehrer Punkte pro Anlage (SMP, DMP, etc.) möglich!
CREATE OR REPLACE VIEW sta_san_abn.v_objektgeometrien_p AS 
 SELECT kp.ogc_fid, kp.ogr_pkid, kp.parent_ogr_pkid,
    kp.rechtswert, kp.hochwert, kp.punkthoehe,
    kp.punktattributabwasser,
    kp.lagegenauigkeitsstufe, kp.hoehengenauigkeitsstufe,
    ST_SetSRID(ST_MakePoint(kp.rechtswert, kp.hochwert), 25832)::geometry(Point,25832) AS p_geom_2d
   FROM sta_san_abn.identi_datenk_stammd_abwassanlage_geomet_geomet_knoten_punkt kp;
ALTER TABLE sta_san_abn.identi_datenk_stammd_abwassanlage_geomet_geomet_knoten_punkt
ADD COLUMN p_geom_2d geometry(Point,25832);
UPDATE sta_san_abn.identi_datenk_stammd_abwassanlage_geomet_geomet_knoten_punkt 
SET p_geom_2d =  ST_SetSRID(ST_MakePoint(rechtswert, hochwert), 25832);
v_objektgeometrien_l.sql
--Kanten: Bildung der einfachen Liniengeometrien (Strecken)
CREATE OR REPLACE VIEW sta_san_abn.v_objektgeometrien_l AS 
 SELECT kk.parent_ogr_pkid,
    ST_SetSRID(ST_MakeLine(ST_MakePoint(kk.start_rechtswert, kk.start_hochwert), ST_MakePoint(kk.ende_rechtswert, kk.ende_hochwert)), 25832)::geometry(LineString,25832) AS l_geom_2d
   FROM sta_san_abn.identi_datenk_stammd_abwassanlage_geomet_geomet_kanten_kante kk
UNION ALL
--sowie der Polylinien aus mehreren Abschnitten
 SELECT ( SELECT p_1.parent_ogr_pkid
           FROM sta_san_abn.ident_daten_stammd_abwassanlage_geomet_geomet_polygo_polygon p_1
          WHERE pk.parent_ogr_pkid::text = p_1.ogr_pkid::text) AS parent_ogr_pkid,
    ST_SetSRID(ST_MakeLine(ST_MakeLine(ST_MakePoint(pk.start_rechtswert, pk.start_hochwert), ST_MakePoint(pk.ende_rechtswert, pk.ende_hochwert))), 25832 )::geometry(LineString,25832) AS l_geom_2d
   FROM sta_san_abn.ident_daten_stamm_abwasanlag_geome_geome_polygo_polygo_kante pk,
    sta_san_abn.ident_daten_stammd_abwassanlage_geomet_geomet_polygo_polygon p
  WHERE pk.parent_ogr_pkid::text = p.ogr_pkid::text AND p.polygonart = 3
  GROUP BY pk.parent_ogr_pkid;
ALTER TABLE sta_san_abn.identi_datenk_stammd_abwassanlage_geomet_geomet_kanten_kante
ADD COLUMN l_geom_2d geometry(LineString,25832);
UPDATE sta_san_abn.identifikati_datenkollekti_stammdatenkol_abwassertechnanlage a 
SET l_geom_2d = (SELECT l_geom_2d from isybau_gmlas.v_objektgeometrien_l WHERE parent_ogr_pkid = a.ogr_pkid)
 
--UPDATE sta_san_abn.identi_datenk_stammd_abwassanlage_geomet_geomet_kanten_kante
--SET l_geom_2d = ST_SetSRID(ST_MakeLine(ST_MakePoint(start_rechtswert, start_hochwert), ST_MakePoint(ende_rechtswert, ende_hochwert)), 25832);
v_objektgeometrien_f.sql
--Knoten: Bildung von Flächengeometrien
CREATE OR REPLACE VIEW sta_san_abn.v_objektgeometrien_f AS 
 SELECT ( SELECT p_1.parent_ogr_pkid
           FROM sta_san_abn.ident_daten_stammd_abwassanlage_geomet_geomet_polygo_polygon p_1
          WHERE pk.parent_ogr_pkid::text = p_1.ogr_pkid::text) AS parent_ogr_pkid,
    ST_SetSRID(ST_MakePolygon(ST_MakeLine(ST_MakeLine(ST_MakePoint(pk.start_rechtswert, pk.start_hochwert), ST_MakePoint(pk.ende_rechtswert, pk.ende_hochwert)))), 25832)::geometry(Polygon,25832) AS f_geom_2d
   FROM sta_san_abn.ident_daten_stamm_abwasanlag_geome_geome_polygo_polygo_kante pk,
    sta_san_abn.ident_daten_stammd_abwassanlage_geomet_geomet_polygo_polygon p
  WHERE pk.parent_ogr_pkid::text = p.ogr_pkid::text AND p.polygonart = 2
  GROUP BY pk.parent_ogr_pkid;
Importergebnis zum download: isybau_sta_san_abn.sqlite & .qgs
  • Die in einer SQL-Datenbank gespeicherten ISYBAU-Daten stehen für vielfältigste Qualitätsprüfungen, Validierungen und Plausiblisierungen zur Verfügung.
  • Durch die immer gleiche Struktur der importierten Daten ist es möglich wiederverwendbare Exportskripte für ander Datenbanken oder -modelle zu erstellen. → QGEP, QKan
  • Importierte und gespeicherte Daten sind auch in QGIS 2 nutzbar.
  • Intensives Testen des Datenbankschemas → Constraints etc.
  • Optimierung der Projektgenerierung bezüglich Layerbezeichnungen, Geometriebildung und Gruppierung („Datenkollektive“) → :?: QGIS Project Generator
  • Nachteile (und Vorteile?) des ad hoc ISYBAU-Modells für die Datenhaltung eruieren.
  • etc. …

„Das Merkblatt DWA-M 150 beinhaltet Regelungen zum Datentransfer und berücksichtigt babei nur Daten der Zustandserfassung von Entwässerungssystemen und den damit in Zusammenhang stehenden Grunddaten. Im Merkblatt ist die technische Umsetzung der Schnittstelle beschrieben und es werden anwendungsbezogene Formate vorgegeben.“

„Das Austauschformat basiert auf dem XML–Standard. Die Datenstruktur ist in der *.xsd-Datei (XML-Schema) definiert. Beispiel-Schemadateien zu den entsprechenden Formaten können von der Homepage der DWA geladen werden.“

Datenvorbereitungen

Die Testdaten enthalten bereits den Verweis auf das beiliegende Schema, sind jedoch insgesamt sehr minimalistisch.

Das Einlesen der Beispieldaten funktionniert sowohl im XML-Modus als auch mittels GMLAS-Treiber (s.o).

Auch im DWA-M 150-Format ist Geometrie in Form von Koordinaten gespeichert, Tabellen data_kg_go_gp bzw. data_hg_go_gp.