Erweiterte INTERLIS Modelle in QGIS

QGIS Model Baker Release 7.6 ist draussen und bringt einige nützliche Features auf die Karte, die deine Arbeit mit INTERLIS Datenmodellen in QGIS noch effizienter machen. Eines dieser Features betrifft das Handling von erweiterten INTERLIS Modellen. Denn das konnte bisher ziemlich mühsam sein. Doch dem ist nicht mehr so…

Vom Problem zur Lösung

Wenn ein INTERLIS Modell erweiterte Klassen enthält, werden diese inklusive Basisklassen in der physischen Datenbank implementiert…

… und folglich Layer in QGIS erstellt.

Wenn dann die erweiterten Klassen die gleichen Namen haben, wird es schwierig sich zurecht zu finden. Und das war ziemlich oft der Fall.

Beispiel

Hier haben das fiktive Modell Ortsplanung_V1_1 mit dem Topic Konstruktionen und darin die Klasse Gebaeude. Im Kantonalen Modell wurde diese Klasse um einigen Attributen zu Kantonale_Ortsplanung_V1_1.Konstruktionen.Gebaeude erweitert. Und nun wurde auch noch ein Städtisches Modell gemacht, wo diese Klasse in zwei Topics weiter spezifiziert worden sind: Staedtische_Ortsplanung_V1_1.Freizeit.Gebaeude und Staedtische_Ortsplanung_V1_1.Gewerbe.Gebaeude.

Verwirrt? Wenn ja, dann keine Sorge. Denn genau darum geht es in dieser Erweiterung. Es existieren nun nämlich vier Implementierungen der Klasse Gebaeude. Und bisher hat Model Baker alle gleichberechtigt im QGIS Projekt angelegt.

Wenn nun die Klasse Gebaeude im Basismodell Ortsplanung_V1_1 eine Beziehung zur Klasse BesitzerIn hat – und so auch alle ihre Erweiterungen, wurden in QGIS für jede Erweiterung eine Relation erstellt.

Vor allem wenn Kataloge im Spiel sind, wurden die Formulare dazu ziemlich übel.

Dabei möchtest du doch gar nicht alle diese Layer sehen, sondern nur die, welche in dem Modell relevant sind, auf dem du gerade arbeitest. Musst du dich damit wirklich herumschlagen?

Nein.

Denn damit ist jetzt Schluss

Neu kannst du beim Erstellen des Projektes im Model Baker bestimmen, wie es optimiert werden soll.

Und schon wird dir ein schönes Projekt ohne überflüssige Layer generiert. Denn in diesem Beispiel arbeitest du auf dem Städtischen Modell mit den zwei spezifizierten Gebaeude Klassen.

… und auch die Relations sind jetzt schön schlank.

Strategien (Verstecken/Gruppieren)

Die irrelevanten Layer müssen aber nicht immer versteckt werden. Auch wenn dies der Standard ist, kann es sein, dass du zwar ein optimiertes Projekt, aber dennoch Layer nicht einfach „nicht sehen“ möchtest. Deshalb gibt es die Option, alle irrelevanten Layer in einer Gruppe zu „sammeln“.

Hier werden dann zwar die Relationen aller Layer erstellt, doch werden den Formularen die Widgets nicht hinzugefügt. Also bleibt das Arbeiten sehr angenehm.

Übrigens: Die Layer werden neu so benannt, dass ihre Namen einmalig sind. Das heisst, sobald ein gleichnamiger Layer besteht, wird der Topicname oder wenn nötig auch der Modellname vorangesetzt.

Wenn dir das schon reicht, kannst du dich nun sinnvollerem widmen 😊 Falls du aber gerne etwas mehr über die Funktionsweise wissen möchtest, geht’s jetzt weiter mit Hintergrundinfos 🧑‍🏭

Wie funktionierts?

In der Implementierungsphase bemerkte man schnell:

Der Model Baker kann nicht immer wissen, was die Benutzer:innen sehen möchten und was nicht.

Und da es fast unmöglich ist, alle Fälle zu berücksichtigen, mussten einige Annahmen getroffen werden.

Annahmen

Es wird angenommen, dass:

• Wenn du eine Basisklasse mit demselben Namen erweiterst, willst du sie „ersetzen“, sonst würdest du sie umbenennen.
• Wenn du eine Basisklasse mehrfach erweiterst (was man mit unterschiedlichen Namen tut), dann willst du sie ebenfalls „ersetzen“.
• Ausnahme der beiden Fällen: Wenn du die Klasse im gleichen Modell, aber in einem anderen Thema erweiterst (denn wenn du die Absicht hättest, sie zu „ersetzen“, hättest du sie zu ABSTRACT gemacht).

Ansatz

Also wurde – technisch formuliert – folgendes umgesetzt:

• Basisklassen mit gleichnamigen Erweiterungen gelten als irrelevant
• Basisklassen mit mehreren Erweiterungen gelten als irrelevant
• Ausser wenn die Erweiterungen im gleichen Modell sind, dann gelten sie nicht als irrelevant

Die Strategien

Je nach dem, was du dann bei der Projektgenerierung anwählst, wird eine der Strategien umgesetzt.

Strategie 1: Verstecken

• Basisklassen-Layer mit gleichnamigen Erweiterungen werden ausgeblendet und Basisklassen-Layer mit mehreren Erweiterungen ebenfalls. Es sei denn, die Erweiterung befindet sich im selben Modell, dann wird sie nicht ausgeblendet, sondern umbenannt.
• Beziehungen von ausgeblendeten Ebenen werden nicht erstellt und damit auch keine Widgets.

Strategie 2: Gruppieren

• Basisklassen-Layer mit gleichnamigen Erweiterungen werden in einer Gruppe zusammengefasst, Basisklassen-Layer mit mehreren Erweiterungen ebenfalls. Ausser wenn die Erweiterung im gleichen Modell ist, dann wird sie nicht gruppiert, sondern umbenannt.
• Beziehungen der gruppierten Ebenen werden erstellt, aber die Widgets werden nicht auf das Formular angewendet.

Und ohne Strategie?

Sofern ein Layer mit gleichem Namen besteht, wird das Topic vorangesetzt. Ist er noch immer nicht eindeutig, dann auch noch das Model.

Baskets für erweiterte Klassen

Kurzes Recap über Baskets (Behälter): Ein Basket ist eine Instanz eines Topics und die Schnittmenge zum aktuellen Dataset. Ein Basket kann Objekte basierend auf Klassen enthalten, die im Topic zulässig sind. Also sind das die Klassen, welche im aktuellen Topic definiert sind und die, welche in Topic definiert sind, das vom aktuellen Topic erweitert wurde. Wenn man nun Objekte im Basket des aktuellen Topics erfasst, muss man auch die Objekte der Klassen, die im Basistopic definiert sind, im Basket des aktuellen Topics erfassen.

Falls das jetzt etwas verwirrend klingt, haben wir gute News für dich:

In den optimierten Projekten werden zukünftig nur die relevanten Baskets angeboten.

Das heisst, auch wenn die Klasse in einem anderen Topic definiert ist, werden dem Layer nur die Baskets angeboten, in denen man auch wirklch erfassen möchte. Je nach gewählter Strategie sind das die Instanzen, auf denen man arbeitet.

Und das wars dann auch schon

Mehr Infos zur Umsetzung auch mit den betreffenden Modellen findest du in der Dokumentation und die Liste aller anderen tollen Features des Model Baker 7.6 im Changelog

Übrigens wurde dieses tolle Feature von der QGIS Anwendergruppe Schweiz finanziert. Also von der Community, also von dir. Vielen Dank 🙂