[PostNAS] alte Einträge in der alkis_beziehungen vorhanden

Do Jul 4 07:41:06 PDT 2013

Hallo NAS Gemeinschaft,

wir haben uns auf dem NAS-Anwendertreffen im Rahmen der FOSSGIS 2013 noch einmal über das Problem, dass Zuordnungen zwischen Flurstücken und Buchungsstellen teilweise nicht richtig aktualisiert werden unterhalten.

Astrid hatte den Vorschlag gemacht, den Sachverhalt noch einmal in der Mailingliste aufzugreifen und versuchen zu klären.

Also hier noch einmal der Sachverhalt, der bei uns zu einem Fehler führte.

Einem Flurstück ist immer eine Buchungsstelle zugeordnet. Diese Beziehung wird über die Tabelle alkis_beziehungen geregelt.
Hier unser Beispiel. Das Flurstück mit der gml_id DENWAL12000019aX ist auf die Buchungsstelle DENWAL1200001bvA gebucht. Hier ein Auszug aus der alkis_beziehungen:

		ogc_fid  |  beziehung_von             | beziehungsart |   beziehung_zu              | dummy
		-----------+------------------------------+-------------------+------------------------------+-------
		 761300 | DENWAL12000019aX | istGebucht      | DENWAL1200001bvA |

Dieses ist auch noch absolut normal. Nun kommt jedoch eine Aktualisierung über NBA. Diese NAS-Datei teilt uns nun einen replace Datensatz mit.
Hier eine kurzer Auszug aus der NAS-Datei mit den relevanten Daten:

	<wfsext:Replace vendorId="AdV" safeToIgnore="false">
		<AX_Flurstueck gml:id="DENWAL12000019aX20130219T094303Z">
			<gml:identifier codeSpace="http://www.adv-online.de/">urn:adv:oid:DENWAL12000019aX</gml:identifier>
			<lebenszeitintervall>
				<AA_Lebenszeitintervall>
					<beginnt>2013-02-19T09:43:03Z</beginnt>
				</AA_Lebenszeitintervall>
			</lebenszeitintervall>
			[...]
			<istGebucht xlink:href="urn:adv:oid:DENWAL120000o3SM"/>
			<zeigtAuf xlink:href="urn:adv:oid:DENWAL1200001b5c"/>
		</AX_Flurstueck>
		<ogc:Filter>
			<ogc:FeatureId fid="DENWAL12000019aX20121002T132006Z" />
		</ogc:Filter>
	</wfsext:Replace>

Aus dieser NAS-Datei ist zu erkennen, dass diesem Flurstück nun die Buchungsstelle mit der gml_id DENWAL120000o3SM zugeordnet werden soll und keine andere mehr.
Nach der Aktualisierung mit PostNAS habe ich noch einmal die beziehungs-Tabelle gefiltert und mir die Beziehungen für dieses Flurstück angeschaut.

	ogc_fid   |  beziehung_von            | beziehungsart |   beziehung_zu               | dummy
	------------+-----------------------------+-------------------+-------------------------------+-------
 	3621489 | DENWAL12000019aX | istGebucht      | DENWAL120000o3SM |
  	761300   | DENWAL12000019aX | istGebucht      | DENWAL1200001bvA  |

Man sieht, dass hier die neue, sowie die alte Beziehung eingetragen ist. Dieses sollte nicht der Fall sein. 
Nun gibt es hier eine Besonderheit. Die Buchungsstelle ist jedoch weiterhin in der Datenbank vorhanden, da noch weitere Flurstücke darin gebucht sind und diese auch weiterhin so gebucht sind.

Generell kann man eigentlich sagen, dass ein Flurstück nur auf eine Buchungsstelle gebucht sein darf. Diese Buchungsstelle kann wiederum in weiteren Buchungsstellen gebucht sein wie z.B. in Aufteilungen von Flurstücken.

Mit folgendem SQL kann abgefragt werden, ob Flurstücke mit mehr als einer Zuordnung zu einer Buchungsstelle in der Datenbank vorhanden sind:

SELECT gml_id,anzahl 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

Dieser Fehler taucht also explizit bei der Aktualisierung durch NBA erzeugte NAS-Daten auf. Da in vielen Bereichen noch kein Aktualisierungen eingespielt worden sind, kann es sein, dass dieser Fehler noch nicht überall aufgetaucht ist. 

Ich habe mir einen Workaround gebaut, der mir alle Flurstücke heraussucht, die mehr als einen Eintrag in Beziehungs Tabelle mit der Beziehungsart "istGebucht" haben und löscht danach die Beziehung mit der kleinen ogc_fid. Daher wird immer die ältere Beziehung gelöscht. Hier noch einmal der SQL dazu:

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);

ACHTUNG! Neuer Fehler aufgetaucht!

Ich habe diese Mail schon vor einigen Tagen angefangen zu schreiben. Jetzt ist direkt ein weiterer Fehler mit dieser Problematik aufgetaucht. Ideal zum Testen!

Hier der neu aufgetauchte Sachverhalt.
Im Katasteramt wurden zwei Flurstücke getauscht. Flurstück mit dem Zähler 332 sollte den Zähler 333 bekommen und umgekehrt. War wohl ein Fehler damals. 
Auf beiden Flurstücken steht ein Gebäude. Auf dem Flurstück mit dem Zähler 332 stand das Gebäude mit der Hausnummer 37 und auf dem Flurstück mit dem Zähler 333 das Gebäude mit der Hausnummer 35.
Nach dem Tausch der Flurstücksnummern sollte somit das Flurstück mit dem Zähler 332 das Gebäude mit der Hausnummer 35 und das Flurstück 333 das Gebäude mit der Hausnr. 37 bekommen.
Nach dem einspielen der NAS-Datei waren jedoch auf beiden Flurstücken die lagebezeichnungmithausnummer beider Gebäude zugeordnet. 

In der NAS-Datei war jedoch jeweils nur eine Beziehung eingetragen. Es wurde also die alte Beziehung wieder nicht aus der Tabelle alkis_beziehungen gelöscht und die neue Beziehung eingetragen.

Ich habe zwei NAS-Dateien erzeugt mit Testdaten. In der insert.xml wird das Flurstück in die Tabelle ax_flurstueck erstmalig eingetragen.
In der zweiten Datei, die replace.xml wird dieses Eintrag ersetzt. Man sieht hier, dass nur ein Eintrag mit der Beziehungsart "weistAuf" eingetragen ist. Dieser sollte aktualisiert werden. Nach dem Import stehen jedoch beide dort drin.

Es ist also bestätigt, dass der Fehler auch in weiteren Zusammenhängen auftreten kann. Wir sollten also schnellstmöglich daran arbeiten diesen Fehler heraus zu bekommen.
Vor allem, wenn andere Benutzer ebenfalls damit beginnen die ersten Veränderungsdaten einzuspielen.

Ich hätte vielleicht schon einen Vorschlag zur Problembehebung.

Vielleicht hilft ein endet-Datum in der alkis_beziehungen. Dieses kann gesetzt werden, wenn ein Datensatz ersetzt wird. 
Oder man kann es irgendwie über den Trigger regeln. Ich denke, das wäre generell auch möglich.
Ich werde mir die Datenbank einmal anschauen und auch ein paar Tests hier in einer Testdatenbank durchführen und es danach in der Liste berichten.

Generell wäre es jedoch sinnvoll, wenn auch andere Personen vielleicht an einer Lösung arbeiten würden.

Diese Mail soll noch einmal als Auftakt dienen und vielleicht eine Diskussion anstoßen um dieses Problem für alle Benutzer zu lösen.
Gerne möchte ich auch aktiv daran mitarbeiten. 

Viele Grüße aus Unna.

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

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : insert.xml
Dateityp    : text/xml
Dateigröße  : 8823 bytes
Beschreibung: insert.xml
URL         : <http://lists.osgeo.org/pipermail/nas/attachments/20130704/c46b4115/attachment-0002.xml>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : update.xml
Dateityp    : text/xml
Dateigröße  : 9137 bytes
Beschreibung: update.xml
URL         : <http://lists.osgeo.org/pipermail/nas/attachments/20130704/c46b4115/attachment-0003.xml>