[PostNAS Suite] Fehler beim Konvertieren

[Frank Jäger]

Am 04.05.20 um 12:05 schrieb Stefan Rahn:
> .....
>
> Bei uns gibt es die Variante "kill" nicht, es wird also alles 
> historisch gesetzt. Aber unabhängig davon, ob man nun löscht oder 
> historisch setzt, hat man ja bei beiden Varianten das schon 
> angesprochene Problem, dass es während eines Einlesevorgangs Fälle 
> gibt, bei denen zuerst das Replace kommt und erst danach das Insert. 
> Die Reihenfolge ist also vertauscht.
>
> Ein Trigger, der beim Einlesen des Replace-Objekts durch einen Eintrag 
> in die delete-Tabelle ausgelöst wird, kann aber noch gar nichts 
> machen, da eben durch das fehlende Insert die Vorgängerobjektversion 
> noch nicht da ist. Deswegen sind wir dazu übergegangen, das Beenden 
> der historisch gewordenen Objektversionen erst ganz am Ende des 
> Einlesevorgangs zu machen. Denn dann wurden auch alle Inserts eingelesen.
>
> .....
>
> Stefan Rahn
>
> -- 
>   
> GDI-Service
> Friedrichstraße 16
> 18057 Rostock
> ..
> Am 30.04.2020 um 14:13 schrieb Jäger, Frank (KRZ):

...


Hallo,

wir führen ALKIS-Datenbanken für mehrere Gemeinden, Städte und Kreise. 
Je nachdem wann eine Datenbank angelegt wurde, wird mal der Hist- und 
mal der Kill-Trigger verwendet. Zwischenzeitlich stand mal nur der 
Hist-Trigger zur Verfügung.

Wir bieten (fast) aktuelle Auskünfte an und keine "Zeitreisen", daher 
werden die historischen Objekte in keiner Weise genutzt und sind somit 
entbehrlich. Im Postprocessing haben wir ein Script hinterlegt, das 
"delete_all_endet()"  ausführt um die sofort wieder los zu werden.

Der Kill-Trigger ist der direktere Weg zum Ziel.

Dass in einer Verarbeitung der "Replace" zu einem Objekt vor dem 
"Insert" kommt, habe ich noch nie feststellen können.

Wir bekommen die Daten "gekachelt". Je nach Konfiguration des 
Katasteramtes (wir bekommen von 3 verschiedenen), sind das zwischen 5 
(eine Gemeinde aus ibR) und fast 900 (ein Kreis aus AED) Dateien je 
Lieferung. Diese werden nach Name sortiert hintereinander konvertiert.

In jeder Kachel (=Datei) sind "Insert" und "Replace" üblicherweise 
paarig enthalten. In welcher Reihenfolge, das interessiert dabei nicht.

Nach meiner Kenntnis arbeitet der Konverter zunächst nur die Inserts ab 
(normale Konvertierungsfunktion ogr2ogr) und dann in einem weiteren 
Durchlauf alle Anweisungen zu Aktualisierung (NAS-Spezial wie 
"Replace"), die in der "delete"-Tabelle landen.

Somit müsste ein "Replace" in einer anderen Datei stehen, um vor dem 
zugehörigen "Insert" ausgeführt zu werden. So was habe ich noch nie bemerkt.

-- 

Frank Jäger