INTERLIS Constraints: Strenge aber flexible Alleskönner im Dienste der Datenqualität (Folge 1)

Constraints hatten lange nicht den Ruf, den sie verdienen, in modernen INTERLIS Datenmodellen tauchen sie nun aber vermehrt auf, um gezielte Qualitäts-Anforderungen zu definieren. Diese Blogserie beleuchtet anhand einiger Beispiele deren Potential im Zusammenhang mit dem ilivalidator.

Constraints stellen in INTERLIS2 Modellen ein flexibles Instrument dar, um spezifische Qualitäts-Aspekte in den Daten zu validieren. Solche Constraints ermöglichen Validierungen, welche das Regelset im Rahmen der typischen Modellierung deutlich erweitern. Damit können beispielsweise nicht mehr nur Datentypen, maximale Zeichenlängen oder zwingende Attribute überprüft werden, sondern es sind mit einfachen Mittel auch inhaltliche Vergleiche (zB. beginnt der Text mit dem Präfix «ABC123»?) , Plausibilitätschecks (zB. Liegt das Datum1 wirklich vor dem Datum2?) oder Existenzprüfungen (zB. existiert diese Auftragsnummer auch wirklich in einer anderen Klasse?) möglich.Mit INTERLIS 2.4 lassen sich solche Constraints nicht nur auf einzelne oder ein Set von Attributen in Klassen anwenden, sondern auch auf Beziehungsattribute oder global definierte Datentypen. Aber dazu später.

Zum Einstieg betrachten wir ein einfach verständliches aber eindrückliches Beispiel, welches zeigt, wie Punkt-Koordinaten dahingehend geprüft werden, ob sie innerhalb einer gegebenen Flächengeometrie – in diesem Zusammenhang innerhalb der Kantonsfläche des Kantons Bern aus SWISSBOUNDARIES - liegt.

Diese Prüfung wird als MANDATORY CONSTRAINT direkt in die entsprechende Klasse implementiert und prüft so jeden einzelnen Datensatz in Bezug auf die oben beschriebene Bedingung.
Die Bedingung selbst nutzt für diese Aufgabe eine Funktion namens IsInsideExternalDataset(), welche gegenüber einem spezifischen Referenzobjekt prüft, ob der Punkt innerhalb oder ausserhalb der Fläche liegt. Die Funktion für eine solche Prüfung wurde in der Open Source Bibliothek GeoW_FunctionsExt bereitgestellt und stellt eine Erweiterung der standardmässig vorhandenen Funktionen dar.

Unser Testdatensatz umfasst zwei nur wenige Meter auseinanderliegende Punkte im Gebiet Bucheggberg, der eine innerhalb und der andere ausserhalb der Berner Kantonsfläche.

Schauen wir uns die Arbeitsweise des ilivalidators etwas genauer an: Jeder Datensatz wird der besagten Funktion übergeben, diese führt die räumliche Abfrage gegenüber den Objekten mit den TID’s 9253, 9256 und 9216 der Klasse TLM_Kantonsgebiet aus dem SWISSBOUNDARIES-Datensatz durch. Der Rückgabewert der Funktion ist WAHR oder FALSCH und dient so direkt als Kriterium des Constraints.
Entsprechend finden wir die dazugehörigen Logeinträge:

Info: second validation pass...
Info: validate mandatory constraint NPL_mini.Geobasisdaten.Objektbezogene_Festlegung.CheckInsideKtBE...
Error: line 13: NPL_mini.Geobasisdaten.Objektbezogene_Festlegung: tid 1: Der Punkt liegt NICHT im Kanton Bern!
Info: object count 2 (structured elements 0)

Die hier etwas genauer betrachtete Funktion stammt wie erwähnt aus der Funktionsbibliothek GeoW_FunctionsExt, welche als Open Source Projekt (https://github.com/GeoWerkstatt/geow-interlis-functions) laufend weiterentwickelt wird, und Methoden bereitstellt, welche durch die defaultmässig vorhandenen INTERLIS Funktionen nicht abgedeckt sind.

Und genau diese Standard-Funktionen schauen wir uns in der nächsten Folge an. 

Und übrigens: Am INTERLIS Anwender:innen-Treffen am 22. November in Olten gibt’s im Nachmittagsprogramm spannende, kostenlose Workshops zu Constraints. Alle Infos und Anmeldung unter https://interlis.discourse.group/t/3-interlis-anwender-innen-treffen/151.