[PostNAS Suite] Nutzungsarten-Postprocessing

Di Mär 1 07:04:07 PST 2016

Hallo Herr Jäger,

ich war unterwegs, deswegen antworte ich erst jetzt:

> ...
>> 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.
Ja, wir haben in kvwmap ja auch bis vor kurzem das Nutzungsarten-PP der 
klassischen PostNAS-Variante verwendet. Dann kam aber der Wunsch nach 
Konformität zum Nutzungsartenkatalog auf. Es sollten also die richtigen 
Schlüssel und Bezeichnungen der Nutzungsarten angezeigt werden. Wir 
haben das Ganze dann einfach angepasst.
Es steht zwar der Zusatz "MV" in den Kommentaren aber es sind trotzdem 
alle Schlüssel und Bezeichnungen in den Schlüsseltabellen enthalten, so 
dass diese Tabellen auch für alle anderen Bundesländer funktionieren 
sollten.
Dass diese Metadaten in der NorGIS-Struktur schon enthalten aber anders 
strukturiert sind, kann gut sein. Wir verwenden die NorGIS-Tabellen 
überhaupt nicht, sondern holen alles aus den über ogr2ogr eingelesen 
ax_-Tabellen.

>> 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()".
Sorry, die Funktion hat noch einen Parameter. Suchen Sie einfach nur mal 
nach "getnutzung", dann sollten Sie sie finden.

>
> 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
Ja, wir hatten auch schon überlegt, unser jetziges Nutzungsarten-PP so 
zu erweitern, dass beim PP schon mit den Flurstücken verschnitten wird 
und so Nutzungsartenteilflächen entstehen, die dann über die "gml_id", 
"beginnt" und "endet" mit dem Flurstück verknüpft sind.
Im Prinzip wollen wir also das Gleiche. So eine gemeinsame, zentrale 
Nutzungstabelle ist ja auch von Vorteil, da Änderungen am 
Nutzungsartenkatalog dann nur einmal an dieser Stelle eingepflegt werden 
müssen.

Aber: Diese gemeinsame Tabelle wäre für uns (die kvwmap-Nutzer) nur dann 
verwendbar, wenn sie unabhängig von dem NorGIS-ALKIS-Importer und den 
anderen NorGIS-Tabellen ist.
Wie schon gesagt, verwenden wir die NorGIS-ALKIS-Struktur nicht und die 
gesamten NorGIS-Tabellen nur wegen der Nutzungsarten-Tabelle 
"mitzuschleppen" wäre unschön.
Außerdem dauert das NorGIS-PP, wie Sie ja auch schon erwähnten, momentan 
sehr lange. (Wir haben z.B. auch Nutzer, die den kompletten 
ALKIS-Bestand von ganz MV in ihrem PostNAS-Schema haben...)

Gruß,
Stefan Rahn

GDI-Service
Joachim-Jungius-Str. 9
18059 Rostock
Tel: 0381 40344445
E-Mail: stefan.rahn at gdi-service.de
www.gdi-service.de