[PostNAS Suite] fehlende "ax_person", View zur Fehlersuche

[Jäger, Frank (KRZ)]

Hallo,
in der Praxis macht sich derzeit ein Fehler des abgebenden NBA-Verfahrens im ALKIS des Katasteramtes störend bemerkbar. Also kein Fehler von PostNAS.
Ich habe in "import/sichten.sql" neue Views ("fehlersuche_nba_person_*") eingefügt, mit denen man prüfen kann, ob der Fehler im Sekundärbestand auftritt.

Symptom: Es fehlen Einträge in "ax_person".
Das tritt nur auf, wenn Aktualisierungen stattgefunden haben, nach der Erstabgabe ist noch alles vollständig.
Das tritt nur auf, wenn ein (räumlich) begrenzter Teil eines Katasterbezirkes ausgegeben wird, also z.B. ein Stadtgebiet aus einem Kreisgebiet.

Wahrscheinliche Fehler-Entstehung:
Ein Flurstück und eine Person (Eigentümer) existieren im Katasterbezirk beide schon bei der Erstabgabe.
Das Flurstück liegt im räumlich gefilterten Bereich, es wird ausgegeben.
Die Person hat aber zum Zeitpunkt der Erstabgabe keine Relation zum Flurstück (über Zwischenstationen). Sie wird also nicht ausgegeben.

Dann erwirbt die Person Eigentum am Flurstück. Die Buchungen auf einem Grundbuch ändern sich. Es werden alle geänderten Elemente bei der nächsten NBA-Aktualisierung ausgegeben, z.B. die Spalte "ax_namensnummer.benennt" die als Inhalt die "gml_id" der Person führt. Es wird aber vergessen, die Person selbst in der NBA-Aktualisierung mit zu liefern. Die Person selbst ist ja auch "unverändert". Zum Zeitpunkt der Erstabgabe hatte sie keinerlei Verbindung zu Flurstücken aus dem Abgabegebiet, nun hat die Person eine solche Verbindung. Sie wird in einer Relation "erwähnt". Dieser Unterschied wird nicht erkannt. Somit führt die Relation innerhalb des Sekundärbestandes dann ins Leere.

Nach meiner Analyse tritt der Fehler bei beiden Software-Herstellern für ALKIS etwa gleich oft auf.

Im "Bestandsnachweis" der "Buchauskunft" ist dieser Fall daran erkennbar, dass die Namennummer aufgelistet wird, aber kein Name dahinter steht. Hier wird bewusst kein JOIN verwendet, der auch die Nummer verschwinden ließe.

Eine Stadt in unserem Verbandsgebiet konvertiert mit PostNAS nach SQLite statt nach PostGIS. Ich habe mir zur Fehleranalyse mal die geladene SQLite-Datenbank geben lassen, in der der Fehler aufgefallen ist. Die PostGIS-Views funktionieren darin nicht, weil in SQLite die Relationen noch über die alte Tabelle "alkis_beziehungen" verbunden werden ("hat" und "benennt" sind leer).
Ich wollte eigentlich schon vorschlagen, die Tabelle "alkis_beziehungen" mal fallen zu lassen. Aber wenn es keine ANY()-Funktion gibt, dann kann man auch keine 1:N-Relationen über sowas wie "ANY (ax_person.hat=ax_anschrift.gml_id)" aufbauen.
Eine SQLite-taugliche Version des Views habe ich auch mit eingefügt. Die funktioniert auch in PostGIS, aber nur wenn man "alkis_beziehungen" in Ruhe gelassen hat.
Ich truncate das auch schon mal, da das in PostGIS eigentlich überflüssig ist. 

Mit freundlichen Grüßen
Frank Jäger

Kommunales Rechenzentrum
Minden-Ravensberg/Lippe
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 4264 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.osgeo.org/pipermail/nas/attachments/20160301/9665a1c3/attachment.bin>