Am 20.10.2012 15:46, schrieb Willi:
On Saturday, October 20, 2012 5:47 AM Stephan Knauss
[mailto:o...@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
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
