Support für ilidata:-Option

[olivergrimm]

Seit Version 1.13.4 (evtl. früher) unterstützt der ilivalidator die Angabe einer voll-qualifizierenden Katalog-ID über ilidata:Dataset.id um externe Referenzen gegenüber Katalogen prüfen zu können:

Beispiel:
java -jar .\ilivalidator-1.13.4-SNAPSHOT.jar --allObjectsAccessible ilidata:sh.geo.models.Hauptnutzung_CH "obe_Nutzungsplanung_SH_LV95_V4_0.XTF"

Die ilidata:-Angabe bezieht sich auf die Id des entsprechenden ilidata-Eintrags (Analogie zum Beispiel: https://models.geo.sh.ch/ilidata.xml)

Es soll geklärt werden, ob ein Bedarf besteht, dass diese Option auch beim ilicop nutzbar gemacht werden soll.

(siehe auch: claeis/ilivalidator#382 (comment))

---

Aktuell unterstützt der ilicop die Validierung gegenüber externen Katalogen über die Konfigurationsoptionen

Variante 1:
-Interpretation der Kataloge wenn sie im ZIP als XML mitgeschickt werden

Variante 2:
-Konfig catalogs:-Volume und serverseitige Bereitstellung der XML-Dateien
-Prüfen mittels Option --AllObjectsAccessible

[olivergrimm]

#156

[beistehen]

Im Hinblick auf die "Organisationsliste" des VSA (und zukünftig des SIA und SVGW und allenfalls LKCH) würde ich die Unterstützung von ilidata begrüssen. Diese Daten sind häufigen Änderungen unterworfen und das manuelle Herunterladen und mitschicken mit den zu validierenden Daten ist mühsam (und für Endnutzer nicht immer nachvollziehbar).

Eine prüfenswerte Idee (credit to @edigonzales) finde ich auch die Verwendung eines metaconfig-files:

# metaconfig.ini
[CONFIGURATION]
ch.interlis.referenceData=ilidata:vsa_organisationen

und dann

java -jar ilivalidator.jar --allObjectsAccessible --metaConfig metaconfig.ini abc.xtf

[romefi]

Ich würde gerne noch prüfen, ob man überhaupt explizit angeben muss, gegenüber welchen Katalog geprüft werden muss, wenn dieser in einem ilidata.xml geführt wird.

• Muss ein XTF immer gegenüber dem im ilidata.xml angegebenen Katalog geprüft werden? Kann es sein, dass das XTF in bestimmten Use Cases gegenüber einem anderen Katalog geprüft werden muss?
• Weiss man, gegenüber welchem Katalog geprüft werden muss, wenn im ilidata.xml auch alte Katalog-Versionen zu einem Modell aufgeführt sind? Wird immer gegenüber dem aktuellsten geprüft?

Viele Unsicherheiten, welche die Stabilität der Checks gefährdet. So gesehen könnte der Vorschlag von @beistehen im Moment die beste Lösung sein. Das metaconfig.ini wird auf der ilicop-Instanz geführt und definiert, welches Modell gegenüber welchen Katalogen geprüft werden soll.

Wichtig für mich ist vor allem, dass diejenige Person, welche die Daten prüfen möchte, im Regelfall nicht wissen resp. angeben muss, gegenüber welchen Katalog geprüft wird. Es kann aber auch sein, dass die Daten gegenüber einer bestimmten Katalogversion geprüft werden müssen. Z.B. bei den MGDM der landwirtschaftlichen Bewirtschaftung ändern die Kataloge jährlich (meist rückwärtskompatibel). D.h. ich will ein XTF gegenüber dem Katalog von dem Jahr vergleichen, der mit den Daten im XTF übereinstimmt. Würde das immer noch gehen, indem z.B. der Katalog doch im ZIP mitgeliefert wird? Würde damit das metaconfig.ini übersteuern?

[edigonzales]

Wichtig für mich ist vor allem, dass diejenige Person, welche die Daten prüfen möchte, im Regelfall nicht wissen resp. angeben muss, gegenüber welchen Katalog geprüft wird.

Wir haben es so gelöst, dass es "Prüfprofile" gibt, die zudem steuerbar über einen Query-Parameter sind:

http://ilivalidator.sogeo.services/?t=drainagen

In der Combobox kann man natürlich immer auch noch das (falsche) wählen. Im Standardmodus kann man dann alles hochladen, was man will und alles mit (meta)config-files irgendwie überschreiben.

Die Idee war, dass man den Kunden, die explizit Drainaigen prüfen müssen, den Link mit "t=drainagen" schickt und sie den bookmarken können.

[olivergrimm]

Wir haben uns konzeptionell mit der Entwicklung dieser Erweiterung auseinandergesetzt und den Aufwand geschätzt:
Die geplante Umsetzung ist wie folgt vorgesehen:

• Modelle werden aus XTF Header geparst
• via ilimodels-Logik werden zugehörige Kataloge eruiert
• Allenfalls lokal vorliegende Kataloge (aus Upload oder Katalog-Verzeichnis) werden geprüft und Priorität festgelegt*
• Anpassung des Validierungsaufrufs

• Vorschlag: Katalog in Zip -> Lokale in Mount -> ilidata:Repository

Geschätzter Aufwand: ca. 70h (Spez, Entwicklung, QS, Doku, PL // CHF 11'000.-)

[beistehen]

• Modelle werden aus XTF Header geparst

Hinweis: gelegentlich sind in der HEADERSECTION Modelle referenziert, die in den Daten gar nicht angewandt werden. Siehe dazu auch claeis/ilivalidator#287 und ff.

[romefi]

@olivergrimm habt ihr eine Idee, wie ihr an die Modelle kommt, wenn die HEADERSECTION nicht zuverlässig ist? Das wäre aus meiner Sicht recht zentral, wenn die Lösung funktionieren soll.

[Philippluca]

@romefi @beistehen Grundsätzlich sollten die veröffentlichten Katalog auf den Repositories zu keinen Fehlern führen oder verstehe ich das falsch? Zusätzliche Katalog-Daten sollten daher nicht zu einem Fehlerhaften Validierungsresultat führen. Die Kataloge halten nach meinem Verständnis meist auch keine komplexen Daten, womit der Performance-Impact wohl vernachlässigbar ausfällt.

[edigonzales]

Ich glaube man muss vom Fall ausgehen, dass gar keine Modelle in der Headersection stehen. Nicht nur zusätzliche. Sent from Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: Philipp Lüthi ***@***.***> Sent: Wednesday, April 10, 2024 4:44:50 PM To: GeoWerkstatt/interlis-check-service ***@***.***> Cc: Stefan Ziegler ***@***.***>; Mention ***@***.***> Subject: Re: [GeoWerkstatt/interlis-check-service] Support für ilidata:-Option (Issue #157) @romefi<https://github.com/romefi> @beistehen<https://github.com/beistehen> Grundsätzlich sollten die veröffentlichten Katalog auf den Repositories zu keinen Fehlern führen oder verstehe ich das falsch? Zusätzliche Katalog-Daten sollten daher nicht zu einem Fehlerhaften Validierungsresultat führen. Die Kataloge halten nach meinem Verständnis meist auch keine komplexen Daten, womit der Performance-Impact wohl vernachlässigbar ausfällt. — Reply to this email directly, view it on GitHub<#157 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAVDXOFBSE6FYOSTN5TCNQTY4VF6FAVCNFSM6AAAAAA44TVFAGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBXG42TEOJTHE>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[olivergrimm]

dann eruieren wir die involvierten Modelle über ein Parsing der Datasection.

[beistehen]

@romefi @beistehen Grundsätzlich sollten die veröffentlichten Katalog auf den Repositories zu keinen Fehlern führen oder verstehe ich das falsch? Zusätzliche Katalog-Daten sollten daher nicht zu einem Fehlerhaften Validierungsresultat führen. Die Kataloge halten nach meinem Verständnis meist auch keine komplexen Daten, womit der Performance-Impact wohl vernachlässigbar ausfällt.

@Philippluca In einer idealen Welt sind auch die Modellrepos fehlerfrei. In der Realität sieht die Sache anders aus...
Man kommt mit dem heutigen ilivalidator wohl nicht umhin, die Kataloge immer mitzuprüfen. Zwar kann man sie lokal vorhalten (und aufgrund einer Änderung des md5-Wertes aktualisieren), doch scheint mir der Download nicht der entscheidende Faktor zu sein bei der Performance.

Weiter möchte ich zu bedenken geben, dass zukünftige Modelle auch viel mehr als 1 Katalog haben könnten. Da könnte dann der Impact auf die Performance plötzlich grösser werden.

[edigonzales]

Ich glaube ich verstehe den Wunsch, dass niemand zusätzlich pro Thema machen muss. D.h. der Benutzer muss die Datei hochladen und es wird automatisch der passende Katalog gewählt. Zudem soll auch der Online-Checker-Anbieter nicht pro Thema eine Konfiguration vornehmen müssen. Da sehe ich aber mindestens das Problem, dass der Benutzer nicht sehr transparent andere Prüfresultate bekommt, als wenn er es lokal testet, weil ihm dort dieser Automatismus fehlt.

Der Automatismus funktioniert für das Eruieren des Katalogs, was ist aber, wenn man für das Thema weitere vordefinierte Konfigurationen hat? Z.B. Fehler zu Warnungen degradieren?

Das Parsen der Datasection reicht m.E. auch nicht für den Usecase, dass ein XTF externe Refernzen aufweist und man diese prüfen will. Z.B. Ein VSA-DSS-mini-Datensatz will man komplett prüfen. D.h. man muss den Datensatz "VSA-Organisationen" vorliegen haben. Von dem steht aber nichts im XTF:

Das Wissen dazu steckt nur im Modell. Woher wüsste man nach dem Parsen der Datasection, WO dieser Organisationsdatensatz heruntergeladen werden kann?

[romefi]

Das Wissen dazu steckt nur im Modell. Woher wüsste man nach dem Parsen der Datasection, WO dieser Organisationsdatensatz heruntergeladen werden kann?

Müsste das nicht im ilidata.xml von VSA-DSS definiert sein? Ist ja eigentlich nichts anderes wie ein Katalog, dort findet die Modellverknüpfung auch mit dem ilidata.xml statt. Zumindest in diesem konkreten Fall.

In einer idealen Welt sind auch die Modellrepos fehlerfrei. In der Realität sieht die Sache anders aus...
Man kommt mit dem heutigen ilivalidator wohl nicht umhin, die Kataloge immer mitzuprüfen. Zwar kann man sie lokal vorhalten (und aufgrund einer Änderung des md5-Wertes aktualisieren), doch scheint mir der Download nicht der entscheidende Faktor zu sein bei der Performance.

Der Download scheint mir auch nicht der entscheidende Faktor zu sein. Und fehlerbehaftete Kataloge sind ja ein allgemeines Problem und nicht nur auf diese Umsetzung bezogen. Wenn man von Hand den Katalog runterlädt und Daten manuell mit dem Katalog überprüft, gibt es ja das gleiche Problem.

dann eruieren wir die involvierten Modelle über ein Parsing der Datasection.

War auch mein erster Gedanke. Müsste geprüft werden.

[edigonzales]

Das Wissen dazu steckt nur im Modell. Woher wüsste man nach dem Parsen der Datasection, WO dieser Organisationsdatensatz heruntergeladen werden kann?

Müsste das nicht im ilidata.xml von VSA-DSS definiert sein? Ist ja eigentlich nichts anderes wie ein Katalog, dort findet die Modellverknüpfung auch mit dem ilidata.xml statt. Zumindest in diesem konkreten Fall.
Ja, dort gibt es einen Eintrag. Aber das alleine bringt mir ja noch nichts (oder ich stehe auf dem Schlauch). Wenn ich eine VSA-DSS-mini-XTF prüfen will, ist der Aufruf ganz zu Beginn so:

java -jar ilivalidator.jar vsadssmini.xtf

Angenommen die Daten sind korrekt, läuft ilivalidator ohne Fehler durch. Nun will ich jedoch auch prüfen, ob die Verknüpfungen zu den Organisationen korrekt ist. Aufruf wäre ja jetzt:

java -jar ilivalidator.jar --allObjectsAccessible vsadssmini.xtf

Und jetzt kommen tausend Fehler, weil ilivalidator Objekte nicht findet, weil die im vsaorganisation.xtf sind. Aus der Datasection kannst du für diese Fälle nicht lesen, WAS eigentlich referenziert wird und WO das referenzierte abgelegt ist. Aus dem Modell kannst du lesen, welches Modell im externen Datensatz verwendet wird, aber immer noch nicht, ob dieser in einem ilidata.xml greifbar ist.

Mir ist momentan auch nicht klar, wie das mit "Katalog-Katalogen" gehen soll. Da kannst du wohl aus der Datasection das Modell des Kataloges eruieren. Aber welche Instanz eines Kataloges verwendest du dann? Woher kennst du seine ID aus dem ilidata.xml? Oder gibt es da eine Ilivalidator-Magie, die mir nicht bewusst ist?

Arbeitshypthose wäre meinerseits auch, dass wenn es tatsächlich in sexy geht, dies auch mit dem ilivalidator pur sexy gehen müsste. Sonst wird es m.E. intransparent für die Anwender.

Der Download scheint mir auch nicht der entscheidende Faktor zu sein. Und fehlerbehaftete Kataloge sind ja ein allgemeines Problem und nicht nur auf diese Umsetzung bezogen. Wenn man von Hand den Katalog runterlädt und Daten manuell mit dem Katalog überprüft, gibt es ja das gleiche Problem.

Darum müsste man schauen, dass der Benutzer nicht den Katalog herunterladen müsste, sondern "bloss" die Validierungskonfiguration angeben müsste (in der alles verknüpft ist).

Aus dem Gedächtnis:

java -jar ilivalidator.jar --metaConfig VSADSSMINI_2020_LV95_IPW_20230605-meta vsadssmini.xtf

https://geo.so.ch/models/ilidata.xml
https://geo.so.ch/models/AFU/VSADSSMINI_2020_LV95_IPW_20230605-meta.ini

Wenn es das alles nicht braucht, bin ich ganz Ohr.

Der VSA-DSS-mini Usecase ist schon bissle anders als blosse Kataloge. Aber warum einen mE nicht wirklich transparenten Sonderzug für Kataloge fahren, der dann für weitere Anforderungen eh nicht mehr funktioniert.

[romefi]

Und jetzt kommen tausend Fehler, weil ilivalidator Objekte nicht findet, weil die im vsaorganisation.xtf sind.

Das würde ich mal out of scope nehmen. Muss irgendwie gelöst werden, aber das lösen wir nicht in diesem Issue. Vielleicht kann geostandards.ch ein Validierungstool bauen, dass alle Datensätze validiert, die in einem ilidata.xml referenziert sind. So wie das irgendwann auch für alle ilimodels.xml usw. gemacht werden müsste.

Aber welche Instanz eines Kataloges verwendest du dann? Woher kennst du seine ID aus dem ilidata.xml?

Diese Angabe muss der User machen, da es bei 1-n Beziehung Modell-Katalog nie DEN Katalog gibt. Jemand muss das definieren. Entweder der User, indem er den Katalog auswählt oder irgendjemand, der ein Prüfprofil schreibt. Es müssten also alle Kataloge, die in einem ilidata.xml in den Repos dem referenzierten Modell zugewiesen ist, aufgelistet werden. Das macht ja ilimodels.ch schon. Allenfalls kann man mit ein bisschen Intelligenz (Datum, obsolete etc.) die wahrscheinlichen Kataloge zuerst vorschlagen. Sobald der Katalog, gegenüber dem geprüft werden soll, ausgewählt ist, kennt man auch die ilidata:RepoID und ilivalidator kann rattern.

Der VSA-DSS-mini Usecase ist schon bissle anders als blosse Kataloge.

Wieso? Ist es nicht in Prinzip immer eine ASSOCIATION..... (EXTERNAL) und die assoziierte Quelle(n) sind über ilidata.xml auffindbar und sofern nicht nur eine einzige Quelle vorhanden ist, muss sie angegeben werden? Ist mir bewusst, dass es durchaus auch eine konzeptionelle Frage ist.

[edigonzales]

Aber welche Instanz eines Kataloges verwendest du dann? Woher kennst du seine ID aus dem ilidata.xml?

Diese Angabe muss der User machen, da es bei 1-n Beziehung Modell-Katalog nie DEN Katalog gibt. Jemand muss das definieren. Entweder der User, indem er den Katalog auswählt oder irgendjemand, der ein Prüfprofil schreibt. Es müssten also alle Kataloge, die in einem ilidata.xml in den Repos dem referenzierten Modell zugewiesen ist, aufgelistet werden. Das macht ja ilimodels.ch schon. Allenfalls kann man mit ein bisschen Intelligenz (Datum, obsolete etc.) die wahrscheinlichen Kataloge zuerst vorschlagen. Sobald der Katalog, gegenüber dem geprüft werden soll, ausgewählt ist, kennt man auch die ilidata:RepoID und ilivalidator kann rattern.

Ich würde nicht dem Benutzer aufbürden, den richtigen Katalog aus verschiedenen auszuwählen. Der Benutzer prüft eine Transferdatei ja nicht in einem luftleerem Raum, sondern weil ein Auftraggeber eine Lieferung will. Dieser Auftraggeber soll definieren, mit welchen Parametern die Prüfung resp. letzten Endes die Anlieferung erfolgen soll. Zudem die exakt gleiche Prüfung der Lieferant auch lokal mit ilivalidator pur vornehmen kann, indem er --metaConfig ilidata:fubar verwendet. Da schlägt ihm ja auch niemand den passendsten Katalog vor. Und mit dem Katalogvorschlagen ist ja nur sehr wenig erreicht, nämlich das Vorschlagen von Katalogen. Wenn der Auftraggeber andere zusätzliche Prüfoptionen definiert, muss man das auch wieder sinnvoll exponieren. Seien es nur "schöne" Fehlermeldungen. Warum also was separates für Kataloge machen, was eh nur ein kleines Problem löst. Aber ja, die korrekte Metaconfig (aka Prüfprofil) muss der Benutzer auswählen.

Der VSA-DSS-mini Usecase ist schon bissle anders als blosse Kataloge.

Wieso? Ist es nicht in Prinzip immer eine ASSOCIATION..... (EXTERNAL) und die assoziierte Quelle(n) sind über ilidata.xml auffindbar und sofern nicht nur eine einzige Quelle vorhanden ist, muss sie angegeben werden? Ist mir bewusst, dass es durchaus auch eine konzeptionelle Frage ist.

Ich dachte, man wollte mittels XTF parsen automatisch den Katalog herausfinden. Das geht mit EXTERNAL dann sowieso nicht mehr. Sonst sind sie schon ähnlich.

[romefi]

Ich würde nicht dem Benutzer aufbürden, den richtigen Katalog aus verschiedenen auszuwählen. Der Benutzer prüft eine Transferdatei ja nicht in einem luftleerem Raum, sondern weil ein Auftraggeber eine Lieferung will. Dieser Auftraggeber soll definieren, mit welchen Parametern die Prüfung resp. letzten Endes die Anlieferung erfolgen soll. Zudem die exakt gleiche Prüfung der Lieferant auch lokal mit ilivalidator pur vornehmen kann, indem er --metaConfig ilidata:fubar verwendet. Da schlägt ihm ja auch niemand den passendsten Katalog vor. Und mit dem Katalogvorschlagen ist ja nur sehr wenig erreicht, nämlich das Vorschlagen von Katalogen. Wenn der Auftraggeber andere zusätzliche Prüfoptionen definiert, muss man das auch wieder sinnvoll exponieren. Seien es nur "schöne" Fehlermeldungen. Warum also was separates für Kataloge machen, was eh nur ein kleines Problem löst. Aber ja, die korrekte Metaconfig (aka Prüfprofil) muss der Benutzer auswählen.

Einverstanden, für klar bestimmte Datenlieferungen ist es sinnvoll wenn nicht zwingend, dass der Datenempfänger den Katalog vorgibt. Anders sieht es aus, wenn ein reiner Checker angeboten wird, der nicht im Verhältnis Datelieferant <> Datenempfänger steht. Da weiss der Checker nicht, gegen welchen Katalog geprüft werden soll, also braucht es eine Auswahl der möglichen Kataloge.
@olivergrimm Ggf. macht es Sinn, dass wir beide Usecases (1. Fixe Angabe vom Katalog vom Betreiber, 2. Katalogauswahl) vertiefter anschauen

[olivergrimm]

Danke für Eure wertvollen Inputs. Das Parsen der Datasection war wohl definitiv ein Schuss in die Luft und ist schleunigst zu verwerfen.
Was spricht denn nun konkret gegen die Interpretation von ilidata.xml bzw. ilimodels.xml? und ja, sofern ein Katalog zugewiesen ist, wird dieser in die Validierung miteinbezogen. Bei entsprechender Backend-Konfig und ob der Lieferant will oder nicht.

[edigonzales]

Danke für Eure wertvollen Inputs. Das Parsen der Datasection war wohl definitiv ein Schuss in die Luft und ist schleunigst zu verwerfen. Was spricht denn nun konkret gegen die Interpretation von ilidata.xml bzw. ilimodels.xml? und ja, sofern ein Katalog zugewiesen ist, wird dieser in die Validierung miteinbezogen. Bei entsprechender Backend-Konfig und ob der Lieferant will oder nicht.

Verstehe ich noch nicht. Wie wäre hier der Ablauf? Was machte die Maschine? Was muss der Mensch machen? Und ich würde Umsetzungen nicht auf das Problem "Kataloge" beschränken, sondern ganz allgemein betrachten im Sinne von Validierungskonfiguration.

[edigonzales]

Einverstanden, für klar bestimmte Datenlieferungen ist es sinnvoll wenn nicht zwingend, dass der Datenempfänger den Katalog vorgibt. Anders sieht es aus, wenn ein reiner Checker angeboten wird, der nicht im Verhältnis Datelieferant <> Datenempfänger steht. Da weiss der Checker nicht, gegen welchen Katalog geprüft werden soll, also braucht es eine Auswahl der möglichen Kataloge. @olivergrimm Ggf. macht es Sinn, dass wir beide Usecases (1. Fixe Angabe vom Katalog vom Betreiber, 2. Katalogauswahl) vertiefter anschauen

Es gibt ja letzten Endes wohl zu 99.9% keine Validierung, die nicht in einer Lieferung endet? Es gibt vielleicht "Zwischenprüfungen" vor einer Lieferung. Dann muss man halt einfach einen Parameter haben, der zwar gemäss Vorgabe prüft, aber nicht abliefert.

[olivergrimm]

Danke für Eure wertvollen Inputs. Das Parsen der Datasection war wohl definitiv ein Schuss in die Luft und ist schleunigst zu verwerfen. Was spricht denn nun konkret gegen die Interpretation von ilidata.xml bzw. ilimodels.xml? und ja, sofern ein Katalog zugewiesen ist, wird dieser in die Validierung miteinbezogen. Bei entsprechender Backend-Konfig und ob der Lieferant will oder nicht.

Verstehe ich noch nicht. Wie wäre hier der Ablauf? Was machte die Maschine? Was muss der Mensch machen? Und ich würde Umsetzungen nicht auf das Problem "Kataloge" beschränken, sondern ganz allgemein betrachten im Sinne von Validierungskonfiguration.

Grundsätzlich sollte m.E. alles die Maschine machen. Das Zielpublikum eines einfachen Validators sollte ohne Kenntnisse bzgl. Kataloge klar kommen.

[edigonzales]

Grundsätzlich sollte m.E. alles die Maschine machen. Das Zielpublikum eines einfachen Validators sollte ohne Kenntnisse bzgl. Kataloge klar kommen.

Die Maschine kann aus dem XTF das zu validierende Modell lesen. Aus dem Modell kenn ich via DEPENDS den Katalog. Wobei es bei DEPENDS wohl nicht nur Kataloge geben kann, sondern auch anderes Zeugs (?). Im ilidata.xml finde ich unter "baskets" den Modell- und Topicnamen des Katalogs wieder. Wenn es aber mehrere Katalogversionen gibt, kann ich automatisch nur raten (den aktuellsten, d.h. der keine Vorgängerversion hat). Zudem muss man das ilidata.xml sauber und vollständig pflegen, d.h. baskets muss geführt werden. Hier hätte ich auch ein paar Fragen, ob das zuverlässig ist.

Ich zweifle glaubs einfach ein wenig an "Zielpublikum eines einfachen Validators sollte ohne Kenntnisse bzgl. Kataloge klar kommen". Ja, wie haben die dann die Daten erfasst? Mit Modelbaker, der das gleiche Problem haben wird, wenn es mehrere Kataloge gibt? Wenn man Kataloge wegabstrahieren will, soll man sie schon mal gar nicht verwenden (anderes Thema).

[Philippluca]

@olivergrimm und ich haben eure Kommentare konsolidiert und landen auf folgenden Lösungsvorschlag:
interlis-check-service wird um einen API Parameter (check-profile oder metaConfigId) erweitert, dem ilivalidator mit --metaConfig ilidata:<<metaConfigId>> übergeben wird. Dies ermöglicht es Prüfprofile unabhängig von interlis-check-service und öffentlich zu pflegen & es können die gleichen Validierungen offline reproduziert werden. (Funktionsweise ist hier dokumentiert: https://github.com/claeis/ilivalidator/blob/master/docs/ilivalidator.rst).

Es gilt die Prioritätenliste: API Parameter als ilidata: -> Lokale TOML Datei -> interlis-check-service. Für den Web UI Benutzer bedeutet dies, dass er für den interlis-check-service weiterhin keine angaben machen muss, jedoch entsprechende Katalogfehler bekommen kann.

Wie von @edigonzales erwähnt, finden Validierungen nicht im luftleeren Raum statt, sondern als Vorbedingung einer Lieferung. Mit geopilot decken wir den Prozess der Datenlieferung bereits ab und sehen daher die Umsetzung dort am richtigen Ort.

• Administrator:innen konfigurieren beim Mandat wie bisher ein Extent sowie neu das erwartete Modell und benötigte Prüfprofiel.
• Bei einem Upload wird initial der Extent und das Modell ermittelt. Realistisch sollte hier nur 1 Profil gefunden werden.
• ilicop/interlis-check-service wird mit dem entsprechenden Profil aufgerufen.

Mit diesem Ansatz gelten die stärken von geopilot/ilicop weiterhin:

• Anwender:innen müssen bei der Abgabe nicht spezifizieren wie die Daten validiert werden müssen.
• Bei erfolgreichen Lieferungen gelten pro Mandat immer definierte Vorbedingungen.
• Für die Anwender:innen gibt es nur 1 Fehlerlog, nach welchem sie korrigieren können.

@romefi @edigonzales @beistehen Bitte um Feedback.

[edigonzales]

Es gilt die Prioritätenliste: API Parameter als ilidata: -> Lokale TOML Datei -> interlis-check-service. Für den Web UI Benutzer bedeutet dies, dass er für den interlis-check-service weiterhin keine angaben machen muss, jedoch entsprechende Katalogfehler bekommen kann.

Geht nicht, wenn es für ein Modell mehrere Prüfprofile geben muss. Eventuell aber egal, siehe mein Schlusskommentar.

Wie von @edigonzales erwähnt, finden Validierungen nicht im luftleeren Raum statt, sondern als Vorbedingung einer Lieferung. Mit geopilot decken wir den Prozess der Datenlieferung bereits ab und sehen daher die Umsetzung dort am richtigen Ort.

• Administrator:innen konfigurieren beim Mandat wie bisher ein Extent sowie neu das erwartete Modell und benötigte Prüfprofiel.
• Bei einem Upload wird initial der Extent und das Modell ermittelt. Realistisch sollte hier nur 1 Profil gefunden werden.
• ilicop/interlis-check-service wird mit dem entsprechenden Profil aufgerufen.

Mit diesem Ansatz gelten die stärken von geopilot/ilicop weiterhin:

• Anwender:innen müssen bei der Abgabe nicht spezifizieren wie die Daten validiert werden müssen.
• Bei erfolgreichen Lieferungen gelten pro Mandat immer definierte Vorbedingungen.
• Für die Anwender:innen gibt es nur 1 Fehlerlog, nach welchem sie korrigieren können.

@romefi @edigonzales @beistehen Bitte um Feedback.

Ich verstehe die Abgrenzung ilicop vs geocop nicht so ganz. Wenn man an den geocop liefert und dort angibt, welches Thema (z.B. LK-irgendwas) man schickt und geocop daraus das passende Prüfprofil liest und dann ilicop mit der passenden ilidata-ID, glaube ich es zu verstehen, dass es geht. Aber irgend zu einem Zeitpunkt, muss der Benutzer irgend eine Information mitschicken, sonst hat man immer das Problem, dass es zu einem Modell unterschiedliche "Lieferthemen" gibt oder wie man das nennen will. Bestes Beispiel wäre ja z.B. die Anlieferung eines ÖREB-Rahmenmodelles mit unterschiedlichen Constraints pro Thema.

[Philippluca]

@edigonzales
Die Trennung von ilicop und geopilot ergibt sich aus dem umstand, dass ilicop "nur" ein online Validierungsdienst für INTERLIS Daten darstellt. ilicop bzw. interlis-check-service kennt keine Vorbedingungen / Annahmen welche es bei einer Datenlieferung allenfalls geben könnte. Der Prozess der Anlieferung wird durch geopilot bewerkstelligt. Die Lieferungen sind im Allgemeinen nicht auf INTERLIS Formate limitiert. Je nach Vertrag/Mandat könnten hier auch CSV, Shape, GeoTIFF akzepiert werden.

Ich habe mögliche Lösungen nochmals mit @romefi diskutiert. Wir sind dabei auf 3 Aussagen gekommen, welche dabei helfen könnten, die Lösung zu schärfen.

• Durch den Abgleich des Modells aus Mandat und Daten sollten wir in 90% der Fälle zu einem einzigen Prüfprofil gelangen. (Das Prüfprofil kann dabei bei mehreren Mandaten verwendet werden)

• Durch einen zusätzlichen ableich des Extent von Mandat und Daten sollten wir in 95% der Fälle zu einem eindeutigen Profil gelangen.

• Für die überbleibenden 5% gibt es keine "automatisch richtige" Zuweisung zu einem Prüfprofil. Wir akzeptieren für diese eine Lösung welche

  • Ansatz A: Dass mehrere Validierungen gleichzeitig ausgeführt werden. Ist mindestens eine Validierung erfolgreich, wird diese angezeigt und die Fehlerhaften hinter "Fehlerhafte anzeigen" versteckt. Die Prüfprofile erhalten in ilidata.xml title und shortDescription welche dem Benutzer angezeigt werden. Bei der Selektion des Mandates für eine Lieferung, wird das entsprechende Protokoll hervorgehoben und eine Lieferung nur entsprechend ermöglicht.

    • Pro: Es bedarf keinem User-Input
    • Con: Es braucht vorgelagerte Schritte, um das Modell / Extent zu bestimmen.
    • Con: Es werden Validierungen durchgeführt, welche für die Lieferung möglicherweise irrelevant sind.

  • Ansatz B: Vor der Validierung muss der Benutzer ein Prüfprofil deklarieren.

    • Pro: Es wird pro möglicher Abgabe nur eine Validierung durchgeführt.
    • Con: Der Anwender muss zwischen allen verfügbaren Prüfprofilen das richtige kennen.
    • Con: Wird das falsche Prüfprofil deklariert, gelangt der Prozess nie zu einer Lieferung. Dem User kann der Fehler nicht kommuniziert werden.
    • Con: Die Anwendung wird weniger nutzerfreundlich, da das Upload & Validate Konzept gebrochen wird.

Ich denke, wir könnten die Lösung für mal 90% der Fälle verfolgen und iterativ immer weitere Einschränkungen vornehmen. Sofern mehrere Profile gefunden werden, werden eben mehrere Validierungen erfolgen. Mögliche Parameter zur Einschränkung:

• Modell
• Extent
• Konfiguierte Mandate
• Eingeloggter User und dessen Mandate bei start der Validierung
• Vorhandene Klassen in XTF
• ...

[Philippluca]

May resolve #91