[NAS] Test PostNAS 0.5

[Jäger, Frank (KRZ)]

Hallo,
die seit gestern als Windows-Version verfügbare PostNAS-Version 0.5 habe ich unter Linux bereits ausführlich getestet.

- Die "Beziehungen" im Teil Buchwerk werden gespeichert
- Fortführungen nach dem NBA-Verfahren werden verarbeitet

Beides ist in Details noch fehlerhaft.


Generell:

Der Konverter legt sich die Datenbank-Struktur selbst an. Dazu wird der Inhalt der zu konvertierenden NAS-Datei analysiert.
Für die Konvertierung von einzelnen Dateien funktioniert das, allerdings fällt das Ergebnis - also das Datenbank-Schema - bei verschiedenen Ausgangsdaten unterschiedlich aus. Das ist schlecht für die Programme, die damit weiter arbeiten sollen.

Bei der Konvertierung eines "gekachelten" Datenbestandes und bei Fortführungen mit dem NBA-Verfahren kann dieses Vorgehen nicht funktionieren. Ich habe mir daher ein SQL-Script zum Anlegen der Datenbank erarbeitet, dass nun schrittweise verfeinert wird.
Es ist dabei nicht immer einfach, den Konverter zu überlisten. Ein Beispiel: Die Beziehung "Adresse - Straßenschlüssel".

Der Straßenschlüssel der Adresse ist: ax_lagebezeichnungmithausnummer.lage  integer
Der ForeignKey dazu ist: ax_lagebezeichnungkatalogeintrag.lage character varying(5)

Straßenschlüssel (NRW) sind in Adressen (Straße-Hausnummer) immer numerisch, daher wählt der Konverter Integer-Format.
In der Schlüsseltabelle steht jedoch auch der Sonderfall "Bahnstrecke", der ein nicht numerisches Zeichen enthält. Daher wählt der Konverter das Character-Format. 
Beides ist schlecht zu verbinden. Der Konverter betrachtet nicht die Verbindung sondern nur jede Tabelle einzeln.

Wenn man nun das Feld "ax_lagebezeichnungmithausnummer.lage" im SQL-Script ebenfalls als Character anlegt, dann füllt der Konverter es *ohne* führende Nullen, während "ax_lagebezeichnungkatalogeintrag.lage" *mit* führenden Nullen eingetragen ist. Auch hier keine Equivalenz.


Beziehungen:

Es werden keine ForeinKey-Constraints angelegt.
Es werden auch keine Beziehungen zwischen den Tabellen selbst aufgebaut, die einen direkten "SELECT ... JOIN" möglich machen.
Statt dessen werden ALLE Beziehungen in einer zentralen Tabelle "alkis_beziehungen" gespeichert.
Dort findet man die Felder "beziehung_von", "beziehungsart", "beziehung_zu".
"_von" und "_zu" verweisen auf die "gml_id" von verschiedenen Tabellen. Aus der Beziehungart kann man erraten, welche das sein könnten.
Dies ist nicht unbedingt ein übliches DB-Design. SQL-Selects im Buchwerk werden länger als bisher im ALB weil aus jedem JOIN jetzt ein doppelter JOIN wird. Verbindet man mehrere Tabellen (z.B. Flurstück - Buchung - Grundbuch - Namensnummer - Eigentümer) dann ist die Tabelle alkis_beziehungen im Join mehrfach enthalten.


NBA-Verfahren:

Ich habe festgestellt dass bei Eigentumsübergang die alten Eigentümer nicht gelöscht werden.
Bei Änderung einer Adresse wird die alte Adresse nicht gelöscht.
Auch die Beziehungen dazu bleiben erhalten.

In der Buchwerks-Auskunft werden daher bei fortgeführten Fällen alte und neue Eigentümer sowie alte und neue Adressen angezeigt.


Buchwerks-Auskunft:

Ich habe begonnen, eine Buchwerks-Auskunft auf Basis der Datenstruktur PostNAS 0.5 mit PHP zu schreiben. Das Programm wird gestartet über eine WMS-Feature-Info auf dem Layer "Flurstück".


Fragen:

Bug-Tracker? - Wo kann ich die oben beschriebenen Fehler dokumentieren, damit sie behoben werden.



Mit freundlichen Grüßen
Frank Jäger

Kommunales Rechenzentrum
Minden-Ravensberg/Lippe