Ich möchte auf DSS_2020_LV95 basierende XML Dateien verwenden (für den Import nach TEKSI Wastewater); allerdings mit einem anderen Koordinatensystem, nämlich UTM32N (EPSG: 25832), um Koordinaten aus Deutschland zu verwenden.
Die Dateien sollen automatisch durch ilivalidator als korrekt erkannt werden.
Das Problem ist der Base_LV95.LKoord Typ, der Constraints auf den Wertebereich enthält.
Wie kann ich eine abgeleitete, private „DSS_2020_UTM32N“ erstellen (bzw. Base_LV95.LKoord durch z.B. „Base_UTM32N.LKoord“ ersetzen, die diese Einschränkungen nicht hat, lokal vorgehalten und transparent von ilivalidator genutzt wird?
Tatsächlich ist angedacht, INTERLIS via XSLT stylesheet aus ISYBAU zu erzeugen (und retour).
Ich traue mir zu, einen weiteren Export/Import in TEKSI einzubauen, der nur das wie beschrieben abgeleitete Modell verwendet, aber ansonsten die einfach die Felder schreibt/liest wie im Original Modell. Das Problem ist der ilivalidator (auf den ich auch nicht verzichten möchte) bzw. das im Original Modell definierte LV95 (HKoord müsste man wohl auch anpassen).
Ich sehe drei Varianten, um dein Problem der Validierung mittels ilivalidator zu lösen:
a) „Quick and dirty“
Kopiere die Datei mit dem Modell Base_LV95 lokal zu dir.
Editiere den Wertebereich für die Domain Base_LV95.LKoord und passe ihn deinen Daten an (Achtung: die Datei enthält 2 Modelle - editiere das richtige (= das zweite mit Start in Zeile 89)).
Speichere die ili-Datei (am besten unter einem neuen Dateinamen, um Verwechslungen zu vermeiden; Endung .ili beibehalten!)
Stelle sicher, dass deine lokal erstellte ili-Datei durch ilivalidator als erstes gefunden wird, bevor in den Model Repositories danach gesucht wird. Dies kannst du dadurch erreichen, indem du deine lokal erstellte ili-Datei in denselben Ordner verschiebst, in welchem sich auch die zu prüfende xtf-Datei befindet.
Nun sollte der ilivalidator bezüglich der Koordinatenwerte keine Fehlermeldungen mehr ausgeben.
b) Validierung für Geometriedatentypen ausschalten
ilivalidator kann ein sogenanntes config-File mitgegeben werden, in welchem die Prüfung einzelner Attribute deaktiviert werden kann. Für VSA-DSS würde das bedeuten, dass du überall, wo ein Geometriedatentyp verwendet wird (LKoord, aber auch Polyline und Surface) diese Prüfung explizit ausschaltest. Beispiele dazu findest du in der Doku. Es scheint mir aber gerade etwas viel Aufwand zu sein für die Testphase, in der du dich befindest.
c) Saubere Modellierung eines neuen Koordinatenreferenzsystems
Für eine nachhaltige Lösung (Anwendung des VSA-DSS-Datenmodells mit einem anderen Koordinatenreferenzsystem) wäre es nötig, das zugrunde liegende Basismodell zu ersetzen oder generische Koordinatensysteme (unter Verwendung von INTERLIS 2.4 statt 2.3) anzuwenden. Dies müsste dann wohl zwingend in Absprache mit dem VSA als Eigentümerin des Modells geschehen. Ein solches Modell würde dann auch in einem Model Repository abgelegt und stünde somit allen Anwendungen automatisch zur Verfügung.
Fazit
Für die Varianten a) und b) sehe ich keine lizenzrechtlichen Probleme, solange das zu firmeninternen, nicht-kommerziellen Zwecken geschieht. Einen eigenen Prüfdienst (on- oder offline) für Daten in UTM32N würde ich wohl eher nicht ohne Rücksprache mit dem VSA anbieten.
Prima, Option a) ist ideal, ilivalidator scheint mit dieser Reihenfolge von Suchfoldern aufgerufen zu werden, und der Folder mit der Input XTF kommt auch zuerst zum Zug: Info: modeldir <%ITF_DIR;http://models.interlis.ch/;%JAR_DIR/ilimodels>
Das erspart mir, einen direkten ISYBAU Import zu realisieren, den benötigten subset für die Transformation ISYBAU<-> INTERLIS baue ich per XSLT stylesheet nach.
Danke auch für die lizenzrechtiliche Einschätzung, an eine Veröffentlichung ist nicht gedacht.
