[PostNAS] Buchauskunft: Flurstückshistorie (Vorgänger suchen) u.a.

["Jäger, Frank (KRZ)"]

Hallo,
ich habe die Web-Buchauskunft überarbeitet. Die geänderte Version habe ich eben ins SVN hochgeladen. Z.B. [1].

* Neue Fenster

Die Buchauskunft wird aus der Navigation und aus der (Inlay-) Feature-Info jetzt mit javascript-Function in einem neuen Fenster geöffnet, das 620x800 Pixel im Hochformat groß ist. Dies Hochformat entspricht eher der (auch am Druck orientierten) Aufteilung der Seite mit Seitenkopf und Seitenfuß.
Wenn sich das neue Fenster bisher - abhängig von den Browser-Verstellungen - als neuer Vollbild-Tab auf einem dieser immer breiter werdenden Bildschirme öffnete, dann waren die Zeilen zu weit auseinander gerissen.
Ich hoffe, das ist zu allen Browser-Typen kompatibel. 


* Flurstücks-Historie

Es ist nun auch möglich, zu einem aktuellen Flurstück die Vorgänger zu suchen.

In der Datenbank ist das etwas unglücklich designt:
- Die historischen Tabellen haben Array-Felder mit den Kennzeichen der Nachfolger
- Das aktuelle FS hat aber *keine* Verweise auf seine Vorgänger

Um die Vorgänger eines aktuellen FS zu suchen, muss man also in "ax_historischesflurstueck" und in "ax_historischesflurstueckohneraumbezug" in der Spalte "nachfolgerflurstueckskennzeichen" mit "ANY" nachschlagen, ob das gesuchte Kennzeichen als ein Element des Array irgendwo vorkommt.
Ich bin mir nicht sicher, ob ein Datenbank-Index auf dem Feld diese Suche im Array wesentlich verbessern würde.

Die Postgresql-Dokumentation sagt [2]:
"... searching for specific array elements can be a sign of database misdesign.
Consider using a separate table with a row for each item that would be an array element.
This will be easier to search, and is likely to scale better for a large number of elements."

Ich hatte daher in ersten Anlauf nur die Suche in Richtung der Verweise realisiert. Zu einem alten Flurstückskennzeichen konnte man also die Nachfolger recherchieren.
Meine Anwender haben aber protestiert: Sie benötigen auch die Suche nach Vorgängern eines aktuellen FS.

Ich merke in einem Bestand, der ein Stadtgebiet enthält, keine Verzögerung. In einer größeren Datenbank könnte das anders aussehen.
Man müsste das nach der Konvertierung in eine bessere Struktur umsetzen. Ein SQL-Befehl, der aus (redundanten?) Arrays saubere Verbindungstabellen macht, fällt mir aber gerade nicht ein.
Vielleicht muss man da noch eine Prozedur schreiben.

Die Filterung über Gemarkung und Flur - um die Menge der zu durchsuchenden Arrays einzuschränken - habe ich wieder auskommentiert. Man würde keine Umflurung oder Umgemarkung mehr finden. Das ist selten, aber kommt vor.

Die Tabelle "ax_historischesflurstueck*alb*" ist in meinen Beständen leer und wird daher in den PHP-Programmen nicht berücksichtigt. Allerdings ist sie gefüllt in der RLP-Demo "Mustermonzel".
Ist das bundesland-spezifisch, oder nur ein Überbleibsel der GID 5? 


* Kommunikation

Mich würde mal interessieren, wo die Buchauskunft und/oder die ALKIS-Navigation für Mapbender überhaupt eingesetzt wird.
Diese Nachnutzung ist ja nur ein Randgebiet von "NAS-Konverter" und gehört vielleicht nicht hier her.
Ich möchte die Anwender von PostNAS, die das für ganz andere Zwecke brauchen, hier nicht nerven. Ich könnte mir auch einen (zusätzlichen) Mailverteiler ausserhalb dieser Liste aufbauen.
Anwender von Buchauskunft und Mapbender-Navigation könnten sich also bitte mal bei mir melden.

Links:

[1] http://trac.wheregroup.com/PostNAS/browser/trunk/var/www/info/alkis/alkisfshist.php

[2] http://www.postgresql.org/docs/9.1/static/arrays.html

Mit freundlichen Grüßen
Frank Jäger

Kommunales Rechenzentrum
Minden-Ravensberg/Lippe