RE: [NAS] tatsächliche Nutzung

[Jäger, Frank (KRZ)]

> -----Original Message-----
> From: Ralf Suhr [mailto:Ralf.Suhr at itc-halle.de] 
> Sent: Tuesday, November 09, 2010 9:43 AM
> To: Entwicklung einer NAS Schnittstelle
> Cc: Jäger, Frank (KRZ)
> Subject: Re: [NAS] tatsächliche Nutzung
> 
> 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):
...
> > Nach meinem Verständnis ist "Nutzung" ein Layer im GIS 
> "ALKIS".
...
> > 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.


Hallo,
diese UNION-Abfrage schafft ungefähr die gleiche Struktur, wie mein Script.
- Die Nutzungsart (Quelltabelle) als Feld im Satz einfügen.
- Die individuellen Felder in ein Standard-Feld für Klassifizierung abbilden.

Für den Nutzer bzw. Entwickler ist es dann so einfach wie bei ALB, auf die Daten zuzugreifen.
Da dies eine "Sicht" auf die Daten ist, kommt ihre Lösung ohne redundante Daten aus.

Aber in der Datenbank besteht nach wie vor der Aufwand für eine simple Feature-Info, die nur einen Treffer erwartet, 26 verschiedene geometrische Indices abzuarbeiten.

Meine derzeitige Lösung arbeitet in 26 Einzelschritten, das Ergebnis wäre aber das gleiche, als wenn man ihren UNION-View in einer Tabelle zwischenspeichern würde.

Ich denke da auch an Performance und Antwortzeiten.

Daher finde ich nach wie vor, dass der Layer "nutzung" in eine Tabelle gehört und nicht in 26 verschiedene.
Redundante Daten oder ein View, sind Übergangslösungen.
Langfristig wäre es wünschenswert, wenn das gleich in die passende Struktur konvertiert wird.    

Mit freundlichen Grüßen
F. Jäger