Bei diesem Park, der im wesentlichen aus einem großen innenliegenden See besteht, habe ich zum ersten Mal Multipolygon verwendet: http://www.openstreetmap.org/?lat=16.41321&lon=102.83779&zoom=16&layers=B000FTF, http://www.openstreetmap.org/browse/relation/556138.
Grund: Der Park ist nur teilweise mit 2 einzelnen “Zaunsegmenten” umgeben. Zunächst hatte ich diese getrennt als parallele Linien gezeichnet. Nachdem ich mich über Multipolygon informiert hatte, erschien mir dies die elegantere und richtigere Methode.
Ist dies der Fall und habe ich dies korrekt umgesetzt?
Des weiteren gibt es im Park 4 Objekte, die direkt an den Rand des Parkes anschließen. Ausserhalb ist jeweils ein Gehweg, den ich der Ringstraße zurechne.
einen kleinen Wald (forest) http://www.openstreetmap.org/?lat=16.409483&lon=102.835906&zoom=18&layers=B000FTF.
Diese Objekte sind momentan separat nahe am Parkrand eingezeichnet. Der Wald grenzt zudem auch an den See. Dies führt zur JOSM Validator Warnung “Multipolygon-Wege schneiden sich”. Die zum Parkrand parallelen Linien sind eigentlich gemeinsame Linien. Wie kann ich dies mit Multipolygon ohne doppelte Knoten und Linien umsetzen? Meine bisherigen Versuche lokal in JOSM 3184 ergaben nur “schwarze Löcher”.
Elegant ist Geschmackssache und richtig oder falsch gibt es bei OSM nicht. Aber deine Loesung finde ich unnoetig kompliziert, kein Wunder, dass sie den Renderern Probelme bereitet.
Den Park wuerde ich einfach als einzelnes outer-Polygon einzeichnen, unabhaengig von den Zaeunen. Die Zaeune wuerde ich dann als eigene Polygone einzeichnen, wobei man je nach Geschmack die Knoten vom Park-Polygon mitbenutzen kann oder leicht versetzt parallele Linien eintraegt (so wie du das wohl erst gemacht hattest).
Grundsaetzlich ist es noch eine Ueberlegung, ob fuer den Park ueberhaupt ein multipolygon noetig ist. Der See im Park ist doch Teil des Parks, oder? Dann duerfte er naemlich nicht als inner vom Park ausgeschnitten werden, denn per Definition gehoeren die Flaechen innerhalb der inner-Teile ja nicht zu der Multipolygon-Flaeche.
Wenn der Sportplatz, der Wald und die Seen an den Rand angrenzen (da also kein zum Park gehörender Rand mit Wiese o.ä. ist), dann würde ich den Park nur um diese Flächen außenrum zeichnen und nicht über die gesamte Fläche und dann mit Multipolygon alles wieder ausschneiden. Die zugehörigkeit zu einem Gesamtgebilde (dem Park also), wäre am besten mit einer site-Relation oder etwas in dieser Richtung ausgedrückt.
Der Sportplatz in seiner jetzigen Lage sollte NICHT als Mitglied der Relation eingefügt werden, es sei denn als INNER-Element, WENN die Grenze des Sportplatzes innerhalb der Parkgrenze liegt.
Es gibt übrigens die Möglichkeit, in Potlatch mit der Taste P zwei Linien zu erzeugen, die genau 1 (bzw. X) Meter links und rechts neben der Mauer bzw. dem Zaun verlaufen.
Der Wald müsste ebenfalls als INNER-Element eingetragen werden.
Der Sportplatz liegt komplett innerhalb des Parkes. Es gibt keinen Zwischenraum, der Zaun des Parkes begrenzt zugleich den Sportplatz, er fängt in Richtung Straße fliegende Bälle ab. Zunächst versuchte ich, wie beim Zaun, das entsprechende Stück des Outer-Multipolygon Park für das Inner-Objekt Sportplatz mitzuverwenden. Zwar konnte ich dies in JOSM so eingeben, es wurde aber falsch gezeichnet.
Somit sehe ich im Moment nur die Möglichkeit, den Sportplatz als separate Fläche zu erstellen, wobei entlang der Parkgrenze
entweder leicht versetzte parallele Polygone mit zusätzlichen Knoten
oder doppelte aufeinanderliegende Polygone unter Mitverwendung der Knoten der Parkgrenze gezeichnet werden.
Letzteres kommt meines Erachtens der Wirklichkeit näher, da eine Doppellinie ja nicht wirklich vorhanden ist.
Eine Lichtung liegt innerhalb eines Waldes, aber auf der Flaeche der Lichtung ist selber kein Wald. Insofern gehoert die Lichtung also auch nicht zu dem Gebiet, dass mit landuse=forst gekennzeichnet ist.
Etwas unsauber wird die Sache, wenn man innerhalb eines OSM-Objektes die Waldflaeche (landuse=forst) mit dem Gebiet vermischt, dass als XYZ-Wald bezeichnet wird. Letzteres ist ja haeufig mehr als nur die reine Waldflaeche. Wenn man das aber sauber in der Karte haben will, dann kann man dafuer nicht das selbe Element benutzen wie fuer den landuse.
Bei einem Park mit einem See drin ist das aber nicht so zwingend getrennt wie bei der Waldflaeche und der Lichtung. Ein Park ist normalerweise eine Gesamtanlage. Da gibt es beispielsweise Grasflaechen, Blumenbeete, Baumgruppen und eben auch Seen, die alle Teil des Parkes sind. Solche Flaechen als Multipolygon aus dem Park ausschneiden zu wollen ist falsch, weil sie damit dann nicht mehr zum Park dazugehoeren wuerden.
Nimm statt des Parkes mal eine Stadt mit einem Gewerbegebiet als Beispiel. Wenn man da die Stadt als Multipolygon eintragen und dann das Gewerbegebiet als inner-Element daraus ausschneiden wuerde, so wuerde das bedeuten, dass das Gewerbegebiet nicht zur Stadt dazugehoert. So ist es ja aber nicht, und deshalb macht man das auch nicht so.
Wie von Dir schon selbst im allerersten Posting genannt, sollten die Innenpolygone eines Multipolygons komplett innerhalb des Außenpolygons liegen, d.h. ein Innenpolygon darf nirgendwo an den Außenrand angrenzen. Bei dem Sportplatz, dem Wald und den Springbrunnen ist jenes momentan aber der Fall.
Wie wohl auch von Dir angedacht, wäre eine erste Lösungsmöglichkeit, die entsprechenden Flächen mit geringem Abstand vom Außenpolygon anzulegen. Dann liegen sie innerhalb desselben und es gibt keine Überschneidungen mehr.
Die zweite Lösungsmöglichkeit wäre, die Parkfläche als eigenständige einzeln Fläche einzuzeichnen und an der Innenseite des Sportplatzes, des Waldes und der Springbrunnen entlang zu führen. Jene Flächen fallen dann aus dem Multipolygon heraus. In diesem Fall ermöglicht das sogar den kompletten Verzicht auf das Multipolygon, wie von de_muur schon mal angedeutet (Die Landfläche des Parks wird als in sich geschlossene Fläche gezeichnet und am Zaun, dem Sportplatz, den Springbrunnen und dem See entlang geführt. Der See liegt dann aufgrund des Waldes nicht mehr innerhalb dieser Fläche. Auf das Multipolygon kann verzichtet werden). Diese Lösung halte ich hier für am besten.
Der einzige Nachteil jener zweiten Lösung ist, dass der Name des Parks dann nur noch für die Landfläche gilt und nicht mehr für den See, die Springbrunnen, den Sportplatz und den Wald, welche man ggf. noch zum Park zählen könnte. Dies halte ich aber für das kleinere Problem. Hier tritt sowieso das von de_muur angesprochene Dilemma auf. Was gehört überhaupt wozu? Schon im Alltagsgebrauch wird derartiges nach dem jeweiligen Nutzungszweck variiert. Dementsprechend lässt sich dies auch bei OSM nicht eindeutig festlegen.
Bei Multipolygonen war ein entscheidenden Ziel, überlagernde Flächen zu vermeiden, also z.B. Wasserflächen, die auf Landflächen liegen. Das sollte man meiner Meinung nach so beibehalten. Deshalb schneide ich einen See ggf. per Multipolygon auch aus einer Parkfläche aus. Nun mit Argumenten wie “der See ist auch Teil des Parks” von dieser Regel abzuweichen, bringt unnütze Unklarheiten. OSM kann nun einmal nicht alle Beziehungen und Zusammenhänge abdecken!
Ich denke, du versuchst eine semantische Bedeutung mit dem Multipolygon
zu verknüpfen. Das ist weder in OSM insgesamt, noch speziell bei den Multipolygonen gewollt oder dokumentiert. Dort steht im Detail:
*type multipolygon Tells applications to use area-building rules on the members.*
Da wird nur auf Fächen innerhalb von größeren Flächen eingegangen.
Eine semantische Beziehung wie “weil sie damit dann nicht mehr zum Park
dazugehoeren”, entspricht meiner Meinung nach weder der Absicht noch der
Definition von Multipolygonen.
Genau darum geht es aber bei den inner-Mitgliedern von multipolygonen. Mit den outer Polygonen definiert man den aeusseren Rand einer Flaeche (oder auch mehrerer), und mit den inner Polygonen definiert man innere Raender, also Ausschlussbereiche. Da gibt es eigentlich nichts an der Beschreibung zu deuten, und auch die Beispielbilder sind da ganz eindeutig.
Wie bei OSM so ueblich werden auch die multipolygone haeufig eher recht lax gebraucht (oder eher missbraucht), viele Leute machen sich einfach keine Gedanken darueber, was sie da logisch eigentlich eintragen und sind zufrieden sobald das Ergebnis im Renderer ihren Wuenschen enstspricht.
Wenn aber einer nachfragt, wie er ein multipolygon einrichten sollte, dann sollte man ihm auch die logisch korrekte Nutzung nennen und nicht irgendwelchen Murks.
Da bin ich anderer Meinung. Es geht um Geometrie, nicht um Semantik. Es geht
um Flächen in Flächen, wobei die innenliegenden Flächen andere Eigenschaften
haben als die sie umgebende Fläche.
Ob diese Eigenschafen (semantisch) gegensätzlich oder zusätzlich sind spielt keine
Rolle. Wir interpretieren die Semantik beim Betrachten der Daten/Karten hinzu.
Um das beliebte Beispiel See im Wald zu bemühen.
Der See ist nicht Teil des Waldes.
Der See ist Teil des Waldgebietes.
Es ist also die Frage wie jemand landuse=forest semantisch interpretiert ,die darüber
entscheidet, welche der beiden obigen Aussagen richtig ist und welche falsch.
Welche unserer gegensätzlichen Meinungen logisch (wieder ein semantischer Begriff)
richtig ist, ist reine Ansichtssache, was ein Multipolygon beschreiben soll: die Geometrie
oder die Semantik. Meiner Meinung nach die Geometrie, weil eine semantische
Interpretation der Daten nur zu widersprüchlichen Ergebnissen führen kann.
Der Ärger mit diesen unterschiedlichen Interpretationen der Multipolygone stammt
leider von der Wiki-Seite dazu. Der Begriff ‘Loch in Fläche’ (hole in area) mag eine
semantische Interpretation nahelegen. Dies ist meiner Meinung nach jedoch nicht
beabsichtigt.
Ansonsten stimme ich dir zu, dass wir die unterschiedlichen Interpretation der
Multipolygone durchaus kundtun sollten.
Ja, aber was heisst das denn?
Entweder sagt ein multipolygon aus, dass die innenliegenden Flaechen anders sind, weil sie NICHT die Eigenschaften des aeusseren Bereiches haben, oder aber ein multipolygon sagt was aus?
Eigentlich bleibt gar keine andere Moeglichkeit ueber. Soll es eine Und-Verknuepfung ausdruecken? Oder ein “ich-weiss-es-nicht”? Wie wuerde man dann das Gilt-Nicht-Im-Innern ausdruecken? Und wozu braucht man dann ueberhaupt das multipolygon, was sagt es mehr aus, als die reine Geometrie der Polygone?
Ich denke eher, dass das der Punkt ist, ueber den man anderer Meinung sein kann. Mit landuse=forest meint man einerseits die Flaeche, wo die Baeume wachsen. Haeufig traegt man allerdings an dieses Polygon auch ein name-Tag ein, dass das gesamte Waldgebiet, also inklusive Lichtungen, Seen usw. bezeichnet. Dass diese beiden Sachen aber nicht identisch sind, machen sich die meisten Mapper gar nicht klar. Eigentlich muesst eman zwei Objekte eintragen, also die reine Waldflaeche unabhaengig vom gesammten Waldgebiet. Erstere waere dann ein multipolygon, letztere i.A. ein einfaches Polygon, das alles beinhaltet.
Und eine aehnliche Situation hat man auch bei leisure=park. Meint man damit ausschliesslich die Flaechen, die einen parkartigen Charakter haben? Oder meint man damit die Parkanlage in ihrer Gesamtheit? Wobei sich ein name-Tag nur auf das zweite Beziehen wird, und es deshalb auch logisch zwangslauefig eine Interpretation fuer das erste vorgibt, jenachdem, wo man das name-Tag fuer die Parkanlage anbringt.
Nehmen wir mal einen Way 1: 3km nach rechts, 3km runter, 3km nach links, 3km rauf. Der Way ist also in sich geschlossen und hat als Fläche 9 Quadratkilometer.
Der Way 2 ist genauso, aber mit 1km Kantenlänge und schön mitten drin. Er gibt eine Fläche von 1 Quadratkilometer an.
Ein Multipolygon mit Way1 als outer und Way 2 als inner gibt eine Fläche von 8 Quadratkilometer an. (Die Fläche hat ein Loch.)
Will man etwas über die 9 Quadratkilometer große Fläche sagen, dann sollte man das mit Tags von Way1 ausdrücken.
Will man etwas über die kleine Fläche in der Mitte sagen, dann kommen entsprechende Tags in Way 2.
Wenn man etwas über die 8 Quadratkilometer große Fläche sagen will, dann sollte man die entsprechenden Tags in das Multipolygon schreiben.
Man kann drüber streiten, ob – wenn wir das Beispiel mal als See mit Insel betrachten – man das natural=water an Way1 oder das Multipolygon schreiben sollte (ich denke, man sollte letzteres tun). Aber wir sollten uns darüber einig sein, dass natural=water an Way 1 über einen 9 Quadratkilometer großen See redet und natural=water als Tag des Multipolygons über einen 8 Quadratkilometer großen See redet. Das meine ich deshalb, weil es doch nicht sein kann, dass sich die Bedeutung von Tags in Way 1 ändert, ohne dass man Way 1 ändert … einfach nur dadurch, dass Way1 als outer in einem Multipolygon erwähnt wird. Sowas wäre widersinnig und inkompatibel zur der Zeit, als es noch keine Multipolygone gab.
Das wäre logisch, aber es entspricht leider nicht der historisch gewachsenen Definition der Relation - dass nämlich bei Multipolygonen mit einem einzigen outer-Member die Multipolygon-Tags statt an der Relation auch ohne Bedeutungsunterschied an diesem einen Member angebracht werden können.
Es heißt natürlich auch
aber diese Empfehlung wird zumindest meiner Beobachtung nach noch eher selten befolgt. Es ist aber durchaus anzustreben, dass man sich zunehmend daran hält.
Diesen Ansatz halte ich fuer ziemlich fehleranfaellig, da man nur schwer erkennen kann, was wo gilt.
Stattdessen wuerde ich zwei andere Varianten bevorzugen:
A) Man traegt einen way 3 ein, der vom Verlauf her mit way 1 identisch ist. Dann kann man way 1 als outer fuer das multipolygon benutzen und way 3 fuer die Gesamtflaeche. Das ist ein wenig klarer, aber auch nicht viel besser, weil genug Mapper auch mir uebereinander leigenden Wegen ihre Probleme haben.
Deutlich klarer finde ich deshalb:
B) Way 1, way 2 und multipolygon wie oben.
Will man etwas ueber die 8 Quadratkilometer große Fläche sagen, dann sollte man die entsprechenden Tags in das Multipolygon oder an way 1 schreiben, beide Varianten lassen sich in der Nutzung faktisch nicht unterscheiden.
Will man etwas über die kleine Fläche in der Mitte sagen, dann kommen entsprechende Tags in Way 2.
Will man etwas über die 9 Quadratkilometer große Fläche sagen, dann sollte man diese Tags bei way 1 UND bei way 2 eintragen. Denn die 9 Quadratkilometer Gesamtflaeche ergibt sich ganz einfach aus der Summe der beiden Einzelflaechen.
Wobei es ja auch durchaus Gruende fuer dieses Vorgehen gibt.
Zum einen ist da die Abwaertskompatibilitaet. Wenn eine Auswertung die Relation nicht erkennt, dann erkennt sie wenigstens die beiden Einzelpolygone, weiss allerdings nciht, in welchen Zusammenhang die stehen. Das Ergebniss wird zwar fehlerhaft sein (das Loch wird halt nicht erkannt), aber es ist immer noch besser, als wenn die grosse Flaeche komplett fehlen wuerde.
Zum anderen ist die aktuelle Loesung einfacher, wenn man nachtraeglich ein “Loch” in eine Flaeche eintraegen will. Man braucht das urspruengliche Polygon nicht zu veraendern, sondern traegt einfach das “Loch” als neues Polygon ein und stellt ueber die Relation den Zusammenhang her.
Noch schimmer waren da sicherlich die Anfaenge der multipolygone, als es statt inner- und outer-Eigenschaft auf die Richtung der Polygone drauf an kam. Oder als die inneren Polygone genauso markiert werden sollten wie die aeusseren (was sich uebrigens auesserst schlecht mit der von mir vorgeschlagenen Variante B vertraegt).
Zum Glueck sind diese Sachen aber nahezu ausgestorben. Ob das mit der Vermischung von Relations-Tags und Tags am outer-Polygon auch mal passieren wid, bin ich eher skeptisch. Im Moment muss man einfach das aktuell uebliche Vorgehen akzeptieren.
Na ja, die Richtung zu ignorieren ist eigentlich schlicht und einfach ein Fehler
Auf einer Kugeloberfläche kann man innen und außen nicht anhand der Linie unterscheiden. Wenn ich den Äquator als Begrenzungslinie nehme, habe ich dann die Nordhalbkugel oder die Südhalbkugel markiert?
Die jetzige Regelung fällt also wohl unter “praktisch brauchbarer Irrtum”.
Danke für die Antworten. Es war sehr lehrreich. Mein Eindruck ist, dass Multipolygone sehr konträr gesehen werden, unterschiedlich verwendet werden (können) und vielleicht auch noch nicht ausgereift sind. Ich denke, dass ich mich noch länger damit beschäftigen werde, um sie besser verstehen und einsetzen zu können.
Betrachte Multipolygone erst mal als Zusatzinformationen für Renderer und
andere Programme wie ineinander leigende Flächen dargestellt werden sollen.
Das vereinfacht das Modell im eigenen Kopf und lässt Zweifel, ob dadurch etwas
innenliegendes semantisch von aussenliegenden ausgeschlossen wird, erst
einmal aussen vor.
Ich hoffe es ist nicht der Eindruck entstanden, ich sei jetzt verwirrt und würde Multipolygone bleiben lassen. Im Gegenteil: Ich habe jetzt ein besseres Verständnis. Ich bin aber noch nicht zu einem abschließenden Ergebnis gekommen, sofern dies überhaupt je möglich ist. “Die Theorie von heute ist der Irrtum von morgen.”
Momentan neige ich zu der Ansicht von Edbert “Es geht um Geometrie, nicht um Semantik.” Geometrie ist eindeutig(er), Semantik ist vieldeutig(er) und somit mehr vom Betrachter abhängig. Konzentration oder Beschränkung auf die Geometrie erleichtert somit das Verständnis für Mapper und Renderer.
In meinem obigen Beispiel Park gibt es noch mehr innenliegende Flächen. Diese werde ich noch erfassen und eintragen. Und ich denke, Multipolygon ist zur Beschreibung der Geometrie dann besser. Einen weitaus komplexeren und lehrreicheren Fall eines Waldes habe ich inzwischen in dieser Diskussion gefunden Anfänger möchte sich an Multipolygon versuchen.
Genau das halte ich fuer den komplett falschen Vorschlag. Hier ist mal wieder einer der Faelle fuer den alten Spruch: “Wir mappen nicht fuer die Renderer”
Wenn einer ein Tag einzig und alleine dafur benutzt, damit das Renderer-Ergebnis besser aussieht, dann ist das ein gutes Zeichen dafuer, dass er was falsch macht.
Die Geometrie ergibt sich alleine aus den Koordinaten der Eckpunkte. Da hat die multipolygon-Relation ueberhaupt nichts mit zu tun. Wenn die Koordinaten des einen Polygons innerhalb der Koordinaten eines anderen Polygons liegen, so ist der geometrische Zusammenhang alleine dadfurch vollstaendig bestimmt. Von der Geometrie her ist es dann auch voellig egal, ob eines der Polygone als inner oder als outer bezeichnet wird, die Lage aendert sich dadurch ja nicht.
