[PostNAS] verlorene Straßen

[Jäger, Frank (KRZ)]

Hallo Freunde des PostNAS-Konverters,
 am Montag haben wir uns hier in Lemgo im kleineren Kreis getroffen und über PostNAS und die darauf aufbauenden Anwendungen (Auskunft) im Mapbender- und QGIS-Umfeld geredet. Darüber wird hier gelegentlich noch berichtet werden.

Mit einem der am Montag diskutierten Probleme habe ich mich gleich beschäftigt und habe eine Lösung entworfen, die - bei mir - ca. 90 bis 99% der Fälle löst, aber leider noch nicht alles.

Es geht darum, dass der Kartendienst (WMS) einige Straßennamen nicht mehr darstellt. Stark betroffen davon ist Niedersachsen, Andreas Borgardt (Cuxhaven) hatte davon berichtet.
In NRW war mir das noch nicht "aufgefallen", ich habe aber inzwischen festgestellt, dass wir hier auch in steigendem Maße davon betroffen sind.

Die Straßennamen werden vom WMS in der Tabelle der Präsentationsobjekte "ap_pto" erwartet, wo es u.a. die Felder schriftinhalt, drehwinkel und ein Geometriefeld (Punkt) gibt. Schriftinhalt enthielt nach der Migration aus ALB und ALK zunächst (auch) den Straßennamen, der eigentlich in der Tabelle "ax_lagebezeichnungkatalogeintrag" in der Spalte "bezeichnung" eindeutig verwaltet wird.

Die Redundanz in den Präsentationsobjekten (ap_pto) führt - wie alle Redundanzen - zu erhöhtem Aufwand bei der Fortführung.
Daher soll "ap_pto.schriftinhalt" (für die Anzeige) im primären ALKIS-Bestand nur noch dann einen Inhalt bekommen, wenn dieser von "ax_lagebezeichnungkatalogeintrag.bezeichnung" abweicht (z.B. Abkürzung, Getrennt-Schreibung, ..).
Offensichtlich sind die Daten von Niedersachsen im Rahmen der Nachmigration an dieser Stelle schon gezielt "redundanzfrei" gemacht worden.
Bei der aktuellen Version des WMS (Mapfile) führt das leider dazu, dass sie aus dem Kartenbild verschwinden.
In NRW wird seit kurzem (mit der aktuellen Version der EQK) diese Redundanz beseitigt. Betroffen sind daher die Flurstücke, die in letzter Zeit fortgeführt wurden.

In den beiliegenden SQL-Dateien werden Views definiert, die diese Fälle suchen und anzeigen. Ein View zeigt auch, was die Reparatur machen wird.

Der Kartendienst müsste also zunächst in "ap_pto" nachsehen, ob es ein darzustellende Variante gibt. Wenn der "schriftinhalt" dort leer ist, dann soll "bezeichnung" aus "ax_lagebezeichnungkatalogeintrag" als Label in die Karte gerendert werden.
Position und Drehwinkel des Textes stehen aber nach wie vor in "ap_pto" zusammen mit dem nun leeren Textfeld. 


Lösungsansatz:

Um dem WMS bzw. seinem View die Sucherei zu ersparen (zu langsam) soll im Rahmen des Prost-Processing (nach jeder Konvertierung) im Sekundärbestand wieder eine Kopie (Redundanz) an der bisher üblichen Stelle abgelegt werden, die schnell angezeigt werden kann.

Das Problem besteht darin, die passenden Zeilen von PTO und Lage-Katalog zusammen zu bringen. Die Präsentationsobjekte haben keine Beziehungen zu anderen Objekten, was die Sache schwierig macht. Die aktuelle Lösung arbeitet daher mit einer geometrischen Verschneidung.

- Position des PTO (Punkt-Geometrie) verschneiden mit Flurstück (Punkt liegt in Fläche)
- Das Flurstück findet über die alkis_beziehung "zeigtAuf" die "ax_LagebezeichnungOhneHausNummer".
- "ax_ LagebezeichnungOhneHausNummer " verweist dann auf "ax_LageBezeichnungKatalogEintrag", dort findet man den gesuchten Label.
- Den Kopiert man dann zum PTO von dem man ausgegangen ist.

Randbedingung ist also, dass die Textposition im Flurstück liegt. Wird bei schmalen Wegen der Text parallel durch ein Nachbarflurstück gelegt, funktioniert das so nicht.

Ein weiteres Problem bereiten Flurstücke, die mehrere "LagebezeichnungOhneHausNummer" haben. Je Gemeinde habe ich 1 oder 2 davon gefunden.
Hier ist unklar, welcher Text zu welcher Position gehört, daher bleiben diese Fälle von der "Reparatur" zunächst ausgenommen.

Kennt jemand einen Weg, eine Lagebezeichnung eindeutig einem Präsentationsobjekt zuzuweisen?

Ein typisches Problem bei Redundanzen: Wie erkennt man, wenn der Text im "LageBezeichnungKatalogEintrag" geändert wird, ob in "ap_pto" eine Kopie des alten Wertes lag, die nun auch anzupassen ist, oder ob das eine gewollte Darstellungs-Variante ist. Bisher repariert das Script nur leere (IS NULL) Felder. Möglicherweise sollte man bei einer späteren Lösung das vom Konverter gefüllte Feld "ap_pto.schriftinhalt" unberührt lassen und stattdessen im Post-Processing eine eigene  - für die Präsentation von Straßennamen optimierte - Tabelle daraus extrahieren.

Weitere Erklärungen findet man in den Kommentaren der SQL-Dateien. 
Diese lege ich zunächst als Anlage der Mail bei. Ich plane diese in die Quellcodeverwaltung von PostNAS hochzuladen, sobald mein frisch aktualisierter SVN-Client wieder korrekt arbeitet.

Bitte Erfahrungsberichte und Testergebnisse hier melden und diskutieren.


Mit freundlichen Grüßen
Frank Jäger

Kommunales Rechenzentrum
Minden-Ravensberg/Lippe
Tel.: 05261 / 252 - 185
Fax: 05261 / 932 - 185

mailto:f.jaeger at krz.de
http://www.krz.de/

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : pp_praesentation_sichten.sql
Dateityp    : application/octet-stream
Dateigröße  : 11492 bytes
Beschreibung: pp_praesentation_sichten.sql
URL         : <http://lists.osgeo.org/pipermail/nas/attachments/20131016/12ba82a7/attachment-0002.obj>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : pp_praesentation_action.sql
Dateityp    : application/octet-stream
Dateigröße  : 5102 bytes
Beschreibung: pp_praesentation_action.sql
URL         : <http://lists.osgeo.org/pipermail/nas/attachments/20131016/12ba82a7/attachment-0003.obj>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 7618 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.osgeo.org/pipermail/nas/attachments/20131016/12ba82a7/attachment-0001.bin>