Interlis leicht gemacht #11

18 July 2016

Getreu dem Motto «Release early, release often» gibt es jetzt bereits die zweite Version von ilivalidator - dem OpenSource INTERLIS-Checker - zum Ausprobieren.

Um nicht immer die amtliche Vermessung als Testbeispiel zu verwenden, bastle ich mir zuerst ein paar Daten zusammen. Dazu baue ich vorhandene Daten des Kantons Solothurn in das Modell «Planerischer Gewässerschutz» des BAFU um.

UML-Diagramm

Als erstes mache ich mit ili2pg einen Schemaimport und lege leere Tabellen an, die ich später mit QGIS-Forms-and-Relations-Magie abfüllen werde. Ein Datenumbau mit SQL reicht leider nicht, da ich - zum Testen von ilivalidator - zusätzliche Daten erfassen will, die in den vorhandenen Daten des Kantons noch nicht vorhanden sind.

java -jar ili2pg.jar --dbhost localhost --dbdatabase rosebud2 --dbport 5432 --dbusr stefan --dbpwd ziegler12 --defaultSrsAuth EPSG --defaultSrsCode 21781 --modeldir http://models.geo.admin.ch --models PlanerischerGewaesserschutz_V1 --smart1Inheritance --expandMultilingual --createGeomIdx --createEnumTabs --nameByTopic --strokeArcs --createFkIdx --schemaimport --dbschema plan_gewaesserschutz

Abfüllen werde ich nicht das ganze Modell, sondern nur das Topic «GWSZonen». Und auch nur die Zonen der «Stöckli- und Wasserbergquelle» in der Gemeinde Bärschwil. Betroffen sind die Klassen «GWSZone», «Status» und «Dokument». Zusätzlich müssen einige Assoziationen erfasst werden. Mit QGIS geht das sehr elegant. Neu werden MANDATORY resp. NOT NULL Attribute farblich hervorgehoben:

Datenerfassung in QGIS

Für meinen Geschmack schon sehr viel Farbe. Aber wenigstens fällt es auf…​

Die vier erfassten Zonen der Quelle sehen so aus:

Zonen

Mit ili2pg können die erfassten Daten in eine INTERLIS/XTF-Datei exportiert werden:

java -jar ili2pg.jar --dbhost localhost --dbdatabase rosebud2 --dbport 5432 --dbusr stefan --dbpwd ziegler12  --modeldir http://models.geo.admin.ch --models PlanerischerGewaesserschutz_V1 --disableValidation --export --dbschema plan_gewaesserschutz gewaesserschutz.xtf

Mit xmllint kann die XML-Datei noch für das/mein Auge schöner formatiert werden:

xmllint --format gewaesserschutz.xtf -o gewaesserschutz.xtf

Die daraus resultierende INTERLIS/XTF-Datei kann mit ilivalidator mit einem einfachen Befehl in der Konsole gegenüber dem konzeptionellen INTERLIS-Modell geprüft werden:

java -jar ilivalidator.jar gewaesserschutz.xtf

Wurden keine Fehler gefunden, erscheinen folgende Zeilen in der Konsole:

ilivalidator ohne Fehler

In die INTERLIS/XTF-Datei baue ich nun bewusst vier Fehler ein. Und zwar vier Fehler, die ilivalidator bereits jetzt schon finden sollte:

  • Fehlendes MANDATORY-Attribut «Titel» in der Klasse «Dokument».

  • Zu langes Text-Attribut «OffizielleNr» in der Klasse «Dokument». Erlaubt sind nur 20 Zeichen.

  • Falscher numerischer Wert für das Attribut «Gemeinde» in der Klasse «Dokument». Erlaubt ist eine Zahl zwischen 0 und 9999.

  • Falscher Aufzähltyp für das Attribut «Art» in der Klasse «GWSZone».

Ein erneuter Aufruf von ilivalidator liefert in der Konsole folgendes Resultat:

ilivalidator mit Fehler

Es sollten mindestens zwei Dinge auffallen:

  • Es gibt neu in der Konsole vier Zeilen, die mit Error beginnen.

  • Die letzte Zeile endet mit Info: …​validation failed Anstelle von Info: …​validation done

Die vier Error-Zeilen geben auch Auskunft über die Art des Fehler und bei welchem Objekt (tid) der Fehler auftritt. Ebenfalls liefert ilivalidator die Zeilenummer. Bei XML ist diese aber oftmals nicht wahnsinnig hilfreich. Die Fehlermeldungen sind soweit sehr verständlich.

Die Meldungen auf der Konsole können auch in eine Logdatei geschrieben werden:

java -jar ilivalidator.jar --log result.log gewaesserschutz.xtf

Es besteht zudem die Möglichkeit die Meldungen in ein bewusst sehr einfach gehaltenes INTERLIS-Modell zu schreiben. Das Modell ist auf «Shapefile-Niveau», dh. der Benutzer muss nicht mühsam Daten umbauen, um sie visualisieren zu können.

java -jar ilivalidator.jar --xtflog result.xtf gewaesserschutz.xtf

Mit ili2gpkg könnte jetzt die resultierende Log-XTF-Datei in eine GeoPackage-Datei umgewandelt werden, um die Fehler und Warnungen in QGIS anzeigen zu lassen.

Manchmal möchte man aber Fehler in der Transfer-Datei tolerieren oder sogar ignorieren. Dazu gibt es bereits jetzt schon die Möglichkeit dies über eine TOML-Datei zu steuern. In meiner TOML-Konfiguration schalte ich die type-Prüfung des Attributes «Art» in der Klasse «GWSZone» aus. Dh. es wird nicht mehr geprüft, ob der Wert des Attributes im Aufzähltyp vorkommt. Zudem stufe ich die MANDATORY-Prüfung des Attributes «Titel» in der Klasse «Dokument» zu einer Warnung herunter. Der Aufruf mit einer TOML-Konfiguration ist wie folgt:

java -jar ilivalidator.jar --config gewaesserschutz.toml gewaesserschutz.xtf

Neu werden nur noch drei Fehler gefunden, wobei ein Fehler nur als Warnung attribuiert ist:

ilivalidator mit TOML

Die Steuerung kann auch direkt im Datenmodell mit Metaattributen vorgenommen werden.

In der Anleitung zu ilivalidator gibt es noch mehr Tipps & Tricks und ein kleines Beispiel-Datenmodell mit Datensatz.

So geht INTERLIS-Datenprüfung im 21. Jahrhundert.

Posted by Stefan Ziegler. | INTERLIS , Java , ilivalidator , ili2pg , ili2gpkg