[NAS] tatsächliche Nutzung

[Jäger, Frank (KRZ)]

Hallo,
(english below)
in der von mir entwickelten ALKIS-Buchauskunft fehlte bisher zum Flurstück noch die Angabe der "tatsächlichen Nutzung". Der Grund war: mit der Datenstruktur an dieser Stelle bin ich sehr unglücklich.

In der alten "ALB"-Buchauskunft [1] [2] - die ich hierfür ausgeschlachtet habe - war das viel einfacher:
Im ALB war "Nutzung" ein Teil eines Flurstücks. Somit führte der Nutzungs-Abschnitt in der Datenbank einen Verweis auf das Flurstücksobjekt (Foreign Key Constraint).

Im ALKIS sind die Nutzungsabschnitte nun unabhängig von den Flurstücken und müssen durch Verschneidung ermittelt werden. Das ist aber nicht das Problem, sondern eine für ein GIS sehr ungünstige Datenstruktur, die der Konverter PostNAS erzeugt.

Nach meinem Verständnis ist "Nutzung" ein Layer im GIS "ALKIS". Er ist insgesamt flächendeckend.
Jeder Punkt des geladenen Gebietes hat also genau eine Nutzungsart.
Die einzelnen "Arten der Nutzung" sind eigentlich Classes innerhalb dieses Layers.

Für Verneidungen ("Welche Nutzungen hat das Flurstück?")
oder für eine Feature-Info ("Welche Nutzung hat diese Stelle?")
... müsste es möglich sein in EINER Tabelle über EINEN geometrischen Index nachzuschlagen.

Dies ist leider nicht möglich, weil jede "Class" (Art der Nutzung) des Layers "Nutzung" derzeit in einer eigenen Tabelle mit einem eigenen geometrischen Index abgelegt wird.
Um eine der o.a. Fragen zu beantworten, müssen also in der von PostNAS generierten Datenstruktur nacheinander 26 Tabellen(!) geometrisch verschnitten werden.

Bei einer Feature-Info bekommt man dann 25 Fehlschläge und nur einen Treffer.
Da ein Flurstück i.d.R. auch nur aus 1 bis 2 verschiedenen Nutzungen besteht, ist das Verhältnis ähnlich schlecht.  


Wieso ist das so?

PostNAS kann eigentlich nichts dafür. Er arbeitet nach dem ogr-Prinzip: Die Layer und Attribute der Quelldatei werden 1:1 in das Zielformat umgesetzt. Somit kann man ein beliebiges Shapefile in eine Datenbank umwandeln oder umgekeht. Das macht den Konverter sehr flexibel. So wird prinzipiell auch mit NAS verfahren.

Nun haben aber die Väter von ALKIS in das NAS-Format solche Tags eingebaut, die PostNAS glauben lassen, es wären 26 verschiedene Layer, die nichts miteinander zu tun haben. Das ist aber eigentlich falsch.

Dummerweise haben die 26 Tabellen auch noch verschiedene Attribute:
So hat ein "Bergbaubetrieb" ein "Abbaugut" während ein "Wald" ein "Vegetationsmerkmal" hat.
Der "Weg" hat eine "Funktion" und die Halde ein "Lagergut".


Wie kann man PostNAS veranlassen, diese Layer in einer Tabelle zusammen zu fassen?
Gibt es bereits Instrumente um einen Layer "ax_weg" in einen Tabelle "nutzung" zu mappen?


Ich habe ein SQL-Script begonnen (es ist noch unvollständig), das die Zusammenfassung der 26 Tabellen zu einer Tabelle "nutzung" durchführt. 
Über eine Meta-Tabelle merke ich mir, welches Attribut (Funktion, Lagergut, ...) die individuelle Nutzung mitbringt. Ich packe die Attribute in Standard-Felder.
Diese zusammengefasste Tabelle "nutzung" ermöglicht es mir nun, in der Buch-Auskunft [3] eine Auflistung der Nutzungen zum Flurstück anzuzeigen. Dazu ist 1 SQL-Abfrage notwendig und nicht 26.

Eine Umstellung des Mapfiles für den WMS würde wahrscheinlich eine Beschleunigung bringen.

Mit dieser "Krücke" bin ich aber unzufrieden, die Daten sind redundant und müssen nach jeder Fortführung der Original-Tabellen neu geladen werden.

Ob es wohl möglich wäre, den Quellcode von PostNAS so zu ändern, dass ein Mapping von NAS-Tags auf anders lautende Ziel-Tabellen möglich ist? 

Die SQL-Scripte und die dfür angepasste Buchauskunft werde ich in Kürze ins PostNAS-SVN stellen.

[1] http://gis.krz.de/alb/
[2] http://gis.krz.de/alb/daten/alb_auskunft_mapserver.zip
[3] http://map.krz.de/info/alkis/mapbender.php



@ Frank Warmerdam
I try to explain in english:

ALKIS contains a "Layer" for Landuse.
All Polygons of this landuse-Layer ar puzzled to a full coverage without gaps or overlaps.
Unfortunately in NAS the tags of every "class" of this layer have different names.
So PostNAS creates 26 Tables with 26 gist-Indexes.

A feature-info or an intersection for landuse has to query this 26 tables and merge the results.

Is ist possible to map this 26 NAS-Tags into 1 Table?


Source-Tags are:
 ax_wohnbauflaeche;
 ax_industrieundgewerbeflaeche;
 ax_halde;
 ax_bergbaubetrieb;
 ax_tagebaugrubesteinbruch;
 ax_flaechegemischternutzung;
 ax_flaechebesondererfunktionalerpraegung;
 ax_sportfreizeitunderholungsflaeche;
 ax_friedhof;
 ax_strassenverkehr;
 ax_weg;
 ax_platz;
 ax_bahnverkehr;
 ax_flugverkehr;
 ax_schiffsverkehr;
 ax_landwirtschaft;
 ax_wald;
 ax_gehoelz;
 ax_heide;
 ax_moor;
 ax_sumpf;
 ax_unlandvegetationsloseflaeche;
 ax_vegetationsmerkmal
 ax_fliessgewaesser;
 ax_hafenbecken;
 ax_stehendesgewaesser;

Target is "nutzung".

The Tables has some different attributs but most of them integer.
I'm working on a SQL-Script that copies the records into one table, coming soon.


Mit freundlichen Grüßen
Frank Jäger