[PostNAS Suite] Nutzungsarten-Postprocessing

[Jäger, Frank (KRZ)]

Hallo,
ich versuche mich mal an einer Analyse des "ProstProcessing der Nutzungsarten in NorGIS, PostNAS-Classic und KVWMAP".


> -----Ursprüngliche Nachricht-----
> Von: NAS [mailto:nas-bounces at lists.osgeo.org] Im Auftrag von Stefan Rahn
> Gesendet: Mittwoch, 24. Februar 2016 20:17
> An: nas at lists.osgeo.org
> Betreff: Re: [PostNAS Suite] Nutzungsarten-Postprocessing

...
> Aus Performance-Gründen sammeln wir auch die Nutzungsarten aus den 27
> einzelnen "ax_"-Tabellen in einer Tabelle "n_nutzung" zusammen.
> Das Besondere daran ist, dass mit dieser Tabelle und ein paar zusätzlichen
> Schlüsseltabellen der Nutzungsartenkatalog komplett abgebildet wird. Man
> erhält damit die korrekten Nutzungsartenschlüssel sowie die Bezeichnungen
> der Nutzungsarten nach Nutzungsartenkatalog.
> 
> Die PP-Tabellen-Definitionen sind hier zu finden:
> http://www.kvwmap.de/alkis/nutzungsart_definition.sql
> Und das PP-Skript hier: http://www.kvwmap.de/alkis/nutzungsart_laden.sql


Das kommt mir streckenweise sehr bekannt vor ;-)
Das basiert auf der Lösung aus der "Klassischen" Variante, die ich selbst mal vor ca. 4 Jahren entwickelt habe:
 http://trac.wheregroup.com/PostNAS/browser/trunk/import/nutzungsart_definition.sql 
 http://trac.wheregroup.com/PostNAS/browser/trunk/import/nutzungsart_laden.sql 
Das ist wohl für KVWMAP noch etwas angepasst/verfeinert worden.

Die Tabelle "n_nutzungsartenschluessel" wird hier mit Texten aus dem Script gefüllt. Der Zusatz "MV" in den Comments deutet darauf hin, dass das länderspezifisch gepflegt werden muss? Diese Metadaten sind aber - anders als in der alten Version - in der norGIS-ALKIS-Struktur nun teilweise schon vorhanden, nur leider ganz anders strukturiert.


> Wie man die Tabellen verknüpft und die Nutzungsarten abfragt, sieht man in
> der Datei https://github.com/srahn/kvwmap/blob/develop/class/postgresql.php
> in der Funktion getNutzung().

Das ist auf einer "höhen Ebene" programmiert, das verstehe ich nicht.  Ich finde da keine PHP-Funktion "getNutzung()".


> Gruß aus dem Norden,
> Stefan Rahn


Ich versuche mal eine anzustebende "Einheitliche Lösung" zu skizzieren:


*1. Zentrale Nutzungsarten-Tabelle*

Das Gegenstück zu den zusammengefassten Nutzungsflächen in der "norBIT-ALKIS_Import"-Struktur ist die Tabelle "nutz_21" in Verbindung mit "nutz_shl".
Auch dort sind alle Nutzungsartenflächen der diversen Tabellen bereits zusammengefasst. Es wäre somit gewissermaßen "doppelte Arbeit" das noch mal zu machen.

Aber nicht nur die Auskunft - wo der Anwender nach dem Klick auf das Ergebnis wartet - sondern auch das das Post-Processing sollte möglichst schnell und effektiv laufen. Auf dem letzten Treffen wurde berichtet, dass das teilweise sehr lange läuft. Wenn z.B. jede Nacht ein ganzes Kreisgebiet per NBA aktualisiert wird, dann sind die Datenmengen aus dem NBA zwar nur gering, aber das Prostprocessing verwirft nach der Konvertierung seine Ergebnisse und baut die Tabellen komplett neu auf. Das ganze Kreisgebiet muss also auch bei nur wenigen Änderungen komplett verarbeitet werden. Daher sollten Doppelarbeiten dabei vermieden werden. Wir brauchen möglichst eine einheitliche Lösung mit der QGIS- und WebGIS-Anwendungen (WMS, Mapserver) aus der *gleichen* Datenbank-Struktur lesen können.

Die Nutzungsarten sind in "nutz_21" nicht nur zusammen gefasst sondern sogar schon mit den Flurstücken geometrisch verschnitten, so dass man das zum Zeitpunkt der Auskunft nicht mehr machen muss. 
Diese Tabelle zielt aber derzeit sehr eng auf die Bedürfnisse der QGIS-Eigner-Auskunft mit ALB-ähnlichen Strukturen.
Die Abschnitte haben somit die ALKIS-Systematik verloren (Gruppierung, Zusatzfelder), sie sind auch nicht über die "gml_id" des Flurstücks zu filtern (Standard-Feld für Relationen und Verknüpfungen), sondern nur nach dem ALB-Format des Flurstückskennzeichens (mit Trennzeichen) und sie haben keine Geometrie, wodurch sie nicht für Kartendarstellung oder WFS-Suche verwendet werden können.

Es gibt also bisher folgende 2 Ansätze beim Post-Processing der Nutzungsarten:
   (a.) Die Flächen aus 27 Tabellen zu einer Tabelle zusammen fassen (Classic, KVWMAP)
   (b.) Verschneidung der Flurstücks-Geometrie mit den Geometrien der 27 Nutzungsartentabellen (QGIS, Eignerauskunft)

Aus (a.) kommen die "größeren Stücke" heraus: Der Vorteil der Zusammenfassung ist, dass sie sind dann "zentral" (mit nur einer SQL-Abfrage, über einen geom. Index) verschneidbar sind. Es sind aber eigentlich nur Kopien und die Verschneidung muss noch in der Auskunft gemacht werden.

Bei (b.) sind die Nutzungsflächen schon mit den Flurstücken verschnitten und somit in mehrere kleinere Abschnitte zerteilt. Dadurch erhält man die Größe der Teilflächen.
Es ist nicht nur eine Daten-Kopie sondern durch die Geometrie-Funktionen steckt da schon etwas mehr Information drin.

Um dies für allgemeine Nutzung in ALKIS-Programmen (Buchauskunft, KVWMAP) zusammen zu führen könnte die ALB-lastige Tabelle "nutz_21" erweitert werden um:
 (1.) "gml_id" aus dem verschnittenen "ax_flurstueck". Damit könnte man sie in der Auskunft einfacher verwenden, man müsste nicht erst das ALB-Flurstücksformat ermitteln und formatieren sondern könnte direkt die "gml_id" verwenden.
 (2.) Den Tabellen-Namen der Nutzungsarten-Tabelle aus der das verschnitten wurde und die "gml_id" des Abschnitts daraus.

Somit würden im Post-Processing nicht alle Daten der 27 Nutzungsarten einfach nur kopiert (Rendundanz!). Durch Tabellen-Name und ID könnte man sich benötigte Zusatzfelder dann gezielt aus der Ursprungs-Tabelle holen. Die meisten Flurstücke haben ja nur 1 oder 2 Nutzungen. Auf diese wenigen Tabellen würde man dann für die Auskunft gezielt zugreifen können. Man müsste nicht 27 verschieden Tabellen auf Verdacht verschneiden, da das schon vorbereitet wurde.

Die zentrale Nutzungsarten-Verschneidungstabelle würde somit mehr solche Daten enthalten, die noch nicht in anderen Tabellen vorkommen:
 - Relation Flurstück - Nutzung
 - Größe der Schnittfläche
Aber sie würde nicht einfach nur mit Kopien der Zusatzfelder aufgefüllt. 


*2. Metadaten und Struktur der Nutzungsarten*

Der Charme der NorBIT-Lösung besteht darin, dass die GeoInfoDok (halb-)automatisch importiert worden ist und somit alle Schlüssel und Texte schon in irgendwelchen Tabellen stecken. Wenn man das nutzt, dann erspart man sich die spätere Pflege der (redundanten) Wertetabellen in den SQL-Skripten.

Gruppierung der Nutzungsarten, anzuzeigende Bezeichnungen zu den Nutzungsartenschlüsseln und "welche Zusatzfelder gibt es zu welcher Tabelle" sollten soweit wie möglich aus Tabellen wie "alkis_wertearten" und "alkis_elemente" abgeleitet werden, statt das aus manuell editierten SQL-Scripten noch mal zu laden.

Beispiel:
 
In "nutzungsarten_definition.sql" wird ein Text hinterlegt mit der Zeile:

  INSERT INTO n_nutzungsart VALUES (12, 1, 'Industrie und Gewerbe');

Der Text 'Industrie und Gewerbe' steckt aber auch schon als "v" (Value) in "alkis_wertearten". Dort ist er allerdings dem "k" (Key) "1700" zugeordnet und nicht "12, 1".
(Auch in "alkis_elemente" ist das unter der Kennung 41002 noch mal zu finden, wobei der Text dort nur ein Substring von "definition" ist.)

Die Texte dann noch mal zu erfassen und zu hinterlegen ist eine Redundanz. Man muss "nur" die Systematik knacken.

Wir sollten also versuchen, die in der Datenbank in "alkis_wertearten" bereits vorhandenen Texte für die einzelnen Anwendungen wie Buchauskunft, Mapbender-Suche und KVWMAP zu nutzen.
Ob sich aus den vorhandenen Metadaten die "Systematik" (Gruppierung, Zusatzfelder) ausreichend für die Programmfunktionen generieren lässt, kann ich noch nicht abschätzen. Wenn nicht, sollten aber nur diese Zusatzinformationen zur gewünschten Gruppierung manuell nachdefiniert werden, keine Texte zu Schlüsseln.


*Fazit:*

Die klassischen Nutzungsarten-PPs sind entstanden zu einer Zeit, als die Datenbank noch keine Metatabellen aus der GeoInfoDok enthielt. Aus heutiger Sicht liefern sie redundante Daten.

Das Nutzungsarten-PP der NorGIS-Lösung zielt sehr auf die ALB-ähnliche Struktur der Eigner-Auskunft. Für die Verwendung in anderen ALKIS-Auskunft-Lösungen müssten ein paar Spalten ergänzt werden.

Die wünschenswerte gemeinsame zentrale Nutzungs-Tabelle wäre dann sowohl für ALB-artige Auskünfte (Flurstücks-Abschnitte) als auch für volle ALKIS-Struktur (Link auf "gml_id" der Primärtabellen) brauchbar.

Es sollte vermieden werden, für verschiedene Anwendungsfälle, ähnliche Optimierungen mehrfach zu prozessieren.

MfG
F. Jäger


-------------- 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/20160225/a2f6bb2c/attachment-0001.bin>