Inkrementeller Transfer

Standorte toter Wildsäuli werden an uns geschickt. Kann man inkrementellen Transfer irgendwie faken, damit folgendes geht für Datenlieferant:

  1. Er schickt drei neue Standorte in einer XTF-Datei.
  2. Er schickt von zwei vorhandenen Standorten Änderungen in einer XTF-Datei.

--update löscht in diesem Fall leider das in der Datei nicht vorhandene Objekt.

Stefan

2 „Gefällt mir“

Hm, ich fürchte, dass immer sämtliche unveränderten Objekte mitgeliefert werden müssen… Wie soll das Tool sonst wissen, welche Objekte tatsächlich gelöscht wurden und welche Objekte unverändert blieben…? Man müsste ILI vermutlich dahingehend erweitern, dass man DELETE-Flags für gelöschte/zu löschende Objekte mitliefert… Dann müssten alle in der DB vorhandenen, aber im Transfer nicht gelieferten Objekte in Ruhe gelassen werden.
Wir hatten beim Kt. GL im Rahmen der Historisierung eine DB-Funktion entwickeln lassen, die diesen Mangel behebt – könnte ich bei Bedarf „ausgraben“…

@edigonzales Die Transferdatei müsste für Deinen Usecase und nach RefHB auf Stufe Basket mit ili:kind=„UPDATE“ und auf auf Stufe der Objekte mit ili:operation=„INSERT“ bzw „UPDATE“ ergänzt werden. Sofern ein reguläres XTF für einen Update benutzt wird, nimmt INTERLIS nach Spezifikation die ili:operation=„FULL“ an, was auch ein Löschen von „nicht mitgelieferten“ Objekten erklärt.
@peterstaub: Die Nachlieferungsoperation „DELETE“ auf dem Objekt wäre ja genau dafür gedacht, oder? (RefHB, S.100)

Die Frage zielte darauf ab, ob es eben ohne „richtige“ INTERLIS inkrementelle Nachführung geht, da nicht in Tools implementiert. Ggf. mit Kombination von versch. ili2db-Optionen etc.

Stefan

ah, alles klar. Das habe ich so nicht gecheckt