[PostNAS] alte Einträge in der alkis_beziehungen vorhanden

Mi Feb 20 09:27:52 PST 2013

Das ist ja schon einmal gut zu hören. Dann bin ich wohl nicht alleine mit diesem Problem. Herzlichen Glückwunsch :-)
Die Anzahl ist wohl nur 2, da ein Flurstück seit Erstladen der Daten nur einmal einer neuen Buchungsstelle zugeordnet wurde. In Zukunft könnte die Anzahl sicher auch höher werden.
Uns ist der Fehler aufgefallen, da in der ALKIS-Info Webauskunft der alte, sowie der neue Eigentümer aufgeführt war. Können Sie vielleicht noch einmal prüfen, ob dieses bei Ihnen ebenfalls der Fall ist?

Ich habe mir erschlossen, dass ein Grundstück immer nur einer Buchungsstelle zugeordnet werden kann. Der Hintergrund ist folgender. Ein Flurstück wird entweder einem Grundbuchblatt zugeordnet, dann nur einer Buchungsstelle, oder einem fiktivem Grundbuchblatt, dann ebenfalls einer Buchungsstelle diese jedoch wieder mit weiteren Buchungsstellen verknüpft ist.
Um den Fehler kurzfristig aus der Datenbank zu entfernen habe ich mir folgenden SQL-Befehl gebaut, den ich in das PostProcessing eingebaut habe:

DELETE 
FROM alkis_beziehungen a1
WHERE a1.beziehung_von = ANY(SELECT gml_id FROM (
				SELECT 
					f.*,
					(SELECT count(f2.gml_id) as anzahl
						FROM ax_flurstueck f2
						JOIN alkis_beziehungen a1 ON f2.gml_id = a1.beziehung_von AND a1.beziehungsart = 'istGebucht'
						WHERE f2.gml_id = f.gml_id
					) as anzahl
				FROM ax_flurstueck f
				) as sub
			WHERE sub.anzahl > 1 )
AND a1.beziehungsart = 'istGebucht'
AND a1.ogc_fid = (SELECT min(sub.ogc_fid) as ogc_fid FROM (
	SELECT 
		a1.*,
		(SELECT count(f2.gml_id) as anzahl
			FROM ax_flurstueck f2
			JOIN alkis_beziehungen a1 ON f2.gml_id = a1.beziehung_von AND a1.beziehungsart = 'istGebucht'
			WHERE f2.gml_id = f.gml_id
		) as anzahl
	FROM ax_flurstueck f
	JOIN alkis_beziehungen a1 ON f.gml_id = a1.beziehung_von AND a1.beziehungsart = 'istGebucht'
	) as sub
WHERE sub.beziehung_von = a1.beziehung_von);

Dieser macht nichts anderes als zu schauen, ob es Flurstücke mit mehreren Einträgen in der alkis_beziehungen gibt die die Buchungsart 'istGebucht' besitzen.
Wenn ja, dann lösche ich die ältere der beiden. Dieses erkenne ich an der niedrigeren ogc_fid. Jedoch Vorsicht! Die Sequenz in Postgres hat zwar einen sehr hohen Maximalwert. Wird dieser jedoch erreicht nach Jahrelanger Fortführung, dann beginnt die Sequenz von vorne zu zählen und dann funktioniert dieses nicht mehr!

Um diesen Fehler auszuschließen würde ich vorschlagen, die Stelle zu finden, an der die neue Verbindung in die alkis_beziehungen eingetragen wird und dort anzusetzen und den alten Eintrag heraus zu nehmen. Dann wäre die Datenbank auch bereits während der Laufzeit richtig und man bräuchte nichts mehr über das PostProcessing unternehmen.

Den Fehler habe ich nun auch noch einmal genauer erkundet.
Wenn ein vorhandenes Flurstück einer neuen Buchungsstelle zugeordnet wird und die alte Buchungsstelle wird durch die NAS-Datei gelöscht, dann wird auch der Eintrag in der alkis_beziehungen gelöscht.
Wenn aber das vorhandene Flurstück einer neuen Buchungsstelle zugeordnet wird und die alte Buchungsstelle wird nicht gelöscht, da an ihr noch andere Flurstücke hängen, wird der Eintrag aus der alkis_beziehungen nicht gelöscht.

Daher eine Vermutung von mir.
Beim Löschen einer Buchungsstelle wird geprüft, ob noch eine Verbindung in der alkis_beziehungen für diese Buchungsstelle vorhanden ist. Wenn ja, dann wir diese ebenfalls mit gelöscht.
Das macht soweit auch Sinn, um keine alten Daten in der Datenbank zu hinterlassen.
Jedoch fehlt eine Prüfung beim Überschreiben oder Update einer Flurstückes. Es wird zwar eine neue Beziehung eingetragen, jedoch wird da wohl nicht geprüft, ob eine alte vorhanden ist.
Ich stelle mir eigentlich vor, dass wenn ein Update-Satz über NAS ankommt, dass zuerst geprüft wird, ob bereits Beziehungen eingetragen sind. Wenn ja, dann wird geprüft, ob diese eingetragenen Beziehungen mit den neuen Beziehungen identisch sind. Sollte dieses der Fall sein, müsste nichts weiter unternommen werden.
Sind die eingetragenen Beziehungen und die neuen Beziehungen jedoch nicht identisch, müssten die alten zuerst gelöscht werden und die neuen danach eingetragen werden. Optimal wäre dieses natürlich in einer Transaktion um auszuschließen, dass einer der beiden Schritte fehlschlägt.

Nun ist nur noch die Frage, an welcher Stelle das ganze geschehen muss. Also wer eigentlich die Beziehung einträgt. Ich könnte mir vorstellen ogr2ogr, da ich in den Skripten keinen Anhaltspunkt dafür gefunden habe.
Ich würde dabei gerne mithelfen, aber habe damit absolut keine Erfahrung.

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

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

...
Daher habe ich mir folgenden SQL-Befehl gebaut und bekomme damit alle Flurstücke die mehr als eine Verknüpfung mit der Beziehungsart 'istGebucht' haben.

...

Vielleicht kann jemand mal prüfen, ob in seiner Datenbank auch solche Doppelungen vorhanden sind.

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