Re: [NAS] tatsächliche Nutzung

Die Nov 9 03:43:04 EST 2010

Hallo Herr Jäger,

Sie können den GIS Layer über eine Datenbanksicht erstellen. Der Verschnitt 
der Datenbanksicht mit dem Flurstückslayer hätte ein Ergebnis, was der alten 
Struktur nahe kommt.

CREATE OR REPLACE VIEW nutzflaechen
AS
  SELECT gml_id, artderbebauung AS klassifizierung, 'wohnbauflaeche' AS 
nutzungsart, wkb_geometry
  FROM ax_wohnbauflaeche
  UNION ALL
  SELECT gml_id, abbaugut AS klassifizierung, 'tagebaugrubesteinbruch' AS 
nutzungsart, wkb_geometry
  FROM ax_tagebaugrubesteinbruch
  UNION ALL
...
;

MfG
Ralf Suhr

Am Montag 08 November 2010, 18:21:35 schrieb 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
> _______________________________________________
> NAS mailing list
> NAS at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/nas