Hallo Micha,
ja, das hast du richtig erkannt:
> ... Es sind ja verdammt viele Tabellen!
ALKIS ist ja auch eine sehr komplexe Datenstruktur. Man muss sich eben mit den
Strukturen vertraut machen um eine sinnvolle Abfrage zustande zu bringen.
> Nun möchte ich die Flurstücke ... INKLUSIVE ... Eigentümer in eine Tabelle
> ... umwandeln.
Ja diese Frage kenne ich. Seit fast 30 Jahren betreue ich die Verfahren zum
Liegenschaftskataster und immer wieder kommt die Forderung, die komplexen
N:N-Strukturen über mehrere Tabellen doch einfach mal "platt zu klopfen" und
EINE TABELLE daraus zu machen. Also eine schöne lineare Struktur ohne
Verzweigungen und Sonderfälle wo man nicht mehr nachdenken muss.
Nun gut, gehen wir es an! Was soll geopfert werden?
Sollen Daten weggelassen werden, z.B. nur einen Eigentümer von mehreren
darstellen? - Wahrscheinlich nicht.
Also opfern wir die Redundanzfreiheit, machen einen langen JOIN quer durch
viele Tabellen. Wenn es mehrere Eigentümer gibt, dann wiederholen sich eben
alle anderen Daten für jeden Namen.
Dann bitte aber nachher keine Summe aus der Spalte Fläche bilden, das passt
dann nicht mehr!
Und soll das auch für die Darstellung verwendet werden?
> ... mit ihren Grenzen (Polygone)
Offensichtlich ja.
Nun gut, wenn es EINE platte Tabelle sein soll UND alle Eigentümer drin sein
sollen, dann ist auch die Polygon-Geometrie des Flurstücks für jeden Eigentümer
einmal enthalten. Das Flurstück wird also bei 20 Eigentümern auch 20mal
übereinander gezeichnet und bei räumlichen Abfragen dann auch 20 mal gefunden.
Das ist der Preis des "Platt machens".
Sollte man vielleicht doch besser bei einer Datenbank mit MEHREREN Tabellen
bleiben und die Flurstücke aus der zuständigen Flurstückstabelle rendern?
Immer noch sicher, dass es eine gute Idee ist, das alles in EINE Tabelle zu
stecken?
OK, dann gehen wir es an:
Im Groben sieht der JOIN für die einfachen Fälle so aus:
Flurstück -> Buchungsstelle (Grundstück) -> Grundbuchblatt -> Namennummer ->
Name -> Adresse (des Eigentümers)
Erklärung:
- Ein Flurstück gehört zu einer Buchung (Grundstück)
- Das Grundstück ist auf einem Grundbuchblatt gebucht.
- Das Grundbuchblatt kann mehrere Eigentümer haben, z.B.
1. zu 1/2
2.1 zu 1/4
2.2 zu 1/4
Oder auch einfach "1. bis 4. In Erbengemeinschaft"
- Diese Eigentümer (Namensnummern) verweisen auf die Namentabelle.
- Die Namen verweisen auf die Adressen. Ein Eigentümer kann ja auch mehrere
Adressen haben.
Dann gibt es aber noch Sonderfälle, die zu berücksichtigen sind. Das sind
solche Buchungsarten wie "Erbbaurecht" und "Wohnungsgrundbuch".
Da hat eine Buchungsstelle das "Recht an" einer anderen Buchungsstelle. Es sind
also mehrere Grundbücher beteiligt, jedes Grundbuch hat seine eigenen
Eigentümer.
Also z.B. die normalen Eigentümer, die das Erbbaurecht gewähren und die
Erbbauberechtigten.
Die Anteile auch bitte berücksichtigen, davon gibt es 2 Arten: Bei einem
Gebäude, das in Eigentumswohnungen aufgeteilt ist, hat jedes Grundbuch zu einer
Eigentumswohnung einen Anteil am Flurstück.
Bei mehreren Eigentümern zu einem Grundbuch hat jede Namensnummer einen Anteil
am Grundbuch.
Da haben wir dann folgenden JOIN für die Sonderfälle mit "Recht an", die
zusätzlich (UNION) zum oben genannten JOIN zu berücksichtigen sind:
Flurstück -> Buchungsstelle -(hat Recht an)-> Buchungsstelle ->
Grundbuchblatt -> Namennummer -> Name -> Adresse
--> Grundbuch
Als Basis für die Zusammenfassung zu einer Tabelle kann der View "exp_csv"
dienen, der in folgender Datei zu finden ist:
http://trac.wheregroup.com/PostNAS/browser/trunk/import/sichten.sql
Der hat die Aufgabe eine CSV-Datei (Excel-Tabelle) zu exportieren, also ohne
Geometrie.
> ) UND Beschriftungen I
Na klar, die auch noch.
Beschriftungen zum Flurstück sind die Flurstücksnummern. Wenn die außerhalb der
Fläche liegen, dann braucht man auch noch einen Zuordnungspfeil bestehend aus
Liniengeometrie und Pfeilspitze (Punkt und Drehwinkel) dazu.
Es gibt mehrere Beschriftungs-Texte zu einem Flurstück mit jeweils eigener
Geometrie (Position) jeweils passend zu einem Kartentyp (Maßstab).
Die kann man in der Tabelle "ap_pto" finden, wobei art = 'ZAE_NEN' ist. Der
Join zum Flurstück erfolgt über das Array 'dientZurDarstellungVon' und den
gewünschten Kartentyp wählt man aus 'AdvStandardModell'.
Das kann man dem View ja noch hinzufügen ;-) Viel Spaß
> Die Kollegen basteln dann mit ArcView weiter (ist halt so bei uns) und machen
> druckbare Karten draus.
Die "druckbare Karte" sollte dann aber nicht nur Flurstücke enthalten sondern
auch die anderen etwa 50 Ebenen mit ALKIS-Objekten.
z.B. Gebäude, Straßennamen, Nutzungsarten, Bodenschätzung, Grenzpunkte,
Baulasten, ....
Und wahrscheinlich müssen wir dabei auch wieder die komplexen Strukturen "ganz
einfach" aussehen lassen, damit die Kollegen sich beim "Basteln" nicht
überanstrengen?
Fazit:
In den ALKIS-Programmen des Projektes PostNAS steckt Monate lange Arbeit. Diese
Arbeit hätten wir uns nicht gemacht, wenn es möglich wäre, das ALKIS mal eben
in ein Shapefile zu packen um es - schwupps - in einem ArcView zu päsentieren.
So banal ist das nicht.
Insbesondere sollte man "Karte" und "Buchwerk" ein wenig getrennt betrachten.
Jeder Teil für sich ist schon schwierig genug. Das sollte man nicht auch noch
zusammen schütten.
Alternative:
Man verwendet die Programme, die bereits gemacht wurden um durch diese
komplexen Strukturen redundanzfrei zu navigieren.
Siehe Demo: http://map.krz.de/alkis/mapbender.php
Alle Dateien zu der Demo findet man im SVN:
http://trac.wheregroup.com/PostNAS/browser/trunk/
Oder verwende nicht nur das PostNAS-Import-Programm von NorBIT sondern auch das
dazu passende QGIS-Plugin für Darstellung und Auskunft.
Wenn "die Kollegen" das in ArcView nachbauen möchten, sollten sie mit einem
Aufwand von mehreren Monaten rechnen.
Viel Erfolg!
F. Jäger
> -----Ursprüngliche Nachricht-----
> Von: fossgis-talk-liste-boun...@fossgis.de [mailto:fossgis-talk-liste-
> boun...@fossgis.de] Im Auftrag von fischotter_...@web.de
> Gesendet: Sonntag, 22. März 2015 22:14
> An: fossgis-talk-liste@fossgis.de
> Betreff: [FOSSGIS-Talk] QGIS - NAS-ALKIS-Daten weiterverarbeiten
>
> Hallo Liste,
>
> mit dem ALKIS-Tool von norBIT [1] habe ich die ALKIS-Testdaten von
> Brandenburg [2] in eine PostGIS-DB überführt und dann in QGIS mit der
> entsprechenden norBIT-Erweiterung [3] eingelesen. Das klappt sehr gut.
>
> Nun möchte ich die Flurstücke mit ihren Grenzen (Polygone) UND
> Beschriftungen INKLUSIVE (manchmal auch mehrerer) Eigentümer in eine
> Tabelle und ein Shape (für die Kollegen) umwandeln.
>
> Geht das in QGIS und/oder mit pgAdmin? Wenn ja, wie? Es sind ja verdammt
> viele Tabellen! Oder läuft das ganz anders?
>
> Die Kollegen basteln dann mit ArcView weiter (ist halt so bei uns) und machen
> druckbare Karten draus.
>
> Der Micha.
>
> [1] http://norbit.de/74/
> [2] http://www.geobasis-bb.de/GeoPortal1/produkte/aaa-testdaten.html
> [3] http://plugins.qgis.org/plugins/alkisplugin/
> --
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname : smime.p7s
Dateityp : application/pkcs7-signature
Dateigröße : 7599 bytes
Beschreibung: nicht verfügbar
URL :
<https://lists.fossgis.de/pipermail/fossgis-talk-liste/attachments/20150323/580a8408/smime.p7s>
--
....................................................................
FOSSGIS und OpenStreetMap auf der Agit 2015 in Salzburg
8.-10. Juli, Universität Salzburg
http://www.agit.at
FOSSGIS e.V, der Verein zur Förderung von Freier Software aus dem
GIS-Bereich und Freier Geodaten!
http://www.fossgis.de/ https://twitter.com/fossgis_eV
____________________________________________________________________
FOSSGIS-Talk-Liste mailing list
FOSSGIS-Talk-Liste@fossgis.de
https://lists.fossgis.de/mailman/listinfo/fossgis-talk-liste
