[FOSSGIS-Talk] QGIS - NAS-ALKIS-Daten weiterverarbeiten

Jäger, Frank (KRZ) F.Jaeger at KRZ.DE
Mo Mär 23 12:59:22 CET 2015


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-bounces at fossgis.de [mailto:fossgis-talk-liste-
> bounces at fossgis.de] Im Auftrag von fischotter_lsa at web.de
> Gesendet: Sonntag, 22. März 2015 22:14
> An: fossgis-talk-liste at 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>