[Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)

[Wolfgang]

Hallo,
Am Freitag, 20. April 2012 02:20:24 schrieb Christian Müller:
> Moin,
> 
> ich mag in diesem Zusammenhang noch einmal kurz auf das Thema
> Flächennetzwerk zurückzukommen.
> Have a fun read..

Da hast du dir ja richtig Arbeit gemacht
;-)

> 
> Am 19.04.2012 13:05, schrieb Wolfgang:
> > -1 Das Multipolygon sollte rein Fläche bleiben, und Fläche sollte
> > nur im Multipolygon erfasst werden. Wer was dazu "sammeln" will,
> > kann das über eine site verbinden. Wieder das Thema Relationen
> > verbiegen.
> 
> Damit würdest Du z.B. sämtliche Parks als type=site Relationen
> erfassen, in denen Du dann die MP der Einzelflächen sammelst.  Aber
> was ist überhaupt eine Einzelfläche?

Ich glaube, an dieser Stelle missverstanden zu sein. Solange es nur um 
zusammengehörige Flächen gleichen Typs geht, reicht das Multipolygon 
völlig aus. Ich will nicht Multipolygone durch Sites ersetzen, sondern 
verhindern, dass 
- das Multipolygon mit Elementen verwässert wird, die mit der Fläche 
nichts zu tun haben (place etc) und
- die Flächenberechnung / Darstellung im Multipolygon konzentrieren 
(wenn sie komplizierter ist als ein einfacher Umring)

> 
> Betrachten wir beispielsweise einen Schlosspark bestehend aus
> mehreren Teichen, Rabatten, Wiesen, etc. die im Park verteilt sind -
> das Schloss selbst steht auf einem Sockel im Zentrum des Parks.
> 
> 1. MP - Teiche
> 2. MP - Rabatten
> 3. MP - Wiesen
> 4. MP - Sockel
> 5. MP - Schloss

6. Schlosspark-Verwaltung


Wenn du das Schloss (mit Sockel :-) ) als nicht zum Schlosspark 
zugehöriig betrachtest, brauchst du in der Tat ein Multipolygon für den 
Park mit inner = Schlosssockel. Die Seen, Wiesen etc würde ich als zum 
Schlosspark zugehörig ansehen und nicht aus der Parkfläche ausschließen 
wollen. Die Seen werden natürlich extra gemappt und erhalten wegen der 
Inseln ein Multipolygon, wobei ein Multipolygon für alle Seen reicht.

Da die ganze Fläche außer dem Schloss zum Schlosspark gehört, ist für 
den Renderer auch klar, dass die Inseln ebenfalls leisure=park zu 
rendern sind. Verwaltungsmäßig gehören sie sowieso zum Schlosspark.

Die Seefläche wird nicht als Loch im Park definiert, weil sie 1. zum 
Park gehört und 2. üblicherweise der Renderer damit klar kommt, die 
Wasserfläche hat insofern Vorrang.

Für das Schloss würde mir eine einfaches Polygon mit building=castle/yes 
reichen.

Beim Sockel kommt es drauf an, wie der aussieht. Das könnte ein 
building=sockel (?) sein. In dem Falle bekäme das Schloss dann den 
layer=1, denn es liegt ja tatsächlich auf dem Sockel.

Jetzt haben wir ein Multipolygon für den Schlosspark, eins für die Seen, 
jeweils ein Polygon für den Sockel und das Schloss.

Einzelheiten des Parks wie Rabatte etc erhalten einfache Polygone. Es 
ist eine reine Frage der Logig, dass sie, wenn gewünscht, "über" dem 
Park gerendert werden. Dass sie zum Park gehören, muss ggf. aus der Lage 
ermittelt werden. Wenn jemand eine Statistik aller Rosenbeete in den 
Schlossparks des Landes erstellen will, dann muss er eben abfragen, 
welche Beete sich räumlich in einem solchen Park befinden.

Für die Verwaltung kommt eine Site hinzu, name = "Staatliche Verwaltung 
der Beispielhaften Gärten, Schlösser und Seen", Members sind der 
Schlosspark, das Schloss und weitere Anlagen, die zu der Verwaltung 
gehören, sowie ggf. das Verwaltungsgebäude, das vermutlich in der 
Landeshauptstadt des Beispielhaften Freistaates steht.

:-)


[...]

> 
> Leider sind verschachtelte MP-Relationen (nestedMP) unpraktikabel,
> wenn es um die Berechnung der Fläche geht, die sich aus den
> Einzelflächen der Kinder und Kindeskinder (..) ergibt.  Schließlich
> sind nur die outer/inner Mitglieder der Kinder und Kindeskinder (..)
> interessant, die tatsächlich einen Beitrag zu Außen- oder
> Innenringen des nestedMP liefern.  Ab einer bestimmten
> Schachtelungstiefe wird die
> Grenzbestimmung daher unbeherrschbar - um die Flächengrenze eines
> nestedMP zu ermitteln, müssten alle Blätter des MP-Baumes durchsucht
> werden, also alle Relationen, die dann tatsächlich way-members als
> Mitglieder haben und nicht selbst ein nestedMP sind.  Je tiefer
> dieser Baum, desto höher die Wahrscheinlichkeit, dass es mehr
> irrelevante members als relevante gibt.

So ganz kann ich deinen Ausführungen nicht folgen. Im Prinzip ist das 
Multipolygon überraschend einfach zu berechnen und gleichzeitig 
geschickt aufgebaut.

Regel 1: Jeder Umring kann aus einer beliebigen Anzahl von Polygonen 
bestehen, dabei müssen Anfangs- und Endpunkte auf einander folgender 
Polygone identisch sein und der Umring als Ganzes ein geschlossenes 
Polygon ergeben

Regel 2: Alle geschlossenen Polygone (Umringe), die innnerhalb eines 
geschlossenen Polygons liegen, bilden ein "Loch" in diesem, sie dürfen 
das äußere Polygon nicht berühren.

Regel 3: Die Umringe werden geschachtelt und liegen in beliebiger Tiefe 
ineinander. Inner und Outer können, müssen aber nicht angegeben werden. 
Sie dienen der Übersicht des Mappers und können zur Fehlerkontrolle 
benutzt werden.

Regel 4: Die Eigenschaften des Multipolygons beziehen sich auf alle 
Polygone einer ungeraden Schachtelungstiefe. Die Umringe der geraden 
Schachtelungstiefen sind Löcher. Das heißt auch, dass nur die Umringe 
als Typ "outer" definiert werden dürfen, die tatsächlich vom Typ des 
Multipolygons sind.

Beispiel dazu: Geschlossenes Korallenatoll mit Lagune und Vulkaninsel. 
Das Multipolygon vom typ "Koralleninsel" hat als Outer den Umring des 
Atolls, als Inner den Umring der Lagune. Der Umring der Vulkaninsel wird 
hier nicht reingesetzt, weil er "outer" wäre und nicht vom Typ 
"Koralleninsel" ist. Er gehört aber als "inner" in das MP der Lagune.

> 
> Bsp.: Kreisgrenzen und Landesgrenze - es gäbe 'zig innenliegende
> Kreisgrenzen, die für die Berechnung der Landesgrenze nicht relevant
> sind - deshalb macht es für die Berechnung der Grenzgeometrie keinen
> Sinn, die Landesgrenze über ein nestedMP mit allen
> Kreisgrenz-Relationen als Mitglieder zu erfassen.  Dennoch
> interessiert evtl. der Flächenbezug der Kreisflächen zur
> Landesflächen in einem anderen Kontext.  Beide Wünsche ließen sich
> vereinen.

Für Grenzen bietet sich das Multipolygon an - nicht um irgendwelche 
"inner" zu definieren, sondern weil es möglich ist, das "outer" aus 
einer größeren Anzahl von (nicht geschlossenen) Polygonen zu definieren, 
die zusammen einen geschlossenen Umring ergeben. Ähnlich wie bei der 
coastline hat es gewisse Vorteile, nicht immer den ganzen Umring der 
z.B. USA laden zu müssen.

Die Landesgrenze ist ein MP, die Kreisgenzen jeweils auch. Wer die 
Hauptstadt, Verwaltungszentrale oder was auch immer da rein bringen 
will, kann das dann über die Site machen.

Members sind dann das Multipolygon mit der Grenze und der place-Node der 
Zentrale. Land und Kreise untereinander brauchen keine weitere Relation, 
da sich ihre Zusammengehörigkeit aus der Lage ergibt, im Gegensatz zur 
Zentrale einer Grenze. Da die Grenze in der Regel eine Vielzahl von 
places umschließt, kann hier nicht gefolgert werden, welcher place als 
Hauptort gemeint ist.

> 
> 
> 
> Um auf das Beispiel zurückzukommen:  Ich kann mir auch den gesamten
> Park als Einzelfläche vorstellen, ohne die Grenzen der Rabatten,
> Teiche, Wiesen, etc.  Weil ich das kann, möchte ich den Park auch
> als type=multipolygon anlegen und nicht als type=site (Anm.:
> type=site entspräche einem nestedMP, wenn man daraus die Geometrie
> der Gesamtfläche des Parks ermitteln will).  

Wenn ich dich richtig verstehe, willst du für jede kleine Enzelfläche 
ein MP anlegen. Wie oben beschrieben, ist das nicht notwendig.

Um das nochmal klar zu stellen: es gibt eine vereinfachte 
Flächendarstellung mit verschiedenen tags (building=*, natural=water, 
landuse=*, ...). Solange das nur ein ganz einfaches geschlossenes 
Polygon ist, würde ich immer das benutzen. Sobald aber kompliziertere 
Gebilde auftreten, die entweder Löcher haben oder/und durch mehrere 
zusammenhängende Abschnitte sinnvollerweise definiert sind, sollte nur 
das Multipolygon für die Fläche genutzt werden. Nicht-Flächen-Elemente 
werden dann per Site dazugesetzt.

Gruß, Wolfgang