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

[Christian Müller]

Hallo Wolfgang,


Am 20.04.2012 12:04, schrieb Wolfgang:
> 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)

Weshalb verwässern?  Anhand der inner/outer Rolle, die nur durch ways 
besetzt werden darf, ist doch klar, was zur Flächenberechnung 
herangezogen wird.  Weshalb fürchtest Du die Aufnahme weiterer Elemente 
in anderen Rollen?  Oder geht es Dir nur um die Größe, auf die ein MP 
dann u.U. anwachsen kann?


> 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.

Die Zugehörigkeiten fasse ich genauso auf wie Du - damit sind wir bei 
der Überlappung der Flächen angekommen.  Das Beispiel wird von den 
jetzigen Renderern sicher erwartungsgemäß priorisiert und richtig 
dargestellt.  Spätestens wenn sich landuse=* und leisure=* MPs 
überlappen, kann ich mir aber nicht mehr vorstellen, wie eine 
Renderregel das sinnvoll priorisieren will - Nehmen wir an ein kleinerer 
Stadtpark überlappt auf den Rand einer großflächigeren Wiese.  Es ist 
durch geographische Gegebenheit zu erkennen, dass die Überlappungsfläche 
je nach Sichtweise beiden MP zugeordnet werden kann, also erfasst ein 
OSMler das auch so - in klassischen Karten würde man vermutlich im 
Überlappungsgebiet schraffieren oder punkten.  Da das ganze sehr 
theoretisch ist, lohnt eine Fortsetzung an dieser Stelle vermutlich erst 
mit einem echten Beispiel.  Belassen wir es also dabei..


> 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.
-> Etwas in der Richtung hatte ich im Hinterkopf.  Für komplexe 
Statistiken ist der Rechenaufwand über die räumlichen Abfragen evtl. 
unnötig hoch und wenn es viele Anwender gibt, die unabhängig voneinander 
die gleichen Statistiken erstellen, verschwendet man Energie ;.-)  Ist 
es nicht gerade für die Erstellung solcher Statistiken von Vorteil, wenn 
Schachtelungszusammenhänge explizit in den Relationen wären?  Klar 
können wir uns auch von diversen Rechenzentren abhängig machen, aber 
eine intelligente Lösung ist das nicht, klingt eher wie brute force..


>> 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.

Es ging um (gedachte) nested MP, in denen MP Mitglieder anderer MP sind 
- das ist bisher nicht erlaubt.  Für die gewöhnlichen MP, stimme ich Dir 
zu - schicke Sache.  Mir fällt auf, dass der Terminus "geschachtelte MP" 
auch für die durch alternierende inner / outer Ringe konstruierten MP 
verwendet wird - von diesen habe ich ausdrücklich nicht gesprochen - mir 
ging es um die Verschachtelung von Flächen verschiedenen Typs, weil sie 
logisch Teil einer oder mehrerer anderer Flächen sind.


> [...] Das heißt auch, dass nur die Umringe
> als Typ "outer" definiert werden dürfen, die tatsächlich vom Typ des
> Multipolygons sind.

Ich verweise dann einfach immer auf 
http://wiki.openstreetmap.org/wiki/DE:Relation:multipolygon - spart 
Tipp-Arbeit ;-)


> 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. 

-> Das ist mir alles bekannt, aber dennoch, danke.


>> 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.

Nein, ich schrieb "unterschiedlichen Typs", meinetwegen auch "gleichen 
Typs" aber dann logisch nicht mehr zusammengehörig (wobei das u.U. 
Geschmackssache des Mappenden ist).  Grob nach der Regel:  
unterschiedliche Tags -> neues MP.

Mir geht es darum, Zusammenhänge zwischen MP explizit herzustellen, mit 
einer Erweiterung von MP selbst.  Schließlich sind diese selbst nur eine 
Definition der allgemeineren OSM-Relation, die für die Verlinkung und 
Verschachtelung von MP untereinander einfach einen neuen Rollen-Namen in 
Betracht ziehen kann, ohne die bisherige Verwendung zu ändern, zu 
verwässern, bzw. zu stören.  Problematisch könnte in bestimmten 
Szenarien allenfalls die Anzahl der Mitglieder werden, die dadurch 
entstehen - das ist aber bereits jetzt ein Thema - Ausnahmefälle die 
üblicherweise durch einen Split in separate MP (trotz "gleichen Typs") 
gelöst werden.


> 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.

Ich weiß, ich habe vor einiger Zeit ein wenig mitgeholfen, diese 
Variante der Flächenerfassung mit einem SelectAction-Patch für 
overlapping ways in JOSM salonfähig zu machen..  Gut ist das aber nicht 
- teilweise sind selbst einfache Polygone riesig (Wälder).  Während man 
mit MP vor einem versehentlichen Gesamtdownload halbwegs verschont 
bleibt, klappt das mit closed ways nicht..  Zudem sieht man overlapping 
ways erst durch Verwendung an, wieviele closed ways dahinter stecken.  
Linien, die auf der höchsten Zoomstufe imaginär nebeneinander gezeichnet 
werden, gibt es auch noch - das sieht aber nicht hübscher aus als MP und 
aufwendiger ist es auf Dauer auch noch.


Gruß
Christian