{"id":15108,"date":"2024-12-03T06:55:30","date_gmt":"2024-12-03T05:55:30","guid":{"rendered":"https:\/\/www.opengis.ch\/?p=15108"},"modified":"2024-12-02T08:26:14","modified_gmt":"2024-12-02T07:26:14","slug":"belastete-standorte-im-geopackage","status":"publish","type":"post","link":"https:\/\/www.opengis.ch\/de\/2024\/12\/03\/belastete-standorte-im-geopackage\/","title":{"rendered":"Belastete Standorte im GeoPackage"},"content":{"rendered":"\n

Das INTERLIS Bundesmodell des Kasters der belasteten Standorte KbS_V1_5<\/code> ohne Probleme in einem GeoPackage zu implementieren und zu bearbeiten? Lange nur ein ferner Traum, doch jetzt Realit\u00e4t. Mit Model Baker 7.10 und ili2db 5.2 kannst du deine INTERLIS Datens\u00e4tze, die mehrere Geometriespalten pro Klasse enthalten, bequem auch im GeoPackage barbeiten.<\/strong><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Ein seit Jahren bestehender Painpoint im Umgang mit Modellen wie dem des Kataster der belasteten Standorte oder Nutzungsplanung war, dass die Modelle Klassen mit mehreren Geometrien<\/strong> enthalten. Hier zum Beispiel eine Punkt- und eine Polygon-Geometrie.<\/p>\n\n\n\n

CLASS Belasteter_Standort =\n    Katasternummer : MANDATORY TEXT;\n    URL_Standort : MultilingualUri;\n    Geo_Lage_Polygon : MultiPolygon;\n    Geo_Lage_Punkt : GeometryCHLV95_V1.Coord2;\n    [...]\nEND Belasteter_Standort;\n<\/code><\/pre>\n\n\n\n
Bei der Implementierung dieser Klasse in eine relationale Datenbank stiess man teilweise an Limiten. W\u00e4hrenddem PostgreSQL damit keine Probleme hat und seit scheinbar<\/em> jeher Tabellen mit mehreren Geometrien erstellen kann, hatte man da mit GeoPackage ein Problem.<\/p>\n\n\n\n
GeoPackage konnte nicht mehrere Geometriespalten in der gleichen Tabelle f\u00fchren und diese folglich als zwei Layer mit derselben Source im QGIS visualisieren.<\/p>\n\n\n\n
Ummodellieren ist keine Option<\/h2>\n\n\n\n
Da denkt man sich vielleicht, dass man einfach das Modell auch so bauen h\u00e4tte k\u00f6nnen, dass es funktioniert.<\/p>\n\n\n\n
CLASS Belasteter_Standort (ABSTRACT) =\n    Katasternummer : MANDATORY TEXT;\n    URL_Standort : MultilingualUri;\n    [...]\nEND Belasteter_Standort;\n\nCLASS Belasteter_Standort_Punkt EXTENDS Belasteter_Standort =\n    Geo_Lage_Punkt : GeometryCHLV95_V1.Coord2;\nEND Belasteter_Standort;\n\nCLASS Belasteter_Standort_Polygon EXTENDS Belasteter_Standort =\n    Geo_Lage_Polygon : MultiPolygon;\n    [...]\nEND Belasteter_Standort;\n<\/code><\/pre>\n\n\n\n
Doch diese Variante – so sch\u00f6n sie auch f\u00fcr INTERLISies (pendant zu Swifties) erscheint – ist weniger leserlich als die erste Variante. Und ein Modell soll ja bekanntlich auch f\u00fcr thematische Fachpersonen ein konzeptionelles Dokument zum Verst\u00e4ndnis der Datenstruktur sein.<\/p>\n\n\n\n
Weiter hat mir mal einer der Tool-Entwickler gesagt, wenn er modelliert, dann modelliert er und nimmt keine R\u00fccksicht darauf, ob die Tools es handhaben k\u00f6nnen oder nicht. Sonst bleibt man ja auch in der Tool-Entwicklung stehen. Auch das stimmt nat\u00fcrlich.<\/p>\n\n\n\n
Und doch, ein Modell wie das des Katasters der Belasteten Standorte nicht in einem GeoPackage implementieren zu k\u00f6nnen, war eine sehr m\u00fchsame Einschr\u00e4nkung. Und die Bundesmodelle sind nun einmal vorgegeben und man kann nicht einfach nach belieben daran herumschrauben.<\/p>\n\n\n\n
Deshalb kommen die Tools<\/h2>\n\n\n\n
Der Zugzwang bestand also bei den Tools und um eine GeoPackage-Tabelle mit solchen Mehrfachgeometrien in QGIS bearbeiten zu k\u00f6nnen, war gleich der ganze Stack involviert:<\/p>\n\n\n\n