Ok, da kommen ein paar Dinge zusammen. Ich weiss leider nicht wie das Nachfolgende alles mit Modelbaker umgesetzt werden kann. Da muss ein Modelbaker-Profi her @romefi ?
Die Fehler bezüglich „duplicate coords“ kommen daher, dass es im XTF unterschiedliche Koordinaten gibt, die gerundet auf Millimeter (so wie es das Modell vorschreibt) den gleichen Koordinatenwerte entsprechen. Also z.B. sowas:
<COORD><C1>2781116.8335999995</C1><C2>1147971.2100999989</C2></COORD>
<COORD><C1>2781116.8337000012</C1><C2>1147971.2102000006</C2></COORD>
Weil gleiche Koordinate, motzt der ilivalidator. Die Area-Prüfung meldet noch zwei weitere Fehler:
Error: polygons overlay tid1 07492e5f-c21a-4a3a-90b5-d14d88e6004b, tid2 9206ec22-44b7-4013-a88e-2312ab418be3
Error: polygons overlay tid1 895f6561-b8b3-4514-8dfd-275d76c78015, tid2 f6fd95b4-283a-48ec-ac30-b78a8c91348e
Das sind Polygone der Grundnutzung, die sich überlappen. Grund dafür sind fehlende Stützpunkt in einer Geometrie:
Archive.zip (33,9 KB)
Das Zip-File beinhaltet png und wordfile.
Man kann nun die Validierung fürs Erste ausschalten (--disableValidation), um die Daten überhaupt importieren zu können. Dann erscheinen beim Import der Daten nach Geopackage aber immer noch folgende Fehler:
Error: unknown referenced object Nutzungsplanung_GR_V5_1_DE.KantonaleTypenTabellen.GGP_GestaltungTypKanton TID 2232 referenced from Nutzungsplanung_GR_V5_1_DE.GenerellerGestaltungsplan.GGP_GestaltungTypGemeinde TID c2e44036-992d-11e7-baa4-0e060a842a8d
Error: unknown referenced object Nutzungsplanung_GR_V5_1_DE.KantonaleTypenTabellen.GGP_GestaltungTypKanton TID 2142 referenced from Nutzungsplanung_GR_V5_1_DE.GenerellerGestaltungsplan.GGP_GestaltungTypGemeinde TID c2e46e12-992d-11e7-baa4-0e060a842a8d
...
Und:
Error: failed to transfer data from file to db
Error: dangling references
Das hat damit zu tun, dass im XTF Objekte auf andere Objekte verweisen, die nicht in der XTF-Datei vorhanden sind. Es handelt sich dabei um sowas wie Kataloge. Diese befinden sich im Modell-Repository Index of /NUP
Man muss diese Kataloge zuerst importieren. Meine Importbefehle lauten wie folgt:
java -jar ili2gpkg-5.2.2.jar --dbfile silvaplana1.gpkg --nameByTopic --defaultSrsCode 2056 --strokeArcs --models Nutzungsplanung_GR_V5_1_DE --doSchemaImport --disableValidation --createTidCol --importTid --import PLI_PlanungsinhaltTypKanton.xml
java -jar ili2gpkg-5.2.2.jar --dbfile silvaplana1.gpkg --nameByTopic --defaultSrsCode 2056 --strokeArcs --models Nutzungsplanung_GR_V5_1_DE --disableValidation --importTid --import ZP_ZonenTypKanton.xml
java -jar ili2gpkg-5.2.2.jar --dbfile silvaplana1.gpkg --nameByTopic --defaultSrsCode 2056 --strokeArcs --models Nutzungsplanung_GR_V5_1_DE --disableValidation --importTid --import GGP_GestaltungTypKanton.xml
java -jar ili2gpkg-5.2.2.jar --dbfile silvaplana1.gpkg --nameByTopic --defaultSrsCode 2056 --strokeArcs --models Nutzungsplanung_GR_V5_1_DE --disableValidation --importTid --import GEP_ErschliessungTypKanton.xml
java -jar ili2gpkg-5.2.2.jar --dbfile silvaplana1.gpkg --nameByTopic --defaultSrsCode 2056 --strokeArcs --models Nutzungsplanung_GR_V5_1_DE --disableValidation --importTid --import 3790_2023-04-05.xtf
Der erste Befehl erstellt auch noch gerade die leeren Tabellen (–doSchemaImport). Wichtig sind vor allem auch die Optionen --createTidCol beim Erstellen der Tabellen und --importTid beim Importieren der Daten.
Auch ilivalidator meldet diese Referenzen ins Nirwana. Das muss man ihm aber mitteilen mit --allObjectsAccessible. Weil die Assoziation zwischen Klassen in unterschiedlichen Topics ist, geht ilivalidator standardmässig davon aus, dass die Daten des anderen Topics nicht vorhanden sind. Damit die Fehler mit ilivalidator und --allObjectsAccessible verschwinden, musst du einfach alle Kataloge beim Befehl mitliefern:
java -jar ilivalidator.jar --allObjectsAccessible xml1 xml2 xml3 xml4 meineDaten.xtf
