8 ilivalidator - geostandards-ch/ili2db_ilivalidator_de GitHub Wiki
ilivalidator ist ein Programm, das die Übereinstimmung von Daten im INTERLIS-Format (.itf oder .xtf) mit einem INTERLIS-Modell (.ili) validieren kann. Es wurde wie ili2db von der Firma Eisenhut Informatik AG entwickelt.
Die Benutzeroberfläche des ilivalidator ist anwenderfreundlich und gegenüber der Befehlszeilen-Schnittstelle vorzuziehen. Aus diesem Grund stützen wir unsere Dokumentation ausschliesslich auf das ilivalidator-GUI.
Um das INTERLIS Validator-GUI zu starten, doppelklicken Sie einfach auf die heruntergeladene .jar-Datei. Zum Beispiel "ilivalidator-1.11.12.jar".
Um das GUI auf Deutsch anzuzeigen, müssen Sie den folgenden Befehl verwenden:
java -Duser.language=de -jar ilivalidator-1.11.12.jar
Folgendes Fenster erscheint:
Auf der Benutzeroberfläche finden wir die folgenden Felder:
| Feld | Erklärung |
|---|---|
Datendatei |
Die zu validierende .itf- oder .xtf-Datei |
Datenumfang vollständig |
Hiermit wird angegeben, ob das Tool externe Referenzen finden soll. Zum Beispiel, ob ein Attributwert in einem XML-Katalog existiert. |
Modellnamen |
Das oder die Modelle, die zur Validierung der Daten verwendet werden sollen. Wenn dieses Feld leer gelassen wird, sucht das Tool nach den angegebenen Modellen in der Datendatei. Es sucht: im selben Ordner, im Stammordner des Tools und online. |
Log-Datei |
Falls gewünscht, kann ein Pfad angegeben werden, um eine Logdatei der Validierung zu erzeugen. |
Xtflog-Datei |
Ähnlich wie oben, aber die Logdatei wird im INTERLIS-Format (.xtf) erstellt. Die Struktur dieser INTERLIS-Datei wird hier festgelegt: https://github.com/claeis/ilivalidator/blob/master/docs/ilivalidator.rst#modell-iliverrors |
Konfigurationsdatei |
Es ist möglich, eine .ini-Konfigurationsdatei bereitzustellen, die angibt, welche Validierungen durchgeführt und welche ausgelassen werden sollen. |
Grosses weisses Fenster unten |
In diesem Fenster werden das Log und das Ergebnis der Validierung angezeigt. |
Im folgenden Beispiel möchten wir überprüfen, ob die Transfer-Datei Auengebiete_KB1.xtf mit dem Modell Auengebiete_KB1.ili übereinstimmt. Wir konfigurieren die Benutzeroberfläche wie folgt:
Beachten Sie, dass das Feld Modellnamen leer gelassen wird, da unser Modell in der .xtf-Datei referenziert wird:
Bitte beachten Sie auch, dass sich dieses Modell im selben Ordner wie unsere Transfer-Datei befindet. Dies ist eine Voraussetzung:
Wir starten die Überprüfung mit einem Klick auf "validieren". Wir sehen, dass das Tool das Modell gefunden hat:
Die Schlusszeile “Info: … validation done” weist darauf hin, dass der Validierungsprozess abgeschlossen ist und kein Fehler gefunden wurde:
Die Schlusszeile “Info: … validation failed” weist darauf hin, dass der Validierungsprozess abgeschlossen ist und Fehler gefunden wurden:
Im Folgenden zeigen wir einige Logzeilen/Fehlermeldungen, die anzeigen, dass die Transfer-Datei nicht vollständig korrekt ist.
| Datei | Resultat |
|---|---|
|
Das Objekt RefObjBlattError existiert nicht im Modell weshalb der ilivalidator ein Fehler ausgibt. |
|
Die eindeutige Kennung wird nicht eingehalten. |
|
Der Wert des Attributs wird nicht erkannt. Ilivalidator weist ihn zurück. |
|
Ein obligatorisches Attribut kann nicht leer gelassen werden. |
Wenn Fehler festgestellt werden, gibt das Log einige Details über ihre Gründe und ihren Standort an.
Der folgende Link enthält weitere Informationen über die Art der Fehler, die auftreten können: https://github.com/claeis/ilivalidator/blob/master/docs/ilivalidator.rst#hinweise-zu-fehlermeldungen
Um eine Logdatei zu erzeugen, muss mindestens eines der Felder Log-Datei oder Xtflog-Datei ausgefüllt werden.
Die Logdateien sind nach Abschluss der Validierung im angegebenen Ordner verfügbar:
Im Feld Konfigurationsdatei können Sie eine Konfigurationsdatei definieren, die eine Beschreibung der spezifischen Kontrollen enthält, die bei bestimmten Elementen der Vorlage durchgeführt oder nicht durchgeführt werden sollen.
Nehmen wir als Beispiel die Vorlage Auengebiete_KB1.xtf, in die zwei Fehler eingebaut wurden:
-
Das Attribut ObjNummer, das in der Vorlage obligatorisch ist, wird für ein Objekt auf NULL gefüllt:
-
Das Attribut Inkraftsetzungsdatum, das vom Typ XMLDate ist, wird durch einen ungültigen Wert leer ersetzt:
Mit diesen Ergänzungen bringt das Tool iliValidator logischerweise die folgenden Fehler hervor:
Wir werden nun eine Konfigurationsdatei verwenden, in der wir zwei Ausnahmen definieren, damit diese Fehler nur als Warning ausgegeben werden:
-
Für das Attribut ObjNummer, multiplicity = warning: Fehler bei der Multiplizitätsprüfung für dieses Attribut werden als Warnung ausgegeben.
-
Auf dem Attribut Inkraftsetzungsdatum, type= warning: Wenn ein Attributwert nicht dem Typ des Attributs entspricht, wird der Fehler als Warnung ausgegeben.
Wenn Sie warning durch off ersetzen, würden diese Fehler im Logfile gar nicht erst ausgegeben werden.
Die Konfigurationsdatei (TOML-Format) ist eine Textdatei mit der Erweiterung .ini. In unserem Beispiel ist ihr Inhalt wie folgt :
["PARAMETER"] # Globale Validator Einstellungen # Validierung generell ausschalten # on/off validation="on" ["Auengebiete_KB1.Auengebiete_KB.Auengebiet_KB1.ObjNummer"] # Multiplizitaetpruefung ein/ausschalten bzw. nur als Hinweis. # z.B. ob bei MANDATORY ein Wert vorhanden ist, oder nicht bzw. # bei BAG/LIST ob die entsprechende Anzahl Strukturelemente vorhanden ist # on/warning/off multiplicity="warning" ["Auengebiete_KB1.Auengebiete_KB.Auengebiet_KB1.Inkraftsetzungsdatum"] # Datentyppruefung ein/ausschalten bzw. nur als Hinweis. # z.B. ob eine Zahlenwert innerhalb des Bereichs ist, oder ein # Aufzaehlwert dem Modell entspricht oder die Flaechen eine # Gebietseinteilung sind usw. # on/warning/off type="warning"
Wenn man das Werkzeug iliValidator erneut verwendet, aber den Parameter Konfigurationsdatei setzt, funktioniert die Validierung fehlerfrei :
Wenn das Feld Datenumfang vollständig aktiviert ist, werden externe Referenzen berücksichtigt, die beispielsweise in einer xml-Datei gespeichert sind. Diese Datei muss vorhanden sein, sonst kann das Tool die Daten nicht validieren und es folgt eine entsprechende Fehlermeldung.
Mit dem Tool können wir über die Menüleiste auf die folgenden Optionen zugreifen:
Optionen, die "(ITF)" enthalten, beziehen sich nur auf INTERLIS 1.
Es gibt drei Optionen, die eine weniger intensive Prüfung ermöglichen:
-
Die aktivierte Option Multiplizität nicht prüfen ermöglicht es, Fehler bezüglich der Eindeutigkeit von IDs zu ignorieren. Ausserdem wird dadurch auch bewirkt, dass MANDATORY-Attribute nicht als Fehler gemeldet werden, wenn der Wert leer ist. Dies betrifft auch die Kardinalität von Beziehungen, die nicht als Fehler gemeldet wird, wenn sie nicht erfüllt ist.
-
Die aktivierte Option CONSTRAINTs nicht prüfen bewirkt, dass die INTERLIS-Constraints des Modells nicht geprüft werden. Beispiel: der Wert von Attribut A muss im Bereich X liegen, wenn Attribut B den Wert Y hat?
-
Die aktivierte Option AREA-Topologie nicht prüfen verhindert die Überprüfung der Topologie von AREA-Geometrien.
Die anderen im Tool verfügbaren Optionen sind komplexer und würden den Rahmen dieser Dokumentation überschreiten. Für weitere Informationen sollte man sich an die offizielle Dokumentation des Tools wenden: