Aktuell bietet der ilivalidator bereits diverse Konfigurationsmöglichkeiten, sei es mit Hilfe von Parameter beim Aufruf, Konfigurationsdateien oder erweiterten Modellen. Auf diese Weise lässt sich das Verhalten bei der Validierung beeinflussen, wodurch zum Beispiel auch bestimmte Fehler toleriert werden können. Für einige Tests lassen sich so statt Fehler auch nur Warnungen ausgeben, aber nicht für alle.
Für uns wäre es praktisch, die Validierung so konfigurieren zu können, dass für bestimmte Klassen oder auch nur Attribute (inkl. Geometrie) generell nur Warnungen zurückgegeben werden. Gibt es diese Möglichkeit bereits und ich habe sie übersehen? Falls nicht, gibt es bereits ähnliche Anforderungen/Bestrebungen?
Konkret sind bei uns in letzter Zeit die folgenden beiden Fälle aufgetreten:
OID wird nicht korrekt im Format STANDARDOID geliefert
Liniengeometrie enthält Self-intersections
In beiden Fällen wurden die Fehler korrekt erkannt. Da diese jedoch nicht kritisch im Bezug auf die Nutzung der Daten sind, würden wir die Daten für eine Übergangszeit gerne trotzdem als „valide“ durchgehen lassen, die Datenlieferanten aber durch eine Warnung auf die Fehler hinweisen und zur Bereinigung auffordern.
Beide Fälle würde ich genau nicht akzeptieren. Die OID nicht, weil das mE schnell side effects haben kann, an die man nicht denkt (import/export, foreign keys). Self-Intersections weil mir das früher oder später immer um die Ohren fliegt. Geos/Jts/Postgis garantieren dir explizit kein korrektes Arbeiten mit fehlerhaften Geometrien. Geometrie-Geschichten führen auch immer wieder zu den sonderbarsten Situationen, z.B. QGIS, das Geometrien je nach Zoomstufe nicht mehr anzeigt, weil self-intersection. Oder QGIS-Server, der am Rad dreht, weil fehlerhafte Geometrie.
Unser Ziel dahinter ist eben genau die Datenqualität zu steigern und den ilivalidator als massgebendes Tool zur Prüfung zu etablieren.
Mir ist bewusst, dass fehlerhafte Geometrien und falsche IDs zu Problemen führen können, aber die Realität in den Daten sieht leider nun mal anders aus. Wenn wir heute nur noch mit dem ilivalidator korrekt validierte Daten akzeptieren würden, bekämen wir (etwas überspitzt formuliert) erst einmal gar keine Daten mehr.
Deshalb würden wir die Validierung gerne temporär mit Warnungen lockern und den Datenlieferanten eine Frist zur Elimination der Warnungen einräumen. Die Validierung könnte dann Schritt für Schritt wieder verschärft und die Datenqualität gesteigert werden.
Nicht, dass wir Heilige wären, aber wir sind wieder strenger geworden. Und ich glaube wir geben heute auch noch Daten ab, die nicht fehlerfrei (im Sinne von ilivalidator meldet keine Fehler) sind. Weil es eben bequem ist, Zeugs auszuschalten und dann geht es vergessen. Und die Prüfsoftware wird immer komplizierter.
Spontan fällt mir nur noch ein nachgelagertes Parsen des XML-/CSV-/TXT-Logfiles ein. Dort wird dann gemäss eigenen Regeln entschieden, ob was noch i.O. ist oder nicht. Ginge aber nur, wenn irgendwo integriert und nicht beim Lieferant in der Konsole.
Ah und insbesondere die beiden von dir genannten Fehler würde ich nicht akzeptieren. Wenn ein TEXT ein Zeichen zu lange wäre, wäre mir das noch eher egal. Aber die möglichen sehr negativen Impacts der Self-Intersections (und eventuell OID) würde ich nicht akzeptieren.
@kdeininger Meine Erfahrungen decken sich mit denjenigen von @edigonzales. Es braucht seitens der Validierungsstelle sehr viel Zeit und Fachwissen, um zusammen mit dem Datenlieferanten zu validen Daten zu kommen. Und speziell betreffend die STANDARDOID liegt das Problem häufig auf der Export-Schnittstelle des Systemlieferanten. Wenn man das nicht angeht, so wird jeder Export fehlerhaft bleiben - auch bei der zehnten Ermahnung…
@kdeininger Bzgl. OID-Prüfung: Die folgende „Lösungs-Idee“ für einen ähnlichen Fall habe ich kürzlich mit einem Anwender diskutiert:
Über die Anpassung einer lokal vorliegenden Modelldatei kann die OID-Prüfung entschärft werden:
OID Spezifikation modifiziert (oder ganz auskommentiert):
CLASS SIA405_BaseClass (ABSTRACT) EXTENDS Base_LV95.BaseClass =
!! BaseClass für alle Oberklassen (Superclass) mit Metaattributen
!!OID AS STANDARDOID;
Anschliessend über --modeldir die Interpretation der modifizierten Modelldatei forcieren: --modeldir ".\models;https://models.interlis.ch"
