[PostNAS] alte Einträge in der alkis_beziehungen vorhanden

Fr Feb 22 01:07:09 PST 2013

Guten Morgen!

war gestern leider nicht im Büro...

> Haben sie die Abfrage auch mal auf "meine" Datenbank losgelassen?
Wie komme ich denn da dran?

Ich meinte den Datensatz meines Kunden aus B.O. aber das war auch nicht
wirklich ernst gemeint, sorry.

Abstimmen bringt wahrscheinlich nicht viel, aber mir erscheint der
Vorschlag C auch am sinnvollsten und nachvollziehbarsten.

Schönen Gruß

PS Ich hoffe auf gute Fernsicht im Norden... ;)

Bernd Kamjunke 
_________________________________________________________________
CSO GmbH 
Informations-Lösungen 
Forsthausstrasse 2 
75180 Pforzheim 
Fon     +49 (0) 72 31 . 97 35 63 (direkt)
Fon     +49 (0) 72 31 . 97 35 10 (Zentrale)
Fax      +49 (0) 72 31 . 97 35 90 
eMail  Bernd.Kamjunke at csogis.de  
web    www.csogis.de 
_________________________________________________________________

Geschäftsführer  Jörg Schempf, Dipl.-Ing. (FH) 
Amtsgericht Mannheim . HRB 503836 
UST-ID  DE 144 17 16 31 
_________________________________________________________________ 

-----Ursprüngliche Nachricht-----
Von: nas-bounces at lists.osgeo.org [mailto:nas-bounces at lists.osgeo.org] Im Auftrag von Jäger, Frank (KRZ)
Gesendet: Mittwoch, 20. Februar 2013 18:32
An: 'NAS Schnittstelle via ogr2ogr'
Betreff: Re: [PostNAS] alte Einträge in der alkis_beziehungen vorhanden

Hallo,

> Haben sie die Abfrage auch mal auf "meine" Datenbank losgelassen?
Wie komme ich denn da dran?

> Außerdem ging ich bisher ebenfalls davon aus, das ein Flurstück immer nur eine Buchungsstelle hat...

Einige der von der Abfrage gelieferten gml_id's mit 2 Buchungsstellen habe ich mir mal mit der PHP-Buchauskunft angeschaut. Die sehen tatsächlich falsch aus.

Aber ein Flurstück kann ja durchaus mit mehreren Grundbüchern verbandelt sein!? Ich habe mir also mal einen Fall mit Wohnungs-/Teileigentum angeschaut:
 Da ist auch genau eine Buchungsstelle mit ' istGebucht' auf Buchungsart 1101 (Aufgeteiltes Grundstück WEG).
Andere Buchungsstellen (Buchungsart ' 1301' =Wohnungs-/Teileigentum) haben dann ein Recht (mit Beziehungsart=)  'an' dieser Buchungsstelle. Da ist die Tabelle 'ax_buchungsstelle' also mit sich selbst verbunden. Es scheint somit korrekt zu sein, dass ein FS nur eine Buchungsstelle haben kann.

Das hilft uns, dies eindeutig als Fehler des Konverters zu erkennen. Aber diese Erkenntnis hilft uns nicht wirklich bei der generellen Lösung. Wir müssen nämlich mal weg von dem speziellen Fall 'ax_flurstueck' für den wir jetzt auf Grund dieser Randbedingungen ("Es kann nur einen geben") eine Sonderbehandlung finden könnten. Es gibt ja noch dutzende andere Objekte, die möglicherweise auch falsch replaced werden. Die 'alkis_beziehungen' werden ja generell für alle Relationen zwischen Objekten verwendet.

Was passiert?

Da erfolgt also ein "replace" in einer Tabelle für ein Objekt, dass auch noch Relationen in "alkis_beziehungen" hat.

Die Einträge in 'alkis_beziehungen', die zuvor mit dem alten Objekt eine von- oder zu-Verbindung hatten, müssen mit dem Objekt zusammen gelöscht werden. 
Der passende Ort dazu wäre 'FUNCTION delete_feature_kill()'  (siehe Datei 'alkis-functions.sql'). Ein Gedanke von mir dazu (noch auskommentiert) findet sich bereits bei "-- ENTWURF ungetestet".
Diese Variante geht aber - genau wie der Workaround nach dem Laden - davon aus, dass die gml_id-Einträge auf von- und zu-Seite in den alten und neuen Sätzen identisch sind.
Wie wir gerade messerscharf analysiert haben, wurde aber nicht nur das Objekt ausgetauscht sondern auch "die andere Seite" der Relation (von/zu) verweist nun auf eine andere gml_id. Das wurde in einem Abwasch mit geändert. Pech, denn das ist der Grund, warum sie vom Workaround nicht erwischt wird.

Der Workaround löscht nur redundante (doppelt eingetragene) Relationen, keine "geänderten" Relationen.

Dummerweise wird der Trigger der 'FUNCTION delete_feature_kill()' erst aufgerufen, wenn das neue Objekt (hier ax_flurstueck) und seine Relationen bereits eingefügt wurden. Die gml_id ist die gleiche, daran kann man also das alte und neue Objekt nicht unterscheiden. Derzeit wird das "jüngste" (laut Feld 'beginnt') leben gelassen.

Aber wie könnte man bei den Einträgen in 'alkis_beziehungen' die alten von den neuen Zeilen unterscheiden? 
Da bleibt nur das serial-Feld 'alkis_beziehungen.ogc_fid' als Indikator für eine Reihenfolge. Wenn es aber nicht um Buchungsstellen von Flurstücken geht, also mehrere Beziehungen mit gleicher Beziehungsart existieren können, dann grenzt die Reihenfolge nicht eindeutig die alten von den neuen Beziehungen ab.

Es wäre ja (für die -kill-Variante) alles viele einfacher, wenn PostNAS zunächst den replace-Satz in die Delete-Tabelle schreiben würde, was den Trigger auslöst, welcher alle alten Einträge säubert. Danach würde dann das neue Objekt und seine neuen alkis_beziehungen eingetragen.
Ich hatte schon mal vorgeschlagen, das so zu ändern, bekam aber Gegenwind von der -hist-Fraktion.  
Guggst du http://lists.osgeo.org/pipermail/nas/2012-November/000458.html 

Das Grundproblem scheint mir, dass die im statischen Zustand eigentlich eindeutige Kennung zu einem Objekt, die "gml_id", während der Aktualisierung temporär ihre Eindeutigkeit verliert. Da gibt es kurzfristig ein altes und neues Objekt mit dem gleichen Schlüssel und leider auch Relationen, die ausschließlich diesen nicht mehr eindeutigen Schlüssel verwenden.
Während der Replace gerade bearbeitet wird, also ausgerechnet in der Function, die das regeln soll, sind alte und neue Objekte und somit ihre Beziehungen an der gml_id nicht mehr zu unterscheiden.
Die Struktur der Tabelle 'alkis_beziehungen' basiert derzeit nur auf der Verknüpfung über diesen Schlüssel 'gml_id'. 

Brainstorming - Verschiedene Lösungsansätze:

A.
Wir brauchen die Felder 'alkis_beziehungen.von_ogc_fid' und 'alkis_beziehungen.zu_ogc_fid' ODER 'alkis_beziehungen.von_beginnt' und 'alkis_beziehungen.zu_beginnt' um die Verknüpfungen zu den Objekten auch während der Replace-Bearbeitung auf eindeutige Feldkombinationen zu erweitern.
Diese Schlüsselerweiterungen müssen schon befüllt sein, bevor der Trigger ausgelöst wird.

B.
PostNAS könnte über einen Parameter gesteuert werden um die Reihenfolge zu beeinflussen und so den Bedürfnissen der -hist- und der -kill-Fraktion gerecht zu werden.

Modus=kill: Erst Einträge in delete-Tabelle machen, dann in die sauberen Tabellen (vom Trigger bereinigt) die neuen Objekte und Beziehungen eintragen. 
Modus=hist: Erst die Objekte eintragen um danach im Trigger Zugriff auf alt und neu zu haben um den Beginn des neuen Objektes zum Ende des Alten zu machen.

C.

Eine zusätzliche Spalte (mindestens) in 'alkis_beziehungen'. Z.B. ein Duplikat der Spalte 'delete.context' in der neuen Zeile.
PostNAS kann darin temporär die Zeilen kennzeichnen, die aus einer replace-Verarbeitung stammen.
Das versetzt den Trigger in die Lage, die neuen (context = 'replace') und alten (zu ersetzenden) Zeilen zu unterscheiden.
Auch bei allen anderen Objekt-Tabellen, die in einem Replace verarbeitet werden, täte dies Feld gut. Die Rumeierei mit "das jüngste bleibt erhalten" könnte man sich sparen.

D.

Noch viel mehr Logik in den Trigger packen:
Aus der delete-Tabelle die lange Version der 'featureid' und 'replacedby' holen.
Dies jeweils in 'gml_id' und 'beginnt' zerlegen.
Damit die Objekte eindeutig in alt und neu unterscheiden. 

E.

?
Ihr seit dran!

Die Kombi aus "D für Objekte" und "C für Beziehungen" erscheint mir derzeit am sinnvollsten. 

So, mir reicht's für heute.

Schönen Feierabend.

F.J.