AW: [PostNAS] SQL-Abfrage / csv-Datei erzeugen

[Hentschel, Markus]

Hallo Herr Mau,
Hallo Herr Jäger,


>> Wollen sie wirklich so eine Struktur?
>> Wenn ja - Wozu?

Da muss ich ein bißchen widersprechen. Wir haben in unserem kvwmap-Framework genau so etwas als Feature eingebaut und es ist eines der meistgenutzen Features. Es gibt einen Flurstücks-CSV-Export (der die möglichen 1:n Beziehungen wie z.B. Eigentümer in ein Feld schreibt!), es gibt einen Eigentümer-CSV-Export (pro Eigentümer eine Zeile) und einen Nutzungsarten-CSV-Export. Der Nutzer wählt aus, welche Buchdaten-Elemente im Export enthalten sein sollen. Dass das manchmal recht wüst aussieht (zehn Eigentümer in einem Feld) und zum Teil Wiederholung ohne Ende bedeutet, ist wohlbekannt, stört aber offenbar wenig.

Das Ganze funktioniert bislang auf ALB-Basis, wir wollen daran aber auch in ALKIS-Zeiten (dann auch PostNAS-Zeiten) festhalten, da es wirklich gebraucht und auch als Produkt verkauft wird.

Beste Grüße
Markus Hentschel
 

Landkreis Vorpommern-Rügen

Fachdienst Kataster und Vermessung
Fachgebiet Geodatenzentrum
 






-----Ursprüngliche Nachricht-----
Von: nas-bounces at lists.osgeo.org [mailto:nas-bounces at lists.osgeo.org] Im Auftrag von Frank
Gesendet: Mittwoch, 11. April 2012 20:33
An: nas at lists.osgeo.org
Betreff: Re: [PostNAS] SQL-Abfrage / csv-Datei erzeugen


Am 11.04.2012 16:08, schrieb David.Mau at stadt.mainz.de:
> Hallo PostNAS-Gemeinde,
>
> ich möchte eine csv-Datei mit folgenden Kriterien aus einer PostGIS-DB
> (PostNAS_06-Schema) erzeugen:
>
> 1) Eigentümerbezogene Auswertung (ax_person) mit
> 2) Angaben zum Flurstück (ax_flurstueck)
> 3) Angaben zur Adresse des Eigentümers (ax_anschrift)
> 4) Angaben zum Eigentüner (ax_namensnummer)
> 5) Angaben zum Buchungsblatt (ax_buchungsblatt)
> 6) Angaben zur Buchungstelle (ax_buchungsstelle)
> 7) Angaben zum historischen Flurstück (ax_historischesflurstueck)
> 8) Angaben zum historischen Flurstück-ALB 
> (ax_historischesflurstueckalb)
>
> Die SQL-Abfragen für die Views "flurstuecke_eines_eigentuemers", 
> "rechte_eines_eigentuemers" und "adressen_zum_flurstueck" kommen 
> meinen Anforderungen schon recht nah.
>
> Kann man das irgendwie zusammenbringen? Über Lösungsansätze von Euch 
> würde ich mich sehr freuen.
>
> Vielen Dank für Eure Unterstützung.
>
> Mit freundlichen Grüßen
> i.A.
>
> David Mau

Ja ääähh jein,
natürlich kann man das irgendwie mit ein wenig Fleiß alles in eine lineare Struktur quetschen, die dann als cvs-Datei ausgegeben werden kann.
Ich bezweifle aber, dass irgend jemand mit dem Ergebnis etwas anfangen kann. Die Frage ist aus meiner Sicht weniger, WIE das geht, sondern eher, WARUM man das tun sollte.
Es hat schon seiner Grund, dass ALKIS-Daten als XML (NAS) ausgeliefert und dann in eine relationale Datenbank gespeichert werden. Dort werden die Relationen (1:N) passend abgebildet.
Durch die Auskunft-Programme werden dann jeweils verbundene Gruppen von Tabellen zusammen lesbar angezeigt. Dazu werden z.B. noch zusätzliche Schlüsseltabellen hinzugezogen, die in der Frage noch gar nicht erwähnt wurden, die aber auch benötigt werden um die Daten zu interpretieren.
Über einen Link geht es dann zur nächsten Gruppe von Tabellen.

Beispiel:
- Ein Format zeigt alles zum Flurstück,
- ein anderes Format zeigt alles zum Grundbuch.
- Ein drittes Format kann die Historie Schritt für Schritt nachverfolgen.

Die Historie muss ja manchmal über mehrere Zwischenschritte analysiert werden, z.B. wenn zunächst mehrere Flurstücke verschmolzen wurden um sie dann in anderer Geometrie wieder neu zu teilen.

Einige der Beziehungen sind von der Art "1:N", z.B. ein Flurstück kann mehrere Buchungen (auf verschiedenen Grundbüchern) haben (Wohnungseigentum).
Natürlich können auch auf einem GB-Blatt mehrere Buchungen (also
Flurstücke) sein.
Zwischen GB-Blatt und Flurstück ergibt sich somit eine N:N-Beziehung.

Andere Beziehungen sind 1:N wobei N auch 0 sein darf.

Was würde also passieren, wenn wir alles mit einer Equivalenzanfrage linearisieren würden?
Es werden Zeilen gebildet. Damit keine Felder leer bleiben, wird bei 1:n der 1-Anteil wiederholt. Mal kommt also das Flurstück mehrfach vor, mal das Grundbuch.
Gibt es es zum Grundbuch dann noch 10 Eigentümer wird alles noch 10 mal wiederholt, jeweils mit verschiedenen Namen in der Zeile.
Auswerten kann man das nicht mehr. Wenn z.B. die Flächensumme gebildet werden soll, dürfte die Fläche ja nur einmal vorkommen.

Dann kommt die Historie, die ja auch noch mit drin sein soll:
  Da ist die Tabelle mit sich selbst verknüpft um Schritt für Schritt abbilden zu können. Wie viele Generationen sollen maximal möglich sein?
5, 10, 100?
So oft müsste die Spalte wiederholt werden.

Das WIE wird dann noch dadurch erschwert, dass verschiedene Rechtsformen über verschiedene Verbindungen laufen.
Erbbaurecht: Recht einer Buchung an einer anderen Buchung.
Dies auch noch mit in die lineare Tabelle?
Bitteschön. Und - noch den Überblick?

Wollen sie wirklich so eine Struktur?
Wenn ja - Wozu?

--

Frank
_______________________________________________
NAS mailing list
NAS at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/nas