[PostNAS Suite] Fehler beim Konvertieren

[Stefan Rahn]

Hallo,

gerade durch diese Kachelung der Daten bei der Abgabe entsteht das o.g. 
Problem des Vertauschens von Replace und Insert. Das Replace steht in 
einer Kachel, die vor der Kachel eingelesen wird, in der das Insert 
steht. Deshalb ist es auch unerheblich ob der OGR-Konverter als erstes 
die Inserts macht und dann die Replaces, er sieht ja immer nur die eine 
Kachel.
Als wir die Abgabestelle von MV, das Amt für Geoinformation, 
Vermessungs- und Katasterwesen, auf das Problem ansprachen, haben die 
das bestätigt und uns auf das Hauptdokument der GeoInfoDoc 6.0.1 
verwiesen, in der dazu ansatzweise etwas im Kapitel 5.3.2 steht:

"Replace-Befehle, bei denen das fortzuführende Objekt noch nicht im 
Datenbestand des
Nutzers ist, sind bei der Übername wie Insert-Befehle zu behandeln. 
(Beispiel: Ein Nutzer
erhält im Interessengebiet alle Flurstücke und die zugehörigen 
Eigentümer. Ein Flurstück
wechselt seinen Eigentümer. Der Eigentümer ist aus Sicht des Nutzers neu 
(Insert) aus
Sicht des ALKIS-Führungssystems aber alt (Replace), weil er bereits an 
Flurstücken
außerhalb des Interessengebiets Eigentum hatte und deshalb seit langem 
im abgebenden
System geführt wird, jedoch noch nie im System des Nutzers geführt wurde.)"

Das aufnehmende System muss mit dieser falschen Reihenfolge umgehen 
können. Das bedeutet:
-          das zuerst vorkommende „Replace“ muss als „Insert“ 
interpretiert werden
-          das folgende „Insert“ muss dann nachträglich „eingeschoben“ 
werden.

Sicherlich hängt es auch von der verwendeten Abgabe-Software ab. Wir 
haben dieses Problem aber bei allen von uns betreuten Katasterämtern 
gehabt. Meistens immer bei Eigentumsänderungen.

Gruß,

Stefan Rahn

-- 
  
GDI-Service
Friedrichstraße 16
18057 Rostock
Tel: 0381 40344445
E-Mail: stefan.rahn at gdi-service.de
gdi-service.de

Am 04.05.2020 um 15:31 schrieb 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.
>