signedav/extended-model-optimization

Slides about extended model optimization in QGIS Model Baker

extended-model-optimization's Issues

Blogpost

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. Das konnte bisher ziemlich mühsam sein - ist nun aber Geschichte.

Was war das Problem?

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.

Ein Beispiel: Wir 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.

Nun hat die Klasse Gebaeude im Basismodell Ortsplanung_V1_1 eine Beziehung zur Klasse BesitzerIn und so auch alle ihre Erweiterungen. Folglich 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 Erweiterungen sehen, sondern nur die, welche in dem Modell relevant sind, auf dem du gerade arbeitest. Musst du dich wirklich damit herumschlagen?

Nein.

Denn damit ist jetzt Schluss

Neu kannst du beim Erstellen des Projektes im Model Baker bestimmen, wie das Projekt 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 seit neustem Release so benannt, dass sie einmalig sind. Das heisst, sobald ein gleichnamiger Layer besteht, wird der Topicname oder wenn nötig auch der Modellname vorangesetzt.

Wenn es dir nun schon reicht, das zu wissen, kannst du dich nun sinnvollerem widmen 😺 Falls du aber gerne etwas mehr über die Funktionsweise wissen möchtest, geht's jetzt weiter mit Hintergrundinfo.

Wie funktionierts?

In der Implementierungsphase bemerkten wir 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, gelten sie nicht 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.

Welche Baskets für erweiterte Klassen

Kurzes Recap über Baskets: Ein Basket (Behälter) 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 6.7. im Changelog

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