Es geht um areas mit gleichen Haupttags. Eine Fläche kann nicht gleichzeitig Wohngebiet (landuse=residential) und Gewerbegebiet (landuse=commercial) sein. Hier kann/muss/sollte ein MP genutzt werden. Allerdings kann innerhalb eines Wohngebiets eine Schule (amenity=school) liegen. Oder innerhalb eines Walds (landuse=forest) gibt es einen See (natural=water). Das sind dann keine Fälle für ein MP.
@ aixbrick
Thanks mate, ich habe sowas in der Richtung schon vermutet, konnte aber eine konkrete Aussage dazu nicht finden und iD lässt auch zumindest beim Bearbeiten z.B. landuse im landuse zu, ohne zu meckern. Vielleicht gibt’s ja beim Hochladen dann eine Fehlermeldung, das wollte ich allerdings nicht ausprobieren.
Die Lichtung oder der Tümpel im Wald sind Paradebeispiele für den sinnvollen Einsatz von Multipolygonen. Wo Bäume tatsächlich im Wasser/Letten stehen, das kann als Bruchwald sogar genauer deklariert werden, als durch die Überlagerung.
Vgl. https://wiki.openstreetmap.org/wiki/Relation:multipolygon - Anleitungen unter https://wiki.openstreetmap.org/wiki/Relation:multipolygon#How_to_map
generell gehen wir davon aus, dass es nur 1 landuse pro Fläche geben kann, zumindest “echte” landuse, weil manche landuse sind ja eigentlich landcover, so hat sich im Laufe der Zeit beispielsweise ergeben, dass landuse=forest eine von Bäumen beschattete Fläche ist, als kleinster gemeinsamer Nenner. Das schließt einerseits Forstflächen die gerade komplett abgeholzt wurden, von der Verwendung aus, und am anderen Extrem sind 4 Bäume bei entsprechendem Mikromapping bereits ein “landuse=forest” ohne dass es definitionsgemäß falsch wäre. So einen “forest” kann man durchaus im Garten einer Villa finden, so dass sich dann dort formal 2 landuse überlappen.
Was landuse=residential angeht liegt da vielerorts noch einiges im Argen, der tag wurde in erster Annäherung für komplette Siedlungen verwendet, und wird erst nach und nach weiter verfeinert. Grundsätzlich sollte eine Schule aber nicht innerhalb eines landuse=residential liegen, weil es sich nicht um Wohnnutzung handelt, genausowenig wie ein Park, ein Supermarkt, eine Tankstelle oder eine Kirche (obwohl das alles noch massenhaft vorkommt).
Wie bereits verschiedentlich erwähnt gibt es bei “Siedlungslanduse” ein bisschen Verwirrung, weil landuse einerseits für die Nutzung einer Fläche definiert ist und auch oft so verwendet wird, andererseits mancherorts aber auch für Siedlungsteile verwendet wird (Wohngebiet, Gewerbegebiet, Industriegebiet etc.), so dass dort zwangsläufig an sehr grobem Mapping festgehalten wird, und es zu Bereichen kommt, wo unzutreffender landuse gemappt ist (damit die Teile nicht aus dem Wohngebiet XY rausgenommen werden müssen, obwohl dort keine Wohnnutzung ist). Meine bevorzugte Lösung ist hier “place” zu verwenden (neighbourhood, quarter, suburb, je nachdem). Welcher landuse dann dort vorherrscht, ob es also ein Wohngebiet oder Gewerbegebiet ist, das ergibt sich aus den landuses Objekten darin.
@ dieterdreist
Danke für Deine Erläuterungen zum Landuse, aber das ist eigentlich eine andere Baustelle. Meine Frage geht weniger in Richtung korrekte Verwendung von Landuse als vielmehr Notwendigkeit von MPs. Nicht, dass ich irgend etwas gegen MPs hätte (es sei denn, es sind landuse-Monster mit 1000enden von Nodes, die quadratkilometergroße Flächen abdecken), ich habe nur bisher nicht verstanden, ob es irgend eine Mappingaufgabe gibt, die zwingend ein MP erfordert.
Es hieß ja hier im Topic bereits, dass die Riesenflächen niemand mehr bearbeiten kann und dass es wesentlich sinnvoller ist, diese in überschaubare Teilflächen zu zerlegen. Dem schließe ich mich an. Also ein Grund weniger, ein MP anzulegen.
Einfache Flächen mit “Loch” drin lassen sich ebenfalls mit areas ohne MP-Zuordnung mappen. Ich habe z.B. schon Flächen mit landuse=grass/meadow/farmland gefunden, die mitten in einer umgebenden Fläche mit landuse=residential liegen, also “Löcher” in der residential-Fläche darstellen. Das scheint kein Problem zu sein, die Flächen werden in der Hauptkarte auch korrekt gerendert. Genauso wie die bereits angeführten Flächen mit amenity=* oder leisure=* etc., die ebenfalls problemlos als area in eine umgebende landuse-area eingebettet werden können.
Wenn das aber alles mit areas ohne MP funktioniert, wozu sind MPs dann letztendlich noch erforderlich oder gar zwingend notwendig? Vielleicht sehe ich ja den Wald vor lauter Bäumen nicht mehr, aber manchmal blickt man’s halt einfach nicht. Daher fände ich es gut, wenn mir jemand hier auf die Sprünge helfen könnte.
Es funktioniert hie und da rein zufällig ohne MPs.
Wenn ich eine Insel im Wasser habe, dann ist mir und Dir und vielleicht auch dem der die Renderregeln erstellt, klar, dass da eine Insel “im” Wasser ist.
Das Selbe bei 'nem Teich im Wald, nur anders rum.
Die Daten wissen das aber nicht. Die kennen keine Teiche oder Bäume oder Inseln und wie diese miteinander konkurrieren oder was oben unten oder ausserhalb ist.
Kommt ein anderer Renderer daher und bedenkt solche Spezialfälle nicht, dann stehen - wie bspw. “in der Hauptkarte” - Bäume im Teich. Dann nimmt man eben MPs und muss nicht jedem einzelnen Renderer nachlaufen und dem erklären, dass Bäume nicht im Teich stehen.
… oder anders formuliert
man kann sich auf den Standpunkt stellen “Ein Teich im Wald muss halt nur über den Wald gerendert werden und gut ist”
mit dieser scheinbar neheliegenden Render-Regel würde eine baumbestandene Insel (und daher als Wald erfasste) in einem Teich/See aber buchstäblich “untergehen”.
abgesehen vom Rendern will man die Daten eigentlich so haben, dass das was als x getaggt ist auch x ist, und nicht dass man davon noch y und z abziehen muss, weil sie geometrisch “darüberliegen”. Multipolygone braucht man immer dann, wenn man ein Loch reinschneiden muss, oder wenn man ein Objekt mappen will, das aus mehreren Flächen besteht die voneinander getrennt sind. Oder wenn die Grenze oder ein Teil der Grenze ein bestimmtes Objekt sein soll, und nicht nur “zufällig momentan” an derselben Stelle liegen.
Man muss aber auch bedenken: landuse heißt zunächst nur Landnutzung. Im Falle von landuse=forest: Die (vorwiegende) Landnutzung ist Wald, d.h. aber nicht automatisch, dass dort überall Bäume stehen, auch wenn der Renderer das so darstellt. Ein Teich kann ein Teil des Walds sein. Ab einer gewissen Größe sollte er natürlich “allein” stehen, aber kleinere Teiche können m.E. auf dem landuse liegen.
Genauso bei Schulen: Ich versuche zwar auch, ein landuse um die Schulfläche herumzuführen. Wenn das aber nicht geht oder ich dafür extra ein MP erstellen müsste, lasse ich die Fläche einfach auf dem landuse liegen. Die Schule befindet sich nun mal in einem Gebiet mit der (vorwiegenden) Landnutzung Wohnen.
Soweit ich an den umliegenden Orten erkenne kann, ist das der Normalfall … amenities wie Kindergärten und Schulen, aber auch leisure areas wie Parks und Sportanlagen liegen überwiegen innerhalb der residential areas ohne als MP eingebunden zu sein. Dazu heisst es im Wiki:
Das liest sich für mich so, dass eine amenity auch ohne MP in die landuse-area eingebettet werden kann. Und da alle diese Flächen korrekt gerendert werden, sieht das für mich auch nicht nach einem zufälligen Ergebnis aus.
Davon abgesehen entspricht das auch der Realität, da Schulen, Kindergärten, Parkplätze und Parkanlagen normalerweise in den als Wohngebiet ausgewiesenen Flächen liegen, auch wenn diese Einrichtungen selber nicht bewohnt werden, aber das hat natürlich nichts damit zu tun, ob für die Erfassung dann areas oder MPs verwendet werden.
Aber nochmals: Ich habe kein Problem damit, für Flächen von “landuse in landuse” überschaubare MPs zu erzeugen, mir geht es nur um das Verständnis der Notwendigkeit.
OSM-Carto bedient sich dazu einer, ich würde es “Heuristik” nennen: Wenn zwei einfache Polygone (geschlossene Wege, die von den Tags her eine Fläche deklarieren) sich überschneiden, dann wird die kleinere als die “obere” angenommen, d.h. bestimmend für die Farbe, in der gemalt wird. Bei “unten” liegenden Flächen, d.h. den von der Ausdehnung her größeren, die zusätzlich mit Mustern gefüllt werden, wird dieses dann noch über die Farbe der kleineren “obere” Fläche gelegt. Keine Ahnung, wie das ausgeht, wenn drei oder vier Flächen übereinanderliegen.
Das kann gut gehen, das kann auch daneben gehen. Man kann damit z.B. eine Streuobstwiese malen, die manchen vielleicht schöner anmutet als wenn als “orchard” getaggt, obwohl sicher andere das für korrekter ansehen. Man kann damit einen Sumpf ununterscheidbar von einem getaggten “swamp” malen. Komisch sieht es aus wenn Bäume im Beton stehen (auf residential grau).
Es gibt Bestrebungen für Mehrfach-landuses. Die Verwaltung kennt ja auch Mischgebiete. Keine Ahnung, ob so was für natural etc. auch angedacht ist.
OK, ich denke, ich verstehe das Problem beim Rendern jetzt: Wenn die umliegende area mit icons gefüllt ist (wie z.B. “forest” oder “scrub”), dann wird ein darin befindliches “Loch” wie ein See oder eine Wiese zwar in der richtigen Farbe gerendert, aber die Fläche wird trotzdem mit den icons gefüllt.
Im Falle von Flächen, die in residential areas liegen, sieht man den Fehler nicht, da landuse=residential nicht mit icons gefüllt, sondern nur farblich abgesetzt ist.
Interessantes Phänomen - der Renderer erkennt zwar die Form und Art der Fläche des “Lochs”, schafft es aber nicht, die icons der übergeordneten Area wegzufiltern.
Damit ist meine Frage aber beantwortet. Danke nochmals für alle konstruktiven Hinweise dazu.
@ Hungerburg
Ja, genau das ist mir gerade an einer entsprechenden Kombination von Flächen aufgefallen … war gerade noch am formulieren, als Dein Beitrag reinkam. Damit ist klar, warum in solchen Fällen MPs notwendig sind, zumindest so lange, bis die Renderer das auch ohne klar trennen können. 
Letztendlich ist das ein meines Erachtens auch mittels Multipolygonen nicht lösbares Problem: Man stelle sich vor, eine Schule im Grünen mit grünem Pausenhof. Als einfache Polygone erfasst sieht es in OSM-Carto gut aus, die Heuristik trifft den Nagel auf den Kopf, drei sich überlagernde Polygone rendern korrekt: Wiese über Schule über Wiese. So weit so gut. Der “Namensraum” (landuse, natural, amenity, leisure etc. die sogenannten top-level tags) spielt da keine Rolle. Kann man mit Multipolygonen auch korrekt rendern machen, aber, der Schulhof gehört zur Schule!
Das ist kein Versehen, das ist Absicht: Die Fläche ist mehrfach definiert, OSM-Carto zeigt richtigerweise an, dass dem so ist. Kein Algorithmus der Welt kann entscheiden welche der Deklarationen gilt.
Noch mal zur Ausgangsfrage…
Beispiele…
Was ist der Unterschied zwischen:
https://www.openstreetmap.org/way/274568891
https://www.openstreetmap.org/relation/13627824
https://www.openstreetmap.org/relation/13627823
https://www.openstreetmap.org/way/274568881
Na? Wer kommt drauf? Es gibt keinen…!!!
Die einen Angaben am Way und der einen Relation sind seamark-typische Ergänzungen… ansonsten sind es mir nicht erklärbare und unnütze Dopplungen, gepaart mit dem anscheinend immernoch vorhandenen iD-Fehler, an Stellen, wo Linien mit geschlossenen Ways verbunden sind, diese ways gesplittet und in Relationen gewandelt werden. Unabhängig davon, sollte man mit iD nie und nimmermals solche Relationen anfassen…
Sowas kommt aber auch davon, daß vielleicht gewisse Editoren (menschlich/ und Anwendungen!) sich nicht an Standards halten… anders kann ich es mir nicht erklären…
Ich werde morgen den betreffenden Bereich entrelationieren.
Sowas ist für mich zu 100% unnötig und verkompliziert den Datenbestand.
Sven
…der mal wieder im Relationsputzmodus ist…
Edit: Pah… noch eine vierte Geometrie in dem Zusammenhang gefunden… Och man… 
Was “vorwiegend” ist, ist imho uninteressant wenn man das Problem vom Datenmodell her betrachtet.
Vorwiegend heisst (ich schrieb das oben schon im Ansatz), dass ein Renderer ein paar Dutzend Spezialregeln und Spezialspezialregeln implementieren muss, statt stumpf eindeutige inner-outer-MPs zu malen.
P.s. Weils immer wieder kommt: OSM-Carto und/oder osm.org ist keine Referenz für Rendering. Es ist nur EINE Referenz, wie man etwas falsch oder richtig, schön oder weniger schön machen kann.
das Rendering kann nicht als Maßstab genommen werden ob die Repräsentation der Realität in der Datenbank ok ist. Beim Rendern ist die Reihenfolge unterschiedlicher Objektklassengruppen fest vorgegeben (layers, deren Inhalt anhand von tags aus einer Datenbank geholt wird). Innerhalb eines layers (z.B. landuse und bestimmte natural Objekte) wird die Reihenfolge über layer tags und über die Flächengröße bestimmt (kleiner liegt höher). Deshalb kann carto bestimmte Sachverhalte auch nicht richtig darstellen obwohl die layertags richtig gesetzt sind.
erledigt…
Fazit für mich ist (schon lange):
Solches massives Relationsmapping muß für mich gerade in dicht erfassten Gebieten als veraltet gelten! Das muß immer in separate Geometrien aufgelöst werden, so es denn geht (technische Grenzen)! Sonst meißelt man ein bestimmtes Taggning auf Gedeih und Verderb fest, was dann lange Zeit keiner mehr anfasst…
Es war ein Heidenaufwand, das alles aufzudröseln… Es gab z.B. eine (!!) Relation mit landuse=residential in der alle (!!) Landuse-beteiligten Liniensegmente gesammelt wurden, ob nun simple Linien oder welche mit highway=*… Egal alles rin… Also irgendwie eine Sammelrelation für Sammelrelationen, für die keine Relation nötig ist. Ähnlich war es mit natural=wetland, landuse=grass…
Übrigens dem user geopard ist es z.B. zu verdanken, daß die Königsbrücker Heide https://www.openstreetmap.org/relation/77659 auch entsprechend entrelationiert wurde… Ok… das Ding ist immernoch groß und hat viele Elemente, Es ist aber erst mal im Rahmen der Ausdehnung des Gebietes hinreichend vereindacht…
Sven
Nur weil es ein Renderer wie erwünscht darstellt, ist es kein richtiges Mapping. Bei manchen landuse-Tags ist es vielleicht schwammiger oder weniger wichtig, ob man innere Flächen als Löcher oder als überlappend ansieht.
Aber ein ringförmiges Gebäude (Beispiel: https://www.openstreetmap.org/relation/9398337) hat nun mal einfach ein Loch. Selbst wenn in der Mitte nur eine runde Grasfläche wäre und ich die eintrage, wäre es nicht ersichtlich, dass das Gebäude ringförmig ist und nicht einfach rund mit Gras auf dem Dach. Ein MP ist hier zwingend erforderlich.
Genauso mappe ich einen L-förmigen Parkplatz nicht als Rechteck, weil über einer Ecke eine Grasfläche liegt und es so in einem Renderer trotzdem zufällig richtig aussieht.
Das würde ich so explizit nicht sagen, es hängt m.E. von dem vorgegebenen Regelwerk ab. Wenn grundsätzlich gilt, dass eine kleine Area innerhalb einer großen Area als “Loch” anzusehen ist, in dem die Attribute der großen Area keine Gültigkeit haben, dürfte es kein besonderes Problem sein, das entsprechend auszuwerten bzw. darzustellen.
Wenn das Regelwerk allerdings offen lässt, ob die kleine Area ein Loch in die größere stanzt oder aber oben drauf liegt, wie ggf. hier
dann brauche ich natürlich eine Funktion, um das kenntlich zu machen. Dann wäre die Regel also
Ohne MP liegt die kleine Area auf der großen Area, mit MP stanzt die kleine ein Loch in die große.
Könnte man das so ausdrücken?