Multipolygone, z.B. See oder Gebäude in Waldfläche

Bisher habe ich, falls ein See, Teich, Sportplatz oder Gebäude kartiert habe, diese nicht las Multipolygone eingetragen. Da ich nun eher mit JOSM arbeite, bin ich beim Lesen des JOSM-wiki nun darauf gestoßen. Zum Verständnis, wenn das äußere Polygon die Waldfläche ist und der See das innere, dann ist der Rand des Waldes meistens kilometerweit entfernt…

hi wegabschneider,

ja und? wälder sind gross und seen sind klein :wink:

das sollte kein problem sein - und wenn, dann nur eines mancher renderer. (omm…)
ich mach das auch bei z.b. gewerbegebieten oder parks innerhalb von staedten (landuse=residential); ist wesentlich sauberer als diese blöde “flaschenhalsmethode”.

ach ja: multipolygone bei gebäuden sind NUR dafür gedacht, wenn diese buildings “löcher” haben.

gruss

wambacher

Nun hab ich mir ein Filmchen angeschaut, wie das mit den Multipolygonen gemacht wird. Aber am eigenen Beispiel erkenn ich das besser.

Konkret geht es um diesen Fall:

http://www.openstreetmap.org/browse/way/60025797

Kann mir jemand ein Beispiel zeigen, bei bem es sich ähnlich “einfach” verhält, damit ich mir das anschauen kann. Das mit den Multipolygonen wird in nicht wengien Fällen nicht gemacht. Teiche und Seen werden, wie mir scheint öfter ‘auf’ Waldflächen gelegt.

Kein Wald mit See, aber ein See mit mehreren Inseln .

Schau Dir die Seen jetzt mal an.
Man muß sie in die richtige Relation einbinden und auf die Drehrichtung (innen / links = gegen den Uhrzeigersinn) des Polygons achten. Ich mach das immer mit Potlach.

Das Problem ist halt, daß man beim Rendern der Karte später unter Umständen nur noch Löcher sieht.
Legt man die Flächen ohne Multipolygonfunktion übereinander, bleiben sie in den meisten Fällen sichtbar.

Zu Absatz 1:
Die Drehrichtung ist völlig belanglos.
Es müssen nur in Summe geschlossene Wege sein.
(Ansonsten wären es keine Flächen.)

Zu Absatz 2:
Die Renderer haben halt dazugelernt. Wo die Renderer oft noch
versagen ist bei Situationen wie leisuere innerhalb leisure,
landuse innerhalb landuse oder natural innerhalb natural.

Edbert (EvanE)

Ich habe es nach der Anleitung im wiki (DE:Relation:multipolygon) mit JOSM nur erst mal für den größeren Teich gemacht. Wenn das jemand prüft wäre gut.

zu 1
Hmmm. Dass der Weg zu einer Fläche geschlossen sein muß, ist schon klar. Aber daß die Drehrichtung belanglos ist, ist mir neu. In der Anleitung wird darauf noch hingewiesen:
http://wiki.openstreetmap.org/wiki/DE:Relation:multipolygon#Potlatch

zu 2
Aha. Da bin ich mal gespannt, wann die das auch können. Ich hab nämlich so einige Löcher in der Karte. :wink:

tippeltappel

In englischen Wiki steht sogar, dass die Richtung jedes einzelnen Weges belanglos ist: “The direction of the ways does not matter.”, Relation:multipolygon#Usage. Anders würde es auch nicht funktionieren, da ein einzelner Weg, der ja eine bestimmte Richtung hat, Mitglied von mehreren Multipolygonen sein kann, in denen er wahrscheinlich unterschiedliche Richtungen haben müsste.

Die Richtung spielt schon seit längerem keine Rolle mehr - zum Glück…
Ein Beispiel:
-Aussenpolygon: Wald (Uhrzeigersinn)
-Innenpolygon: See (Gegenuhrzeigersinn)… kann aber gleichzeitig Aussenpolygon sein.
-Innenpolygon im See: Insel (Uhrzeigersinn)

Schon nur bei diesem einfachen Beispiel sieht man, dass es unmöglich ist, ein Aussenpolygon immer nur im Uhrzeigersinn und ein Innenpolygon nur im Gegenuhrzeigersinn zu erstellen.

Hallo tippeltappel

Auch das OSM-Wiki unterliegt dem Problem, dass es dort veraltete Informationen gibt. :wink:
Weiter oben steht in Anmerkungen Punkt 2: Die Richtung der Linien spielt keine Rolle.

Als erster Punkt wird erwähnt, dass outer oder inner auch aus mehreren Wegstücken
zusammengesetzt sein dürfen.
Eine Begrenzungslinie kann aus mehreren Teillinien “zusammengestückelt” werden,
solange die Linien in ihrer Gesamtheit einen geschlossenen Ring bilden.

Der beste Weg ist in der Tat Multipolygone zu verwenden.
Damit wird das Verhältnis von Flächen in Flächen beschrieben.

Es ist dabei unerheblich, ob die Flächen-Typen sich gegenseitig ausschliessen
(See in Wald) oder die innere spezifischer ist als die äussere (Fußballfeld im Stadium).

Edbert (EvanE)

Ja, ich denke auch, daß die Verwendung der Multipolygone letztendlich die sauberste Methode ist, die Verhältnisse der Flächen zueinander darzustellen. Da kann man trotz der ärgerlichen Löcher keine Rücksicht auf die Renderer nehmen. Wer einmal vor dem Problem gestanden hat, Renderregeln für eine Karte zu erstellen, in der gleichartige Flächentypen völlig unterschiedlich übereinander gestapelt werden, der weiß dieses System zu schätzen.

Beispiele:

(1)
kleines Gewässer
^
Lichtung
^
Wald
^
Insel
^
großes Gewässer

wurden beide Gewässer mit demselben Tag versehen, liegt bei der Stapelmethode das kleine Gewässer entweder mit dem großen Gewässer zusammen unter Insel und Wald, oder beides liegt oben.

(2)
Lichtung
^
Wald

und auf derselben Karte

kleine Waldstücke
^
ausgedehnte Wiesenflächen

Solche Situationen sind mit “Stapelregeln” nicht in den Griff zu bekommen, wenn dieselben Kartenobjekte in verschiedenen Ebenen auftauchen bzw. in verschiedenen Folgen gestapelt werden sollen. Egal, was man macht, irgendein kleines Polygon wird unter einem großen verschwinden.

Mit Multipolygonen ist es dagegen einfach. Die Inner-Konturen stanzen gewissermaßen Löcher in das Outer-Element. Innerhalb dieser Löcher legt man dann paßgenaue Puzzlesteine, indem man für die Inner-Kontur eine Flächen-Definition vergibt. Da man für die Inner-Kontur gleichzeitig eine zweite Relation definieren darf, die dieses Element als Outer-Kontur interpretiert, kann man auch in diese Fläche wieder mit Hilfe von Inner-Konturen Löcher schneiden, in die dann ebenfalls Puzzlesteine gesetzt werden.

So jedenfalls habe ich das System verstanden. Korrigiert mich bitte, wenn ich falsch liege.

Gruß
tippeltappel

Ich kenne keinerlei Probleme bei der Kombination gleichartiger Flächentypen (landuse in landuse, natural in natural, …) in Multipolygonen. Mal bitte ein Beispiel für ein derartiges Problem.

Das einzige mir bekannte, was nicht funktioniert, ist etwas wie landuse=forest in landuse=forest. Dann wird innen ein Loch ausgeschnitten. Das ist aber wohl eher ein Fallback-Mechanismus, um das allererste veraltete Multipolygonkonzept von OSM zu berücksichtigen, wo Innen- und Außenrand noch gleich getaggt wurden (Da wurden Innen- und Außenpolygon über die Drehrichtung unterschieden).

Die OpenCycleMap bleibt natürlich außen vor.

Hallo, die mapnik Karte schaut im Bereich des Teichs großräumig nun blau aus. Hat das was mit meinen Änderungen zu tun? Das sehe ich zum ersten Mal.

Ist richtig, mit Advanced Multipolygonen geht es noch einfacher, das wird aber nur von wenigen Renderern
unterstützt.

Siehe Fig.7 in:

http://wiki.openstreetmap.org/wiki/Multipolygon#Advanced_multipolygons

EDIT: Sehe gerade, dass das Beispiel nicht ganz passt. Falls die mittlere Fläche keine “Lochfläche” ist, benötigt man
wohl wieder 2 Multipolygone.

Chris

Hallo Ebbe

Das ist wohl ein Missverständnis. Ich meinte Situationen in denen die üblichen
Renderer auch ohne Multipoligone mit Flächen in Flächen klar kommen.

Warum einiges auch ohne Multipolygone funktioniert, liegt an der Reihenfolge
in der verschiedene Objektarten gerendert werden.

  • Häuser werden nach (=über) Landnutzung gerendert.
  • Straßen werden nach Landnutzung und Häusern gerendert.
    Deswegen braucht es ein Multipolygon wenn ein Haus (z.B. Kirche)
    innerhalb einer Fußgängerzone (=Straße) steht.

Was meistens nicht geht, sind einzelne Sportplätze (leisure=pitch) innerhalb
eines Sportgeländes (leisure=sport_centre). Da braucht es Multipolygone,
damit die Renderer die Zusammenhänge erkennen können.

Macht ja im Prinzip wenig Sinn, es sei denn die innere Fläche hat einen
eigenen Namen oder andere abweichende Eigenschaften wie Baumart.
Aber dann sind Innen und Aussen auch unterschiedlich getaggt.

Es gibt noch eine Situation, wo die Renderer mit advanced Multipolygonen
nicht klar kommen: (Wald (See (Insel=Wald)))
Den Wald auf der Insel darf man bei advanced Multipolygonen im Prinzip
wieder als outer mappen. Das raffen die Renderer aber bisher nicht.

Das kann man allerdings mit zwei geschachtelten Multipolygonen
problemlos darstellen.

Tja, leider.

Edbert (EvanE)

Stimmt, für Häuser und Straßen verwende ich (und die meisten anderen Multipolygon-Mapper, oder nicht?) normalerweise keine Multipolygone. In solchen Fällen braucht man auch dort welche.

Etwas spät, aber vielleicht ist das http://www.openstreetmap.de/karte.html?lon=8.61138&lat=49.99501&zoom=16&layers=0B0FT ein Beispiel für so ein Problem. Es geht um das Gebiet, welches durch einen Rahmen mit dem Text “Ehemaliges Munitionsdepot und Pilzzucht” bezeichnet ist. In diesem Gebiet sollte es keine Löcher geben, d.h. keine grauen Flächen. Diese grauen Flächen enthalten Wald.

Egal, ob ich das falsch verstehe, es falsch ist, es ein Beispiel für so ein Problem ist oder nicht, die Karte bildet die Realität nicht ab und es wäre schön, wenn das korrigiert werden könnte – ich weiß nicht, wie es geht.

Erste Erkenntnis auf die Schnelle:
Osmarender stellt den Wald dar, sogar unterschiedliche Arten.
Mapnik nicht.

Mal was grundsaetzliches zu Multipolygonen:

Eine Multipolygon-Relation drueckt aus, dass die inneren Bereiche nicht zu der Gesammtflaeche gehoeren. Es geht dabei nicht darum, die Anzeige beim Renderer huebscher zu machen!!!

Wer also ein Spielfeld per Multipolygon aus dem Stadium ausschneidet, der traegt Muell in die Datenbank ein. Genauso gehoert z.B. auch ein Haus zur Gesamtflaeche Wohngebiet. Umgekehrt gehoert eine Insel aber definitiv nicht zur Wasserflaeche.

Die Frage, ob Multipolygon oder nicht, sollte nicht anhand des Renderer-Ergebnisses entschieden werden sondern immer Anhand des logischen Zusammenhangs zwischen Innerem und Aeusserem. Denn es gibt ja noch andere Anwendungsmoeglichkeiten ausser den Renderern, und die wuerden sonst einfach nur schrott leiefrn, ob wohl doch alles “gut aussieht”.
Es sollte also vollkommen egal sein, ob die “üblichen Renderer auch ohne Multipoligone mit Flächen in Flächen klar kommen”. Wir taggen ja NICHT NUR fuer die Renderer, sondern wollen shcon moeglichst richtige Daten in der Datenbank haben.

Gruss
Torsten