[PostNAS Suite] Fwd: Umstellung der Mapdatei (Mapserver 7) für NorGIS ALKIS

[Jäger, Frank (KRZ)]

Hallo,
ich finde, diese Loesung (siehe unten) bringt uns nicht viel weiter. 

> FAZIT:
> Die Mapdatei orientiert sich an dem bisherigen Stand

Das ist noch genau die Darstellung die wir vorher im "klassischen" Zweig hatten, weil eigentlich nur die alte Mapdatei umbenannt wurde. Von der QGIS-Darstellung mit SVG-Symbolen, für die die norGIS-Importer-Datenbank-Struktur optimiert wurde, ist nichts zu sehen.

Auch die Nachverarbeitung nach dem Konvertieren (Post-Processing) wurde einfach nur von mehreren Dateien ein eine Datei zusammen gefasst. Das ist aus 2 Gruenden nicht so gluecklich:

1. Es wurde bisher unterschieden zwischen SQL-Scripten, die in einer neuen Datenbank einmalig auszufuehren sind (Anlegen von Tabellen) und solchen, die nach einer Konvertierung laufen müssen (Aufbereiten von Praesentations-Daten). Wenn man die Definitionen nun auch nach jeder Konvertierung laufen laesst, dann macht das die eigenen Erweiterungen kaputt, z.B. zusaetzliche Berechtigungen für QGIS-Arbeitsplaetze oder abhaengige Views.

2. Es wird ja schon im ALKIS-Importer ein Post-Processing durchgefuehrt, das zielt auf die QGIS-Karte und die QGIS-Anwendungen wie ALB-Eignerauskunft.
Wenn man nun das "klassische" PP hier auch noch (redundant) laufen laesst, dann bekommen die Verwaltungen mit großen Bestaenden Probleme. Die bekommen das jetzt schon kaum in einer Nacht durch.

Ziel sollte es doch sein, für QGIS und Mapserver-WMS die gleiche Darstellung zu haben und die gleiche Datenbank mit Views und Prost-Processing zu nutzen. Also moeglichst wenig doppelte Verarbeitungen oder Redundanzen für verschiedene Anwendungs-Varianten zu erzeugen.

Dies Ziel ist durch den Mapfile-Export des QGIS-Plugin bereits zu ca. 80% geloest. Dabei kommt ein Mapfile heraus, dass zu der vorhandenen ALKIS-Importer-Datenbankstruktur optimal passt und eine QGIS-analoge Darstellung generiert, also fast "amtlich".

Die letzten 20% an Arbeiten vor dem produktiven Einsatz bestehen dann aus Anpassungen an URL, SRS, Pfaden, Metadaten, Templates usw.
Da die Layer/Classes mandantenspezifisch generiert werden, sind diese Arbeiten aber ggf. nach jedem neuen Import erneut faellig. Bei der Groesse und Komplexitaet des Mapfiles und wenn man - wie ich - ein Dutzend Mandanten zu versorgen hat, kann das auf Dauer auch noch viel Arbeit sein.


Daher mal folgender alternativer Loesungs-Ansatz zur Diskussion:

Ich habe von Mandanten aus 3 verschiedenen Kreisen (Katasteraemtern) Mapfiles generieren lassen und die Ergebnisse zu einem "Muster-Mapfile" zusammen gefasst.
Je Mandant koennen also auch einzelne Layer oder Classes enthalten sein, zu denen es keine Daten gibt. Die Mapfiles waren leicht unterschiedlich, obwohl es sich um benachbarte Kreise aus der gleichen Region handelt.
Beispiel: Die laufende Nummer von Nebengebäuden in Klammern wird nur von manchen Kreisen geführt. 

Ich kann nun durch einfache Massen-Edits aus dem Muster ein produktives Mapfile erzeugen. Ab und zu muss das Muster mal ueberprueft und ggf. erweitert werden insbesondere, bevor es in anderen Regionen oder Bundeslaendern eingesetzt wird. Vielleicht brauchen wir auf Dauer auch bundesland-spezifische Muster.

Folgende Anpassungen habe ich durchgefuehrt:

- Im Mapfile enthaltene Symbole in eine Datei ausgelagert. Die wird spaeter nur einmal benoetigt, nicht je Mandant wie das Mapfile.

- Template mit Header und Footer zur Anbindung der Buchauskunft ausgehend von Flurstueck.

- Verschlankung durch entfernen unnoetiger Zeilen ("OFFSET 0 0", "MINSCALEDENOM 0", "STYLE END"). 

- Die Layer-Namen werden beim Export durchnummeriert. Wenn spaeter ein Layer dazu kommt, aendern sich alle nachfolgenden Namen. Die Konfiguration im Client (Mapbender) oder im MapProxy ist dann jedes Mal hinfaellig und muss neu gemacht werden. Ich habe die Layer-Namen durch ein anderes Namens-System ersetzt um das konstant zu halten.
So koennen z.B. auch die MapProxy-Projekte je Mandant aus einem Muster erzeugt werden.

Das Muster-Mapfile mit Zubehör habe ich hochgeladen: http://trac.wheregroup.com/PostNAS/changeset/367/trunk 
Mapfile:  http://trac.wheregroup.com/PostNAS/browser/trunk/umn/alkis_n 
Die SVG-Symbole müssen noch vom ALKIS-Plugin zum WMS-Server kopiert werden, es macht keinen Sinn, dass ich die hier noch mal hoch lade.


Es gibt noch einige PROBLEME mit diesem Muster, in den Kommentaren weise ich darauf hin:

- Die Gruppierung erfolgt nach Nutzungsarten. Dabei kann es vorkommen, dass eine Fläche aus einer Nutzungsart die Symbole einer vorhergehenden Gruppe überdeckt.

- Längliche SVG-Symbole werden beim Drehen beschnitten. Beispiel Fließrichtungspfeil, der nicht waagerecht verläuft.
  Das ist ein Fehler im Mapserver: https://github.com/mapserver/mapserver/pull/5264 

- Die Legende sieht monströs aus. Die Symbole sind riesig. Nicht lesbar.

- Eine Class erzeugt "Internal Server Error", Ursache unbekannt. Auskommentiert.

- Neben den Hausnummern tauchen im gleichen Layer in Gebäuden nun Buchstaben auf (oF,  III).


Der QGIS-Mapfile-Export zielt nur auf die amtliche Karte. Einige Zusatz-Layer der klassischen Version sind derzeit noch nicht im Muster enthalten:

- Flur-Uebersicht
- Feature-Info auf Baulasten, Flurbereinigung usw.
- Schätzungsergebnisse (sandiger Lehm usw.)
- Ein Copyright-Layer muss noch ergänzt werden. Die Katasteraemter schreiben vertraglich vor, dass die Datenquelle benannt werden muss. 


Durch den Verzicht auf die Flurübersicht, sind nur kleine Datenbank-Ergänzungen notwendig.
Ein Script für den Ordner  \apps\alkis-import\postprocessing.d\  des ALKIS-Importers liegt hier:
http://trac.wheregroup.com/PostNAS/browser/trunk/import/norgis_alkis_pp/x_classic2norgis.sql 
Das "x" am Anfang des Namens sorgt dafür, dass dieses Script *nach* den anderen ausgeführt wird (alphabetische Reihenfolge).

Im MapProxy habe ich das Ganze in 2 Layer gecached, die anders gruppieren, als es im Mapfile mit "wms_layer_group" gemacht wird.
Ich habe einen Flächen-Layer gebildet und alle restlichen Layer zu einem Cache-Layer zusammen gefasst. Bei Ausschalten der Fläche eignet sich die Karte dann für die Ueberlagerung anderer WMS.

MfG
Frank Jäger

krz Mi.-Ra./Li.



> -----Ursprüngliche Nachricht-----
> Von: NAS [mailto:nas-bounces at lists.osgeo.org] Im Auftrag von Thekla Wirkus
> (WhereGroup)
> Gesendet: Dienstag, 19. April 2016 14:21
> An: PostNAS Suite - ALKIS, ATKIS, ABK - NAS Schnittstelle via ogr2ogr
> Betreff: [PostNAS Suite] Fwd: Umstellung der Mapdatei (Mapserver 7) für
> NorGIS ALKIS
> 
> 
> Hallo zusammen,
> 
> wir haben die bisherige Mapdatei umgestellt. Ziel war es, die bisherige
> Mapdatei (/trunk/umn/alkis/alkis_muster.map) mit NorGIS ALKIS in Mapserver
> 7 zu verwenden.
> 
> Die neue Mapdatei liegt im SVN-Verzeichnis /trunk/umn/alkis/alkis_norgis.map
> 
> Um diese Mapdatei (/trunk/umn/alkis/alkis_norgis.map) verwenden zu können,
> müssen die ALKIS-Daten mit dem NorGIS ALKIS Import-Tool importiert werden
> (siehe:
> http://trac.wheregroup.com/PostNAS/wiki/Komponenten)
> 
> Für die Darstellung einiger Layer sind PostProcessing-Dateien notwendig. Sie
> stammen aus den PostNAS-Postprocessing-SQL-Dateien:
> - nutzungsart_definition.sql
> - nutzungsart_metadaten.sql
> - nutzungsart_laden.sql
> - postnas_keytables
> - sichten_wms.sql
> - pp_definition.sql
> - pp_gebiet.sql
> - pp_laden.sql
> 
> Diese Dateien werden zusammengefasst zu einer PostProcessing-Datei. Sie
> befindet sich unter:
> /trunk/import/norgis_alkis_pp/postprocessing_mapdatei_demo.sql
> 
> Die Postprocessing-Datei (postprocessing_mapdatei_demo.sql) kann in das
> NorGIS ALKIS Verzeichnis (/alkisimport-master/postprocessing.d/) gelegt
> werden. Sie wird dann beim Importieren der Daten berücksichtigt.
> 
> Durch dieses PostProcessing können Layer aus den Gruppen Nutzung, Gebiete,
> Gebäude, Bodenschätzung, Flurstück, Präsentation, Grenzen dargestellt
> werden.
...
> FAZIT:
> Die Mapdatei orientiert sich an dem bisherigen Stand
> ...
> 
> Mit freundlichen Grüßen
> Thekla Wirkus
-------------- 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/20160509/f8275383/attachment.bin>