# Erstellen eines von DSS\_2020\_LV95 abgeleiteten Modells für die Verwendung von UTM32N Koordinaten **URL:** \ **Category:** INTERLIS Werkzeuge\ **Tags:** ilivalidator\ **Created:** [5. April 2025 um 10:48 UTC](https://interlis.discourse.group/t/erstellen-eines-von-dss-2020-lv95-abgeleiteten-modells-fuer-die-verwendung-von-utm32n-koordinaten/372 "2025-04-05T10:48:36Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![fxd](https://avatars.discourse-cdn.com/v4/letter/f/e9a140/32.png) [@fxd](https://interlis.discourse.group/u/fxd)\ **Post date:** [5. April 2025 um 10:48 UTC](https://interlis.discourse.group/t/erstellen-eines-von-dss-2020-lv95-abgeleiteten-modells-fuer-die-verwendung-von-utm32n-koordinaten/372/1 "2025-04-05T10:48:36Z")
Ich möchte auf [DSS\_2020\_LV95](https://ilimodels.ch/detail/8c0c29a2540fc1d6a948144dca50b217/DSS_2020_LV95) basierende XML Dateien verwenden (für den Import nach TEKSI Wastewater); allerdings mit einem anderen Koordinatensystem, nämlich [UTM32N (EPSG: 25832)](https://epsg.io/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? Ist das möglich, auch lizenzrechtlich? ---
**Author:** ![edigonzales](https://yyz2.discourse-cdn.com/free1/user_avatar/interlis.discourse.group/edigonzales/32/4_2.png) [@edigonzales](https://interlis.discourse.group/u/edigonzales)\ **Post date:** [5. April 2025 um 17:22 UTC](https://interlis.discourse.group/t/erstellen-eines-von-dss-2020-lv95-abgeleiteten-modells-fuer-die-verwendung-von-utm32n-koordinaten/372/2 "2025-04-05T17:22:20Z")
Hallo Felix du hast bereits INTERLIS-Transferdateien im Modell DSS\_2020\_LV95 aber die Koordinatenbereiche entsprechen nicht dem Base\_LV95-Modell? Stefan ---
**Author:** ![fxd](https://avatars.discourse-cdn.com/v4/letter/f/e9a140/32.png) [@fxd](https://interlis.discourse.group/u/fxd)\ **Post date:** [5. April 2025 um 18:16 UTC](https://interlis.discourse.group/t/erstellen-eines-von-dss-2020-lv95-abgeleiteten-modells-fuer-die-verwendung-von-utm32n-koordinaten/372/3 "2025-04-05T18:16:39Z")
Ich kann diese zumindest erzeugen, via Export aus TEKSI (PostGIS DB nach Anleitung mit SRID 25832 angelegt, Bauwerk in Deutschland angelegt, ilivalidator beschwert sich über value out of Range für Koordinate → Hochwert) bei Validierung nach Export, wie hier beschrieben: [Looking for advice to use TEKSI wastewater for communal wastewater in germany (coordinate constraint violation because restricted Base\_LV95.LKoord type) · Issue #582 · teksi/wastewater · GitHub](https://github.com/teksi/wastewater/issues/582) ![image](https://global.discourse-cdn.com/free1/uploads/interlis/original/1X/04a805115c785a5339f149859923fe53a4577232.jpeg) ![image](https://global.discourse-cdn.com/free1/uploads/interlis/optimized/1X/ce46443f2e94f20fb00a5b4036d1160bc75d2143_2_690x76.png) ![image](https://global.discourse-cdn.com/free1/uploads/interlis/original/1X/3e7877a22a25101cc050fbf8939ee4c07ce609e6.jpeg) 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). [tww-export\_Stadion\_Vortex\_DSS\_2020\_1\_LV95.xtf](https://interlis.discourse.group/uploads/short-url/zmy8D9Cd6lB3Wrssu7R4Uvg02p7.xtf) (2,5 KB) [tww-export\_Stadion\_Vortex.xtf.250403190904.ilivalidator-DSS\_2020\_1\_LV95.log](https://interlis.discourse.group/uploads/short-url/z1cdlyonaERE0VLRSEOiPyd8yY0.log) (16,3 KB) [tww-export\_Stadion\_Vortex.xtf.250403190901.ili2pg-export-DSS\_2020\_1\_LV95.log](https://interlis.discourse.group/uploads/short-url/AhV1vdQvDbZgj1A31M72Qg0OX3s.log) (79,5 KB) ---
**Author:** ![beistehen](https://yyz2.discourse-cdn.com/free1/user_avatar/interlis.discourse.group/beistehen/32/7_2.png) [@beistehen](https://interlis.discourse.group/u/beistehen)\ **Post date:** [7. April 2025 um 11:36 UTC](https://interlis.discourse.group/t/erstellen-eines-von-dss-2020-lv95-abgeleiteten-modells-fuer-die-verwendung-von-utm32n-koordinaten/372/4 "2025-04-07T11:36:16Z")
Hallo Felix Ich sehe drei Varianten, um dein Problem der Validierung mittels ilivalidator zu lösen: ## a) „Quick and dirty“ - Kopiere die [Datei](https://405.sia.ch/models/2015/Base_d-20181005.ili) 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](https://github.com/claeis/ilivalidator/blob/master/docs/ilivalidator.rst#konfiguration). 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. ---
**Author:** ![fxd](https://avatars.discourse-cdn.com/v4/letter/f/e9a140/32.png) [@fxd](https://interlis.discourse.group/u/fxd)\ **Post date:** [7. April 2025 um 13:46 UTC](https://interlis.discourse.group/t/erstellen-eines-von-dss-2020-lv95-abgeleiteten-modells-fuer-die-verwendung-von-utm32n-koordinaten/372/5 "2025-04-07T13:46:26Z")
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. ---
**Author:** ![fxd](https://avatars.discourse-cdn.com/v4/letter/f/e9a140/32.png) [@fxd](https://interlis.discourse.group/u/fxd)\ **Post date:** [8. April 2025 um 14:08 UTC](https://interlis.discourse.group/t/erstellen-eines-von-dss-2020-lv95-abgeleiteten-modells-fuer-die-verwendung-von-utm32n-koordinaten/372/6 "2025-04-08T14:08:49Z")
Erfolgreicher Export & Re-Import (nach einigen Anpassungen im pg2ili\_abwasser Schema bzgl. SRID) mit der gepatchten **Base\_d-20181005.ili** Modelldatei. ![image](https://global.discourse-cdn.com/free1/uploads/interlis/original/1X/b287de5213a964279e5a4e99c987baa257fbca5d.png) ![image](https://global.discourse-cdn.com/free1/uploads/interlis/original/1X/c1da4e3cb7db3be8d1b7e71a2596c3b8b93675dc.png) ---
**Author:** ![edigonzales](https://yyz2.discourse-cdn.com/free1/user_avatar/interlis.discourse.group/edigonzales/32/4_2.png) [@edigonzales](https://interlis.discourse.group/u/edigonzales)\ **Post date:** [8. April 2025 um 14:25 UTC](https://interlis.discourse.group/t/erstellen-eines-von-dss-2020-lv95-abgeleiteten-modells-fuer-die-verwendung-von-utm32n-koordinaten/372/7 "2025-04-08T14:25:50Z")
Ich würd’ die geschweiften Klammern entfernen resp mit UTM32N ersetzen, damit klar ist, dass es nicht mehr CHLV95 ist. Dito für die Höhen. Stefan