INTERLIS Constraints #2: Wenn Constraints auf den Prüfstand müssen

Moderne Produktions-Modelle sind voll von Constraints

INTERLIS-Datenmodelle wagen vermehrt den Spagat, sowohl taugliche Produktionsmodelle wie auch verlässliche Validierungsmodelle zu sein. Ein Indiz dafür ist, dass zusätzliche Constraints überall dort eingesetzt werden, wo das Modell ursprünglich bewusst zurückhaltend streng definiert wurde. Diese Constraints decken so genau den Bereich ab, welcher durch weniger strenge und dadurch häufig simplere Modellierung entsteht und potentiell Widersprüchlichkeiten oder andere Qualitätseinbussen verursacht.

Dadurch bekommen Constraints eine wichtige Bedeutung und deren einwandfreie Funktion ist entscheidend, damit die Daten-Qualität nicht unter der vereinfachten Modellierung leidet.

Auch Modellierer:innen machen Fehler

Im Zusammenhang mit dem neuen Datenmodell für die Naturgefahrenkarte des Kantons Solothurn hat GeoWerkstatt unter diesem Aspekt eine Vielzahl von teilweise komplexen Constraints implementiert. Greifen wir uns ein Beispiel auf: Das Modell ermöglicht beispielsweise widersprüchliche Jährlichkeitsangaben aufgrund zweier modelltechnisch getrennter Informationen (BefundSteinBlockschlag.IWCode und PQ_Jaehrlichkeit_SteinBlockschlag.Jaehrlichkeit), welche sich aber inhaltlich entsprechen müssen. Mittels folgendem Constraint wird ein solcher Widerspruch gezielt überprüft:

!!@ name = "CheckBefundSteinBlockschlagJaehrlichkeit-300"

!!@ ilivalid.msg = "Die Jährlichkeit stimmt nicht mit der Jährlichkeit der Prozessquelle überein."

MANDATORY CONSTRAINT NOT((IWCode == #rot_stark_300) OR (IWCode == #blau_mittel_300)) OR (PQ_Jaehrlichkeit_SteinBlockschlag_R->Jaehrlichkeit == 300);

Mit entsprechender Kenntnis und etwas Übung lassen sich solche Constraints effizient in die Modelle integrieren und ein INTERLIS-Compiler macht den/die ModelliererIn freundlich auf syntaktische Mängel aufmerksam. Speziell durch die Anwendung von Copy/Paste bei der Modellierung können aber schnell inhaltliche Fehler im Modell entstehen. So passiert es, dass der Constraint nicht mehr das prüft, was er eigentlich sollte. Das im Rahmen des besagten Projektes und im Auftrag des Amtes für Geoinformation des Kantons Solothurn spezifizierte und realisierte Testbed setzt genau hier an: Das Prinzip funktioniert wie folgt: Für jeden Constraint wird ein sogenannter Failcase konstruiert. Dieser Failcase stellt eine feine Modifikation des fehlerfreien Testoperats dar und umfasst lediglich das fehlerbehaftete Daten-Inkrement. In unserem Beispiel könnte dies nun die referenzierte Prozessquelle mit einer Jaehrlichkeit != 300 sein:

Das Testbed umfasst nun für jeden zu prüfenden Constraint ein Verzeichnis, welches das Daten-Inkrement enthält. Zur Laufzeit wird das Inkrement dann mit dem fehlerfreien Gesamtdatensatz vereinigt und validiert. Das erwartete Ergebnis dieser Validierung ist nun ein Fehler-Log-Eintrag mit Bezug zu genau dem getesteten Constraint. Findet der ilivalidator den Fehler nicht, so liegt entweder ein Problem mit dem Validator (bzw. dessen Parametern) oder dem Constraint vor. Somit ist das Testbed nicht mehr als eine Verzeichnisstruktur mit einem XTF für den fehlerfreien Gesamtdatensatz und je einem XTF-Inkrement pro Constraint. Die zweite Komponente is der Testbed-Runner – die Applikation, welches dieses Testbed auswertet. Der Runner ist in Java entwickelt, lässt sich standalone ausführen oder auch in Gradle integrieren und wird wie folgt aufgerufen:

 java.exe -jar .\interlis-testbed-runner-0.0.1.jar --validator ilivalidator-1.14.2-SNAPSHOT.jar .\Testbed-1

Alle Komponenten liegen als Open Source Entwicklungen vor: GeoWerkstatt/interlis-testbed-runner: Der Testbed-Runner ermöglicht das Testen von Constraints bzw. der dazugehörigen Methoden basierend auf Testdaten in einer definierten Ordnerstruktur. (github.com)

Fazit

Constraints werden immer mächtiger und sind bewährte Instrumente zur spezifischen Überprüfung der Datenqualität. Das Testbed ermöglicht es nun, diesen Qualitätsanspruch auch auf deren Definition und Funktionalität auszudehnen – man sorgt bereits in der Entwicklungsphase für eine umfangreiche Qualitätssicherung, in dem man jeden Constraint auf seine Wirksamkeit überprüft, noch bevor die ersten Daten vorliegen. Im Rahmen der Entwicklungen der Constraints für die Zusatzprüfungen beim Datenmodell Amtliche Vermessung (DMAV) mit dem ilivalidator ist es geplant, das Testbed von Beginn weg parallel mitaufzubauen.