[PostNAS] Überarbeitet: Schätzungsergebnisse, Texte, Navigation

Mo Apr 29 04:04:46 PDT 2013

Hallo Freunde von PostNAS,
ich habe in den letzten Wochen ein paar Verfeinerungen an der Nutzung der PostNAS-ALKIS-Daten vorgenommen und diese kürzlich auch ins SVN hoch geladen.

http://trac.wheregroup.com/PostNAS/changeset/278 
http://trac.wheregroup.com/PostNAS/changeset/279/

Ich möchte schildern, was sich geändert hat:

** ALKIS-WMS:

- Schätzung landwirtschaftlicher Flächen

Es gab im WMS schon eine Gruppe "Bodenschätzung". Darin befanden sich bisher Ebenen zu "Grabloch" und "Musterstück". Das braucht bei uns (Nutzung durch Städte und Gemeinden) eigentlich niemand. Die eigentlichen Klassenflächen fehlten jedoch bisher.

Ich habe nun die "Klassenflächen" (Fläche) und "Schätzungsergebnisse" (Text) als Ebenen eingefügt. Statt dessen habe ich "Grabloch" und "Muster" verschwinden lassen.
Auf den Flächen ist eine Feature-Info möglich. Das Template erklärt dann z.B. was die Kartenanzeige "Sl3LöD 38/40" bedeutet:
 - Farbe Rot = Kulturart "Ackerland"
 - Sl = Bodenart "Anlehmiger Sand"
 - 3 = Zustandsstufe
 - LöD = Enststehungsart "Löß über Dilluvium"
 - 38 = Bodenzahl
 - 40 = Ackerzahl

Dies Template zur Schätzung ist noch nicht - wie das auf Flurstück oder Baulast - an die Buchauskunft angebunden.

Damit die Schätzung dargestellt und entschlüsselt werden kann, habe ich die Schlüssel, Kurzbezeichnungen und Bezeichnungen aus der GeoInfoDok abgetippt: 
http://trac.wheregroup.com/PostNAS/browser/trunk/import/alkis_PostNAS_keytables.sql 
Die Spalte "kurz" dient der Darstellung in der Karte und die Spalte "bezeichner" dient der Anzeige in der Feature-Info

Damit die Flurstücksgrenzen nicht von den Klassenflächengrenzen überdeckt werden, habe ich die Schätzungs-Layer im Mapfile nach oben gerückt.
Für die Nutzer vom Mapbender bedeutet das, dass die Layer nach dem Update eines bestehenden alten WMS im Client neu sortiert werden müssen.
Am schnellsten geht das mit einem SQL-Statement, siehe im Kommentar-Kopf des Mapfiles und http://trac.osgeo.org/mapbender/ticket/891 .

- Texte

Einige Texte aus "ap_pto" wurden bisher schon innerhalb der fachlich passenden Layer-Gruppe dargestellt (Flurstücksnummern, Hausnummern). Der Rest bisher pauschal unter "Präsentation".
Dort habe ich nun einen neuen Layer "Straßen" gebildet, die die Bezeichnung von Straßen, Wegen und Plätzen sowie die Klassifikation von Bundes- und Landstraßen umfasst.
Durch die Bildung dieser fachbezogenen Layer und Klassen hat man die Möglichkeit, diesen Labels individuelle Schriftgrößen zuzuordnen und sie nach Bedarf ein- und auszuschalten. In der Praxis finden sich noch Namen von Plätzen, die als art="FreierText" definiert sind.
Außerdem gibt es in den ALKIS-Daten noch Felder die die horizontale und vertikale Ausrichtung des Labels zu der gegebenen Position beschreiben. Diese werden nun auch berücksichtigt. Es wäre ja auch zu einfach gewesen, einfach nur die Koordinate der Label-Position mitzugeben. Das wäre nicht kompliziert genug gewesen für ALKIS  ;-).

Bei der Bildung der SQL-Views, die die Daten für die Darstellung liefern, wurde noch ein anderes Problem gelöst: Zunehmend werden Texte bei Fortführungen manuell positioniert und dabei werden teilweise auch verschiedene Positionen für verschiedene Maßstäbe gesetzt. Bisher wurden im WMS pauschal alle Texte - bei verschiedenen Positionen also redundant - angezeigt. Die neuen Views bevorzugen die Position für 1:1000 wenn mehrere zu einem Objekt gesetzt sind. Nur wenn noch keine maßstabsbezogenen Textpositionen gesetzt sind, wird die Label-Position ohne Angabe verwendet.
Die Views dazu sind leider etwas kompliziert (mit Subquery prüfen, ob es zu einem Objekt eine maßstabsabhängige Position gibt). Für die Beschleunigung wäre es auf Dauer wohl nützlich, das Ergebnis des View im Rahmen des PostProcessing in einer Hilfstabelle fertig abzulegen.
Beispiel: siehe View "ap_pto_stra" in http://trac.wheregroup.com/PostNAS/browser/trunk/import/sichten_wms.sql 

Die Änderungen am Schema, den Schlüsseltabellen und den Views werden erst wirksam, wenn man eine PostNAS-Datenbank neu anlegt und lädt.
Um eine bestehende, geladene Datenbank zu aktualisieren, soll das neue Patch-File http://trac.wheregroup.com/PostNAS/browser/trunk/import/alkis_Patch.sql dienen. Dort habe ich die letzten Änderungen nochmals zusammen gefasst. Dies funktioniert, wenn die Datenbank nicht zu alt ist und z.B. Felder bereits als Array[] definiert sind, die früher nur "einfach" waren.

Die beschriebenen Änderungen am WMS stecken in der Entwickler-Version des Mapfiles: http://trac.wheregroup.com/PostNAS/browser/trunk/umn/alkis/alkis_muster_entw.map  

** Navigation

Das Mapbender-Plugin für Suche und Positionierung nach Flurstück, Grundbuch, Adresse oder Eigentümer in ALKIS habe ich auch überarbeitet.
Äußerlich sichtbar: 
- Eine "zurück"-Schaltfläche
- Eine Zeile oben, die erklärt, was der letzte Klick gemacht hat
- Eine Zeile unten, die das Ergebnis anzeigt (Anzahl gefundener Fälle)

Das Modul zum Suchen nach Eigentümer-Namen hat eine "Blätter"-Funktion. Wenn zu einer Suche z.B. zum Eigentümer "Stadt" das im SQL angegebene Limit nicht ausreicht, dann wird am Ende "weiter" angezeigt und man kann die Liste fortsetzen.

Für das Problem der Such-Sackgassen habe ich noch keine abschließende Lösung. Man kann sich z.B. zunächst für einen Grundbuch-Bezirk entscheiden und dann für ein Grundbuch-Blatt um dann festzustellen, dass keins der darauf gebuchten Flurstücke in den Bereich fällt, der laut Filter erlaubt ist.
Dieser Filter erlaubt eine (Nutzerprofil "Stadt") oder mehrere (Nutzerprofil "Verband") Gemeinden aus einer Datenbank anzuzeigen, die einen ganzen Kreis enthält. 

Das Programm müsste also beim Auflisten der Bezirke schon prüfen, ob mindestens ein Flurstück auf einem Blatt in diesem Bezirk gebucht ist. Das sind eine Menge JOINs: 
 - Variante 1: Bezirk > Blatt > Buchung > Flurstück > Gemarkung > Gemeinde
 - Variante 2: Bezirk > Blatt > Buchung >(Recht an)> Buchung >  Flurstück > Gemarkung > Gemeinde
Wobei die meisten JOINs noch die Tabelle "alkis_beziehungen" dazwischen geschaltet haben (hier weg gelassen).

Das macht die Anwendung zu langsam.

Versuch:
Wenn man schon bei der Suche "Blatt" bis Flurstück JOINen muss, um den Filter zu prüfen, dann kann man die Daten dazu ja auch gleich ausgeben.
Das weicht dann allerdings von der Regel ab, sich "Stufe für Stufe" in die Tiefe zu klicken. Wenn der Gemeinde-Filter gesetzt ist, dann werden in "Grundbuch" und "Eigentümer" nun gleich die 3 Stufen "Blatt - Buchung - Flurstück" auf einmal ausgegeben und diese gleich auf erlaubte Flurstücke(Gemeinde) gefiltert. Dies ist kombiniert mit einer Blätter-Funktion. Die Bedienung wird etwas verwirrender, wenn an der Stelle gleich eine 3stufige Ausgabe kommt.

Wenn kein Filter gesetzt ist (Nutzerprofil "Kreis"), dann arbeitet das Programm wie bisher Stufe für Stufe, weil "Sackgassen" dann unwahrscheinlicher sind.

Wenn jemand bessere Ideen hat, raus damit ...
Wahrscheinlich liegt die Lösung auch hier bei Hilfstabellen, die nach dem Laden der Datenbank aufbereitet werden und z.B. zeigen welche GB-Blätter Flurstücke aus welchen Gemeinden enthalten (über beide Varianten geladen).

Ein erster Blick auf die Änderungen: http://map.krz.de/alkis/mapbender.php (Musterbestand RLP).

Mit freundlichen Grüßen
Frank Jäger

Kommunales Rechenzentrum
Minden-Ravensberg/Lippe