Ilivalidator: "Warning" unterscheiden?

Im Log des ilivalidator werden die Zeilen ja mit „Error / Info / Warning“ begonnen und damit definiert. Die „Warning“ gibt es aber für „Systemprobleme“ (z.B. irgendein Repo nicht gefunden) und für „Datenprobleme“ (irgendwas in der Interlisdatei klemmt.) Mit Info ist es ähnlich, aber solange alles OK ist interessiert die Info weniger.

Jetzt habe ich immer viele Log-Dateien, die ich auf „Warning“ zu prüfen bzw. zu durchsuchen habe - und da interessiert mich eigentlich nur die Warnings zu meinem Dateiinhalt, aber die Suchfunktion bringt natürlich alle Warnungen.

Ich möchte daher so auf die Schnelle zur Diskussion stellen, ob es nicht vorteilhaft wäre, diese Zeilenkennungen etwas spezifischer zu halten. Damit kann man sich leichter zurechtfinden ..

Wie sehen andere das?

@peter2 Das QGIS Plugin xtf logchecker erlaubt es diese „Warning“ für die igCheck error log files einfach zu filtern. Diese Funktion könnte man auch für die ilivalidator error logs portieren. Interesse?

Ich finde dese Unterscheidung Error / Info / Warning grundsätzlich gut. Wenn es Error hat, dann ist noch etwas nicht gut - Warning weisst mich darauf hin, dass je nach fachlicher Anforderung etwas nicht stimmt. Info hilft einfach zu sehen, wo man noch Dinge verbessern könnte oder eine bestimmte Situation ist. So jedenfalls verwendet es der VSA in seinen Modellen.

Ich kenne das Problem und löse es über Regex. Mehr Infos unter findstr /? unter Windows CMD oder find unter Linux.

So ein Filter wie in QGis schaut gut aus - und ist sicher auch benutzerfreundlich. Mir würde es gefallen.

RegEx ist natürlich ein technisch saubere Lösung, aber eher für „Fortgeschrittene“. Der Durchschnittsanwender wird dabei eher kämpfen müssen.

Diese Anforderung (Unterscheidung nach „Systemproblemen“ und „Datenproblemen“) ist nicht neu und poppt in regelmässigen Abständen wieder auf. Offenbar lässt sich das programmtechnisch aber nicht so einfach umsetzen. Das kommt wohl daher, dass die Code-Basis über die letzten 25 Jahre kontinuierlich gewachsen ist. Zudem lassen sich nicht alle Fehler/Warnings eindeutig einer der beiden vorgeschlagenen Kategorien zuweisen.

Seit der Version 1.14.1 (2023) lässt sich mit der Option --csvlog das Logfile als CSV ausgeben und damit einfacher weiterverarbeiten (oder man verwendet sogar --xtflog, um komplett in der modellbasierten Welt zu bleiben).