endlich mal jemand der meine Meinung teilt 
Ich hoffe doch, dass wir alle das sowieso entspannt sehen. 
Mir war das ganze auch nur nebenbei aufgefallen. Ich hatte zu Anfang übrigens auch eingeschnittene Bäche mit layer=-1 bezeichnet, dann mal nachgeschaut. Da liefen gerade einige Diskussionen zu dem Thema, worauf wohl auch das WIKI ergänzt wurde. Wirklich tragisch ist es, wenn man das anders macht, nicht.
Es soll das potentielle Problem vermieden werden, dass ein Bach/Objekt mit layer=-1 unterhalb von einer Landfläche mit layer=0 liegt. Wenn z.B. ein Renderer nur das oberste Layer darstellen würde, würde der Bach dann auf einmal fehlen. Zur Zeit werden die Layerverhältnisse zwischen Linien und Flächen von den wichtigsten Renderern wohl gerade aufgrund derartiger Problem nicht berücksichtigt (wenn ich mich nicht irre, ich bin keiner der Programmierer). Falls sich das aber mal ändert… Außerdem sollte es z.B. für jemanden, der ein unterirdisches Objekt im Tunnel verlegt, einfacher werden. Er muss nicht mehr alle anderen dazwischenliegenden Objekte erst auf ihr Layer überprüfen, um dann ein noch tieferes zu vergeben.
Ansonsten, wir OSMler sind ja manchmal schon gemein zueinander. 
Nightdive nennt ein Beispiel und wir fallen erst einmal über ihn her, anstelle uns zu freuen. Und ich habe auch noch angefangen, sorry. 
Zusammengefasst noch mal zur eigentlichen Frage von nilix:
@nilix:
Nimm keine Layer für “Deinen” See, sondern ein Multipolygon. Normale Multipolygone sind auch gar nicht kompliziert, wenn man das ein paar mal gemacht hat. Zumindest in JOSM geht das doch recht zügig.
Und, falls Du in dem Wald neben dem See noch eine Wiese oder ähnliches hast, reicht es natürlich aus, für alle zusammen nur ein Multipolygon mit einem Außenrand (dem Wald) und mehreren Innenpolygonen (dem See, der Liegewiese am See, der Lichtung anderswo im gleichen Wald, …) zu erstellen.
Falls Dir Multipolygone zu kompliziert sind, würde ich trotzdem keine Layer nutzen, dann lieber alles weglassen, und den See einfach nur einzeichnen. Dann gehörst Du aber nur zu den “niederen Schichten” unter den Mappern. Mit Deinem ersten eigenen korrekten Multipolygon steigst Du automatisch zur Crème de la Crème auf. Den meisten sind die nämlich, warum auch immer, zu kompliziert.
Nach meinem Verständnis dient layer nur dazu, die Topologie sich überschneidender Ways am Schnittpunkt klarzustellen. Für Flächen hat es keine Bedeutung, auch wenn da jemand im Wiki was verschlimmbessert hat. Wäre auch keine gute Idee, da es zu großflächig verzahnten Abhängigkeiten führt.
Als Rendererprogrammierer kann ich Dir auch sagen, daß zumindest Mapnik-Renderer eine eigene Struktur von echten Zeichenebenen verwalten, die nach logischen Gesichtspunkten anhand der Haupttags zusammengestellt werden (z.B. alle Wasserwege in eine Ebene oder alle Landuse-Flächen, alle Autobahnen, alle Tunnel usw. ) und das layer-Attribut keinen Einfluß auf diese Aufteilung hat, sondern bestenfalls innerhalb gleichartiger Objekte in einer Ebene.
Meiner Auffassung nach nicht nur überschneidende Ways, sondern auch aufeinander liegende Areas und einen Way/Node einschließende Areas. Oder wie soll sonst eine “liegt über”-Beziehung zwischen diesen ausgedrückt werden?
Gar nicht. Die Dinge liegen nicht übereinander (da stehen keine Bäume im Wasser, da schwimmt keine Insel auf dem See und der Weg verläuft auch nicht oberhalb der Baumwipfel), sondern sind exklusiv nebeneinander. Dieses Verhältnis wird mit einem Multipolygon ausgedrückt. Es einfach “drüberzumalen” ist topologisch falsch.
Nur bei einem vektororientierten Zeichenprogramm würde drübermalen mit einer solchen layer-Reihenfolge Sinn machen. Aber OSM ist eine Datenbank. Die OSM Editoren und Renderer sind keine Malprogramme, ignorieren das komplett und zeichnen anhand einer logische Auswertung anderer Tags. Wenn das erwartete Ergebnis erscheint, ist das reiner Zufall.
Es geht mir um Flächen, bei denen die Dinge in der Realität übereinander liegen.
Beispiele:
Fußgängerplatz auf “Stelzen”, unter dem eine Straße mit Bushaltestelle und allem drum und dran verläuft.
Parkplatz auf Dach eines Getränkemarkts.
Es gibt jeweils Objekte, die unter/über einer Fläche liegen, ohne deren Rand zu schneiden. Trotzdem weiß keine andere Möglichkeit als layer, um das sinnvoll auszudrücken.
Für solche Konstellationen ist die Frage natürlich gültig, muß aber klar von der anfangs diskutierten See/Wald Problematik abgegrenzt werden. Du hattest es komplett allgemein formuliert, daher das Mißverständnis.
Ich weiß nicht, ob es für solche Fälle schon eine abgestimmte Lösung gibt. Beschreiben kann man es sinnvoll mit den layers, aber auswerten/rendern ist ein wesentlich schwierigeres Thema. Ich würde mal annehmen, daß es Zufall ist, ob solche Flächen sichtbar sind oder nicht, je nachdem ob der Renderer Parkplätze vor oder nach Getränkemärkten rendert.
Also ich denke wir sehen das schon entspannt, oder? Von übereinander herfallen kann m.E. auch keine Rede sein, sollte auf jeden Fall nicht so rüberkommen.
Das o.g. Beispiel hat natürlich dazu eingeladen diese Frage zu stellen.
Die deutsche Features Seite ist halt nur eine Übersetzung der englischen, im Zweifelsfall schau ich dort auch mal nach. Dort steht noch einiges mehr erklärt, auch bei Tunnel und Brücke…
Eine grundsätzliche Frage ist doch, ob man sich weiterhin an diese Vorschläge hält oder nicht? Wenn nicht, dann sollten wir dieses Forum abschalten.
Jeder macht was er denkt und wie es ihm gerade gefällt und nach kurzer Zeit werfen die Macher der Renderer das Handtuch weil es überhaupt keine Strukturen mehr gibt die sie den Proggis mitgeben können und das wars dann.
Natürlich sind die “Vorgaben” nicht in Stein gemeißelt und das ganze Projekt ist dynamisch. Aber Chaos sollte deshalb trotzdem nicht ausbrechen. Sehe ich das wirklich sooo viel zu eng?
Was wäre denn eine Alternative?
Georg
Du siehst das etwas zu eng in diesem Fall, finde ich zumindest.
Der Hauptzweck von Layer ist doch bei Elementen die man nicht logisch sortieren kann (2 Brücken übereinander) vorzugeben was oben und was unten ist. Die Information ob dies oberhalb der angenommen Grundfläche ist oder nicht finde ich weniger wichtig denn wir malen eine 2D Karte.
Ob der Threadersteller hier den See mit einem Multpolygon ausschneidet oder nicht ist z.b. nicht ganz so wichtig obwohl es in meinen Augen sinnvoll ist, aber ein layer Tag wäre nicht richtig weil hier physikalisch nichts übereinander liegt.
Es gibt sehr viele Bereiche in denen unterschiedliches mappen für richtig Probleme sorgt und darum sollte man sich primär kümmern.
BTW
Wie würdet ihr folgendes taggen:
Einen Teich der vielleicht 100m X 50m groß ist, sehr flach (0.5m-1m tief) wo alle 5m im Wasser ein Baum steht und das ganze befindet sich in einem Wald. Der Teich trocknet nur in extremen Sommern aus.
Das ganze gibt es wirklich…
Einen Wald, dazu eine Fläche mit natural=wetland. Die können sich überlagern.
moin,
haben wir schon Mangroven? 
duck & wech
jörk
Aha, also ein Stück “Bruchwald” (da stehendes Gewässer, zu unterscheiden vom “Auwald” am fließenden Gewässer)?
Ja, kann man so taggen, wie von Nop gesagt. Ich tagge solche Bruchwälder allerdings ohne überlagernde Waldfläche nur als natural=wetland + wetland=swamp. wetland=swamp bezeichnet direkt “waterlogged forests”, im Gegensatz z.B. zu wetland=marsh bei kleinerem Bewuchs (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwetland). Bei wetland gibt es tatsächlich intelligent ausgewählte, im WIKI gut unterschiedene Tags, welche die verschiedenen Typen von Feuchtgebieten abdecken.
Ach ja, die Mangroven: natural=wetland + wetland=mangrove
A propos Mangroven… Das war das Stichwort für einen Ausflug über den großen Teich, nach Florida. Es hat mich dann doch mal interessiert wie die Mapper dort drüben das handhaben.
Sie haben doch tatsächlich die Everglades (auch) als leisure=park gemappt 
Also ich verstehe unter Park etwas anderes und mir fallen nicht wirklich viele Leute ein, die ich in diesen Park schicken würde um einen erholsamen Spaziergang zu machen… 
Nationalpark ist ok, aber zusätzlich park ?
Das kennzeichen als area=yes in Verbindung mit leisure=park führt dort zu einer riesigen grünen Fläche die in den hohen Zoomstufen z.B. die Mangroven komplett überdeckt. 
Also auch hier eine “suboptimale” Darstellung…
Georg
Ich kram mal den Thread wieder raus.
folgendes Problem:
Es gibt einen Wald. In diesem Wald ist ein See und in diesem See ist eine Insel (mit Bäumen - Wald)
Und zwar genau hier: http://www.openstreetmap.org/?lat=50.84468&lon=12.94772&zoom=17
Hab an dem Wald jetzt meine ersten “Malübungen gemacht”.
- Den durch eine Straße zweigeteilten Wald mal zu einem zusammengefasst und die ganzen Seen auf multipolygon inner gesetzt sowie den Wald auf outer.
- Die Lichtung http://www.openstreetmap.org/?lat=50.84606&lon=12.96561&zoom=17 habe ich auch auf inner gesetzt.
Nun zeigt er aber in der Karte die Insel im See nicht mit an? Hab ihm deswegen jetzt erstmal layer=+1 gegeben. ist das korrekt?
Ausserdem wird die Lichtung scheinbar nicht als “Loch im Wald” angezeigt sondern von der Farbe als See? Hab ihm aber absichtlich keine Tags gegeben?
Hallo,
ich habe mal den layer und das natural:wood (landuse:forest solte reichen) entfernt.
Und jetzt die Lösung deines Problemes:
http://www.openstreetmap.org/browse/relation/229790/history
Keys in OSM werden im Regelfall klein geschrieben werden.
Dazu habe ich noch ein multipolygon für den Engelmannteich gebaut. See=outer Insel=inner.
Grüße
Ropino
Ich hätte die für die Insel im See kein eigenes Multipolygon gemacht. Die Insel ist ja bewaldet und somit eigentlich Teil des Waldes. Damit kann man sie einfach zum ersten Multipolygon hinzufügen und als “outer” taggen.
Das entspräche genau dem Beispielbild 7 von http://wiki.openstreetmap.org/wiki/Multipolygon. Würde ich so ändern.
lars
Das ist einer der Fälle, bei denen selbst ich mal die “softwarefreundlichere” Variante nehmen würde. Diese Advanced-multipolygon-Geschichte wurde schließlich ohne größere Diskussion auf die Seite geschmuggelt und ist verdammt schwierig zu implementieren. Also nicht beschweren, wenn es da noch auf Jahre hinaus Fehler gibt - das ist fast schon nicht mehr die Vermeidung von “Taggen für den Renderer”, das fällt unter “Taggen gegen den Renderer”.
Eigentlich kann man sich natürlich schon bei Multipolygonen selbst darum streiten, ob die wirklich die beste Idee waren, aber sei’s drum…
jetzt hab ichs nicht ganz verstanden … was ist denn die softwarefreundlicher variante? die mit nur einem multipolygon oder? also die insel wieder als outer?
Meiner Ansicht nach ist “softwarefreundlicher” eine Umsetzung, die pro Multipolygon nur 1 outer hat - weil das bis vor kurzem die einzig mögliche Variante war. Also alles, was oberhalb der Überschrift “Advanced Multipolygons” in der Dokumentation steht (mit Ausnahme der Zeile “none” in der Tabelle).
Im konkreten Fall lässt sich das umsetzen als ein eigenes Multipolygon für See&Insel mit outer=See und inner=Insel.
Das ist aber bis zu einem gewissen Grad Ansichtssache, also nicht verwirren lassen.
Liebe OSMer,
Flächen
Früher, als Karten noch auf Papier gezeichnet wurden, war das alles ganz einfach. 
Da hat man einfach den Kreis vom See blau angemalt, und den Wald drumherum grün.
Bei elektronischen Karten, die aus Geo-Daten erzeugt werden, ist das wesentlich komplexer…
Beispiel:
a) ein Polygon bezeichnet die Grenze von XY-Land
b) innerhalb der Grenze liegt ein Wald
c) innerhalb vom Wald liegt ein See
Nun könnte man folgende Fragen stellen:
- welche Gesamtfläche hat XY-Land?
- wie gross ist die Waldfläche von XY-Land?
- wie gross ist die Wasserfläche von XY-Land?
- wie gross ist das Grundstück des Waldbesitzers, dem auch der See gehört?
1 = a
2 = b - c
3 = c
4 = b
Damit man solche Fragen aus der Datenbank beantworten kann, müssen die Verhältnisse der Flächen zueinander (Relation bzw. Multipolygon) genau beschrieben weden.
Wenn man Polygone einfach “übereinander” legen, oder “sich gegenseitig schneidend” zeichnen würde, würden Informationen verloren gehen.
Höhen
Layer sind eine Krücke.
Layer für **Flächen **sind überholt. Sie wurden früher als Krücke benutzt, um Renderern zu sagen welche Fläche “oben” gezeichnet werden soll.
Layer für **Brücken **und **Tunnel **werden von intelligenten Renderern ebenfalls nicht mehr gebraucht (diese wissen, dass eine Brücke immer “oben drüber” und ein Tunnel immer “unten drunter” geht).
Heute werden Layer nur noch für komplexe Brückenkonstruktionen gebraucht, bei denen sich 3 oder mehr Strassen/Wege kreuzen,
und um in mehrgeschossigen Gebäuden mehrere Stockwerke zu unterscheiden (was aber nicht gerendert wird).
Und auch das wird irgendwann überflüssig sein, wenn wir die Höhe als dritte Dimension in OSM eingeführt haben.
Gruss, Markus