ich bin auf der Suche nach einem Tool, mit dem sich mehrere xtf Dateien (gleiches Interlis Modell) in eine gemeinsame xtf Datei zusammenfassen lassen.
bei infogrips gibt es itfcopy. dies scheint jedoch lediglich mit .itf Dateien zu funktionieren
Eine Suche ergab noch Hinweise auf ein „Interlis Toolbox Paket“ mit dem Programm ilmerge. Nur leider kann ich dieses Programm auch nach weiterer Suche nicht finden.
Anwendungsfall LKMap Zürich, eine Versorgung/Unternehmung beauftragt in Ihrem Versorgungsgebiet mehrere Unternehmungen ein Medium nachzuführen. Die Abgabe an den Kanton muss jedoch (nach meinem derzeitigen Wissenstand) in einer Datei (pro Medium) erfolgen.
Ich habe für diesen Zweck alle xtf in eine Datenbank geschrieben und dann von der DB wieder in eine XTF.
Dazu kannst du die Interlis-Tools verwenden (z.b. ili2gpkg) und mittels Batch alle xtf aus einem Verzeichnis automatisiert einlesen und anschliessend exportieren.
Es erstaunt mich, dass dies funktioniert. Dabei werden doch die Inhalte der Dateien in eine neue Datei kopiert, also inklusive dem Header. Aber der Header sollte doch in einer Interlis-Datei nur einmal vorkommen.
Das schlichte mergen von xtf-Dateien scheint doch nicht richtig zu funktionieren (aufgrund der resultierenden Anzahl Elemente). der Ansatz von Thomas Marti via ili2gpkg erscheint doch erfolgversprechender.
Ich möchte das Thema nochmals aufgreifen; vielleicht ergibt sich hier eine Art „best-practice“.
Ich habe jetzt ein paar Kombinationen der LKMap-Dateien A und B ausprobiert, eindeutig sinnlose und fehlleitende und (anscheinend) richtige, geprüft mit ilivalidator. Erstellt mit Copy&Paste in UltraEdit; Ziel ist natürlich XSLT …
a) vollständiges mergen (Datei a plus Datei b):
Ergibt zwei vollständige Dateien mit zwei XML-Deklarationen in einer; ilival prüft nur die erste und ist zufrieden.
b) vollständiges mergen, aber händisches Löschen der zweiten Deklaration:
Validierung wie a)
c) Inhalt der Datasection A mit Inhalt der Datasection B ergänzen:
Alles wird geprüft; die Basket-ID ist gleich und die Validierung scheitert.
d) Inhalt der Datasection A mit Inhalt der Datasection B ergänzen und eine Basket-ID ändern
Alles wird geprüft; die Validierung zeigt zwei Baskets und ist erfolgreich.
e) Inhalt des Basket A mit Inhalt des Basket B ergänzen
Alles wird geprüft; die Validierung ist erfolgreich.
Somit scheiden a) und b) aus, weil die (falsche) Datenstruktur den Ilivalidator täuscht.
c) ergibt falsches Ergebnis, d) erfordert Handarbeit …
Bleibt Lösung e)
Bleibt die Frage: Ist das auch zulässig - technisch und formell? Oder produziert man da Datenmüll der Extraklasse?
Die DataSection kann keinen, einen oder mehrere Behälter (Basket) enthalten:
Es ist also nicht vorgesehen, mehrere DataSections in 1 Datei unterzubringen. Alle zusätzlichen DataSections werden von ilivalidator zurecht ignoriert, wie deine Tests zeigen.
Was hingegen möglich ist, ist, mehrere Behälter in der DataSection unterzubringen (wie oben in Kapitel 3.3.5 beschrieben). In Behältern werden die Inhalte von TOPICs transferiert.
Damit man sich nicht mit der Thematik des Transferformates herumschlagen muss, würde ich aber wärmstens die von @ThomasMarti propagierte Methode empfehlen: Nämlich das Einlesen der einzelnen Transferdatensätze in eine Datenbank oder ein Datenbankformat (mit ili2db) und anschliessend die Zusammenführung in der Datenbank. Das hat den Vorteil, dass die Daten vor dem Export noch in der DB validiert werden können. Und der Export liefert auf jeden Fall ein gültiges Transferformat; auch mit mehreren Baskes, falls gewünscht.
Damit kann man sich auch die Einarbeitung in XSLT sparen (und die gewonnene Zeit für die Einarbeitung in ili2db und SQL nutzen… )
e) Löst das Problem auch nicht immer. Du musst dich auch um die Eindeutigkeit der TID im Transfer kümmern? Oder gilt die nur für Baskets? @beistehen
Bisschen schade ist, dass das Importieren und Exportieren in eine DB die relativ teure Geometriebildung beinhaltet (also von XTF nach Simplefeature) inkl. Overlapbereinigung. Es ist also mehr als bloss ein Mergen.
Das mit der Eindeutigkeit der TIDs sollte via ili2db kein Problem sein.
Entweder sind sie gem. Modell schon global eindeutig (=OID bei allen Klassen und Topics).
Oder sie sind transient (kein OID bei Klasse und/oder Topic). Dann werden sie beim import durch ili2db eindeutig gemacht (in dem für jedes Objekt eine neue id generiert wird (Spalte t_id)), die beim export dann als TID verwendet wird.
der Ansatz von Thomas Marti via ili2gpkg erscheint doch erfolgversprechender.
)