[PostNAS] alte Einträge in der alkis_beziehungen vorhanden

Mi Feb 20 22:34:24 PST 2013

Hallo,

die Idee mit dem fehlerhaften replace auch auf andere Objekte hatte ich auch schon. Man kann es ja wirklich nicht ausschließen, dass es nicht auch bei anderen Beziehungen auftaucht.

An die Benutzer, die die hist-Variante benutzen habe ich nicht gedacht.

Daher denke ich, macht es Sinn, auch bei der alkis_beziehungs Tabelle ein beginn und endet Datum einzuführen. Nur so können alle Varianten heraus bekommen, ob ein Eintrag dort noch gültig ist oder nicht. 

Mit freundlichen Grüßen
Im Auftrag

Marvin Brandt

Kreis Unna - Der Landrat
Zentrale Datenverarbeitung
DV-Verfahren 
Friedrich-Ebert-Straße 17
59425 Unna

Fon 0 23 03 / 27-14 16
Fax 0 23 03 / 27-28 96
marvin.brandt at kreis-unna.de
www.kreis-unna.de

-----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.

-----Ursprüngliche Nachricht-----
Von: nas-bounces at lists.osgeo.org [mailto:nas-bounces at lists.osgeo.org] Im Auftrag von Bernd Kamjunke
Gesendet: Mittwoch, 20. Februar 2013 16:25
An: NAS Schnittstelle via ogr2ogr
Betreff: Re: [PostNAS] alte Einträge in der alkis_beziehungen vorhanden

Hallo Herr Jäger!

Haben sie die Abfrage auch mal auf "meine" Datenbank losgelassen?
Ich bekomme jedenfalls keine Treffer, egal ob Grunddatenbestand oder (immer noch fehlerhafte) Fortführungen. Außerdem ging ich bisher ebenfalls davon aus, das ein Flurstück immer nur eine Buchungsstelle hat...

Herzlichen Gruß

Bernd Kamjunke
..

-----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 16:12
An: 'NAS Schnittstelle via ogr2ogr'
Betreff: Re: [PostNAS] alte Einträge in der alkis_beziehungen vorhanden

Ich habe mit diesem SQL mehrere ALKIS-Datenbanken ausgewertet.
In allen Datenbanken wurden Sätze geliefert (zwischen 4 und 80 Fälle).
Die Anzahl war immer 2.

F.J.

_______________________________________________
NAS mailing list
NAS at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/nas
Denken Sie an die Umwelt. Pruefen Sie deshalb bitte, 
ob der Ausdruck dieser E-Mail wirklich notwendig ist.

Diese E-Mail wurde beim Ausgang auf Viren geprueft. Wegen der 
potentiellen Gefahr auf den Uebertragungswegen wird zu einer 
Vireneingangskontrolle geraten. Eine Haftung für Virenfreiheit
wird ausgeschlossen.