[Talk-de] Verwendung von Multipolygonen

[Peter Wendorff]

Am 20.10.2012 15:46, schrieb Willi:
> On Saturday, October 20, 2012 5:47 AM Stephan Knauss
> [mailto:osm at stephans-server.de] wrote:
>
>> Was war denn speziell bei dem Flughafen die Motivation zum Beispiel das
> Vorfeld
>> aus der Relation wegzulassen?
>> http://www.openstreetmap.org/browse/relation/1442532
> 	
> Ich habe das Vorfeld (apron) nicht aus der Relation weggelassen sondern es
> als inneres Mitglied (inner) derselben aufgenommen. Damit wird zum einen
> mitgeteilt, dass es innerhalb der äußeren Begrenzung (outer) des Flughafens
> liegt. Und zum Anderen, dass es etwas Anderes ist als die restliche
> Flughafenfläche (outer ohne alle inner) und anders dargestellt werden soll.
> Wie legt aeroway=apron fest. Für die restliche Flughafenfläche gilt
> aeroway=aerodrome.
Das halte ich für falsch.
Dass das Vorfeld innerhalb des Flughafens liegt, ergibt sich aus der 
Geometrie.
Die Role inner eines Multipolygons dagegen besagt "schneide dieses 
Polygon aus, das gehört nicht dazu."
Das ist ungefähr genau das Gegenteil und hier nicht zutreffend.
Dass es etwas anderes ist als die restliche Flughafenflche (outer ohne 
alle inner), ist etwas anderes, aber dann gehört die Eigenschaft "dies 
ist ein Flughafen" (aeroaway=aerodrome) an den outer-way, nicht ans 
Multipolygon.
> Damit habe ich festgelegt wie ich den Flughafen sehe und verstanden haben
> will. Zum Beispiel zeichnet daraufhin ein Renderer wie Mapnik das Vorfeld
> nach, also über die Flughafenfläche und das Vorfeld ist sichtbar. Da Mapnik
> Wasser nach Flughafenflächen zeichnet wenn nichts anderes angegeben ist, ist
> auch der See http://www.openstreetmap.org/browse/way/33300147
> zu sehen obwohl er kein inneres Mitglied des Multipolygons ist.
Das ist aber ein Problem des Mapnik-Stils, der nichts mit den Daten zu 
tun hat.
Die Daten sind nicht falsch, nur weil der Mapnik-Stil hier 
offensichtlich fehlerhafte Ergebnisse produziert.
> Diesen See http://www.openstreetmap.org/browse/way/186750719
> zeichnet Mapnik nach dem Wald
> http://www.openstreetmap.org/browse/way/186750716
> in dem er liegt. Er ist also sichtbar, auch ohne Multipolygon.
>
> Auch diesen See http://www.openstreetmap.org/browse/way/186750718
> zeichnet Mapnik nach diesem Wald
> http://www.openstreetmap.org/browse/way/186750717.
> Mapnik merkt nicht, dass dies der umgekehrte Fall ist, Wald im See. Mapnik
> prüft gar nicht ob eine Fläche in einer anderen liegt. Der Wald wird nicht
> dargestellt.
Richtig erkannt: Mapnik prüft überhaupt keine Lage, sondern zeichnet 
stumpf in vorgegebener Reihenfolge übereinander.
Meistens funktioniert das, manchmal auch nicht, aber es ist ein Fehler 
bzw. eine Begrenzung von Mapnik, wenn dabei was schiefgeht.
> In diesem Beispiel wird durch eine Relation Multipolygon
> http://www.openstreetmap.org/browse/relation/2410561
> mitgeteilt, dass ein Wald in einem See liegt und Mapnik zeichnet dann den
> Wald nach dem See. Der Wald ist sichtbar.
Jein.
Jetzt sind wir an der Uneindeutigkeit der natürlichen (hier deutschen) 
Sprache.
Die inhaltliche Frage wäre eigentlich: gehört der See zum Wald oder 
nicht? Liegt der See im Wald, oder erstreckt sich der Wald um den See herum?
Semantisch halte ich im Falle von Wald und See beides für vertretbar und 
damit beide Möglichkeiten, das in den Daten zu modellieren, für korrekt.

Beim Flughafen dagegen ist das was anderes: Niemand käme auf die Idee, 
ernsthaft zu behaupten, das Vorfeld gehöre nicht zum Flughafen.
Das gehört nicht zu den Flughafengebäuden, nicht zum Terminal, nicht zur 
Wiese, die sich auch auf dem Flughafengelände erstreckt, aber genauso 
wie Terminals, Wiese und so weiter gehört es zum Flughafen. Es 
auszuschneiden wäre damit falsch.
>
> Da die Reihenfolge der Abarbeitung der Flächen nicht festgelegt ist, kann
> ein anderer Renderer zu einer anderen Darstellung kommen. Durch Verwendung
> von Multipolygonen verhindere ich dies, wie in diesem Beispiel
> http://www.openstreetmap.org/browse/relation/1625506.
Stimmt, dadurch verhinderst Du das.
Aber was tust du damit eigentlich?
Im Flughafen-Beispiel erzeugst Du bewusst und absichtlich Fehler in den 
Daten und versteckst dafür Fehler der Renderer.
Du verminderst Auswertungsmöglichkeiten der Daten (Wie viel Fläche hat 
der Flughafen?) und minderst gleichzeitig den Druck, Fehler in den 
Renderern zu beheben.
Stattdessen könntest Du den Fehler der Renderer berichten und versuchen 
mitzuhelfen, wie man ihn beheben könnte (was zugegeben im aktuellen Fall 
nicht unbedingt einfach wird).
> Ausser für den beschriebenen können Multipolygone auch noch für andere
> Zwecke eingesetzt werden. Zum Beispiel zur Beschreibung von Exklaven und
> Enklaven. Es wird also beschrieben, dass eine Fläche in einer anderen liegt,
> aber nicht zu ihr gehört. Es ist nicht immer sofort ersichlich wozu die
> Relation Multipolygon erstellt wurde. Und so entstehen immer wieder
> Missverständnisse und eigentlich unnötige Diskussionen.
Die Beschreibung von Enklaven und Exklaven ist der einzige (!) Sinn von 
Multipolygonen bzw. deren inner-role.
Deine Beispiele oben sind falsche Anwendungen des Multipolygons, und nur 
so werden Missverständnisse eingeführt, denn eigentlich ist die 
Definition klar:
Die Multipolygon-Relation ist eine Möglichkeit, eine Fläche zu 
beschreiben, die durch einen geschlossenen Linienzug (= closed way = 
Polygon) nicht beschrieben werden kann, indem
a) mehrere nicht geometrisch zusammenhängende Flächen zusammengefasst werden
und/oder
b) Löcher aus einfachen Flächen ausgeschnitten werden.

Die dritte Variante, auch noch aus nicht geschlossenen Wegen Flächen 
zusammenzustückeln, ist eine technisch gebundene "Notlösung", die ich 
persönlich auch schon kritisch sehe; das berührt aber nicht die bis 
hierhin von mir beschriebene Situation.

Gruß
Peter