Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

Ich glaube, dass Ihr aneinander vorbeiredet. Mammi71 hatte da vielleicht eher Wälder oder Farmlands vor Augen, wo auch eine Secondary ein geeigneter Anlass sein kann, Flächen aufzuteilen und handhabbar zu machen - und darum geht es doch hier. Ob ein kleines Dorf-Residential über eine Secondary drübergezogen wird oder an der Straße getrennt wird, ist mir ehrlich gesagt total egal, solange die Residentials nicht mit der Straße verklebt werden.

Wäre das nicht ein Fall für type=site ?

Dann ist dieses Beispiel

wohl eher ungeeignet?

Die Turnhalle ist aber kein Campus, den man eigens taggen könnte, wie es bei Universitäten der Fall ist.

Ich sehe da 2 “räumlich getrennte” Flächen, die durch eine Relationen zusammengefaßt wurden. Wenn das so korrekt ist, wäre das für mich eine Relation type=site.
Oder wie ist

zu verstehen?

Nicht nach dem Proposal:

Da wird sogar die Anwendung von MPs mit mehreren outer-Ringen angeordnet („should be used“, in rechtlichen Texten mit „ist/sind zu verwenden“ zu übersetzen).

–ks

type=site wird nicht gerendert. Folglich würde das gesamte Schulgelände einfach verschwinden, da man die Turnhalle nicht eigens mit amenity=school taggen kann; die Turnhalle ist keine Schule.

+1 wobei ich auch bei Straßen kleiner als secondary teile…

Macht man das nicht, würde ich im meiner Brandenburgischen Waldsteppe wieder zu Groß-MP’s kommen. Das Problem mit Bahnlinien ect. ist aber eher, daß es sehr oft MP-Fragmente von Erfassungen sind, die mehr als 7-8 Jahre zurückreichen und an deren Teilung sich bisher einfach keiner rangesetzt hat… Das MP in der Uckermark z.B.: https://www.openstreetmap.org/relation/78817 bewerte ich als ein solches. Solange die stabil sind, gibt es zwar keine Not, diese zu teilen, aber mindestens an der Autobahn und der Bahnstrecke kann man das mal gelegentlich teilen. Bei einer detaillierteren Erfassung des Melzower Forstes bleibe es wegen Mooren in Seen trotzdem bei einer sehr hohen Zahl an Inner-Elementen.

Sven

Das ist wieder mal eine Logik die sich mir nicht erschliest!
Und die unterschiedlichen Versionen in Englisch und Deutsch nerven mich auch immer mehr. Da können wir ja gleich auf die Deutsche Version verzichten.

Und was ist mit der Regel “Wir taggen nicht für den Renderer” ?

Wie soll ein Anfänger da durchblicken ?

[überspitzte Formulierung auf Mod-Bitte entfernt]
In diesem Thread geht es um unnötige, kaum wartbare große Multipoligone. Bei Deinem Beispiel gibt es gar kein MP, auch kein kleines, noch nicht einmal ein größeres kaum überblickbares normales Polygon. Hier gibt es nichts, was nach den hier diskutierten Empfehlungen aufzudröseln und kleinteiliger zu mappen wäre. Alles gut.
Das war leider ein missglückter Versuch, etwas zu entgegnen, wo es nichts zu entgegnen gab.

Unabhängig vom ungeeigneten Beispiel: auch eine primary kann eine schmale OD haben. Mensch, flexibilisiert doch einfach mal Euer Hirn. Keiner sprach davon, dass man ab Straßenklasse x auftrennen muss. Umgekehrt wird ein Schuh draus: wenn man aus anderen Gründen auftrennen muss, kann man dies sinnvoll entlang von vorhandenen Straßen tun. Dabei kann man im Einzelfall anhand der örtlichen Situation entscheiden, ob es sinnvoller ist, ein landuse entlang einer Straße aufzuteilen oder doch einfach drüber weg zu führen. Selbstverständlich stets ohne Linien und Flächen miteinander zu verkleben.

Der Mammi

[Mod Hut auf]

Damit der Umgangston hier nicht weiter leidet: Entferne die Beleidiung mit “kleingeistiger Engstirnigkeit” umgehend.

[Mod Hut ab]

Kann sich mal jemand diese MPs ansehen?
http://overpass-turbo.eu/s/E1W
rechterhand nördlich der sundischen Wiese habe ich verbrochen, wüsste aber nicht wo es noch zu unterteilen ginge. Ist halt ein großes Feuchtgebiet mit vielen offenen Wasserflächen drin. Verbesserungsvorschläge willkommen.
mittig die Kirr wird wohl gleichermaßen kaum besser gehen …
linkerhand der Darßer Urwald (eigentlich nur Darßer Wald oder Darßwald, “Urwald” wird hin und wieder verwendet, ist es aber nicht wirklich …) Hier wollte ich mal anfangen, einige Riegen (feuchte Niederungen zwischen den Dünenwällen) mit oft Erlenbruchwäldern zu mappen. Dabei hatte ich mir das MP erst mal zerschossen und mühsam wieder repariert. Ich hätte es gern in kleineren Häppchen, dann trau ich mich vielleicht wieder an die Riegen ran.

der derzeitige Stand schlägt vor, nur noch Multipolygone mit einem outer way zu empfehlen (bzw. von mehreren outer ways abzuraten), m.E. ist das übertrieben. Einen outer Ring halte ich für sinnvoll als Beschränkung, aber ob der aus einem oder mehreren outer ways besteht ändert nichts an der Übersichtlichkeit, und MPs sind normalerweise einfacher zu bearbeiten als mehrfache übereinandergestapelte ways. Bei letzteren kommt es in der Folge leicht zu falschen (bzw. unvollständigen) Verbindungen.

Auch bei den anderen Punkten gibt es aus meiner Sicht noch Überarbeitungsbedarf:

Der Punkt 3. ist nicht nachvollziehbar dargestellt, wieso sollte das OK sein bei in der Nähe liegenden Teilen und nicht mehr bei weiter entfernten Teilen? Entweder es gibt eine Lösung dafür ohne MP, dann macht es kaum Sinn, die nur teilweise zu implementieren, oder es gibt keine Alternative, dann ist das Abraten davon auch schwierig.

zu 4. “Absolut unerwünscht sind „MP-Teppiche“, bei denen nur die Grenzlinien von Flächen eingezeichnet und dann zu Outer-Ringen zusammengestellt werden. Diese Konstrukte sind für spätere Mapper kaum zu durchschauen und zu bearbeiten.”

Übertriebene Bewertung m.E., wer iD benutzt dürfte nicht mal den Unterschied von verklebten Flächen und solchen mit MP bemerken, für viele andere Editoren, z.B. JOSM oder GoMap!!, gilt: den way selektieren und alle darauf aufbauenden Flächen werden bequem aufgelistet. Im Gegensatz zu übereinandergeklebten Flächen, da muss man erst komplizierte Tastenkombinationen ausführen, um überhaupt an die unteren Flächen zu gelangen. Die Komplexität, die durch das Mappen von “Objekten” entsteht (ein Objekt ein OSM Objekt, z.B. Museumsgebäude und Museuminstitution(en) darin), ist sowohl bei Multipolygonen als auch bei Überlappungen da. Die Relationen sind einfacher für den Mapper, die Überlappungen für Computer und die Leute die die Daten importieren oder weiterverarbeiten (weil Relationen einen “Extradurchgang” erfordern, normalerweise)

zu 5. “Nur Flächen dürfen untereinander verklebt werden”, nein, bestimmte Linien (z.B. Mauern, Zäune) sollen auch verbunden werden (Topologie).

Ich bestreite ja nicht, dass mit MP viel Schindluder getrieben wird, aber das derzeitige Proposal übertreibt es in die andere Richtung, aus meiner Sicht.

Doch, das ist genau der Kern des Vorschlags. Es ist nicht immer gleich zu überblicken, welche Linie zu welchem MP gehört; das Risiko, etwas zu “zerschießen”, ist empirisch belegbar deutlich höher bei MP aus mehreren Outer-Ways. Siehe die regelmäßigen Hilferufe hier im Forum. Insbesondere in Ecken, wo mehrere Flächen aufeinanderstoßen, passieren häufig Unfälle.

Ja. Weil das Thema so umstritten ist, würde ich dazu raten, es hier auszuklammern. Ich befürchte nämlich auch, dass irgendjemand auf die clevere Idee kommt, alle drei (räumlich weit getrennten) Kliniken der Berliner Charité in ein MP zu packen, wenn hier für MPs mit mehreren Outer-Ringen grünes Licht gegeben wird.

Dass iD die Nutzer im Dunkeln lässt, was sie da eigentlich anrichten, sollte nicht der Maßstab sein.- Was meinst Du mit “übereinandergeklebten Flächen”? Miteinander verklebte Flächen? Das ist selbst mit dem verpönten P2 ein Kinderspiel (einen gemeinsamen Node anfassen und solange “#” drücken, bis die gewünschte Fläche gehighlighted wird).

Könntest Du mit einer vorsichtigen Formulierung leben: “Überlege reiflich, bevor du Linienelemente wie Mauern und Zäune auf Flächengrenzen setzt, weil sie dann im Editor möglicherweise nicht klar genug angezeigt werden.”

D.h. das steht da absichtlich so da? Ich war eigentlich von einem Versehen ausgegangen.
Ich würde da klar unterscheiden zwischen Linien, die eine konzeptionell eine Fläche repräsentieren (Straßen, waterways) und solchen, die eine Linie darstellen (bzw. vertikale Fläche), z.B. auch Cliff, coastline, die meisten barrier Linien, etc.
Es geht hier um Topologie, bestimmte Linien müssen idealerweise mit den Flächen verbunden werden.

Flächen sollten generell so wenig wie möglich mit sonstigen Linien verbunden sein, das gilt nicht nur für ways, sondern auch für barriers, natural:tree_row, power:line, usw.
Man muss es im Gegensatz zu den ways bei den barriers allerdings nicht so streng nehmen. Die Wiese endet nicht in Straßenmitte, das ist sicher unstrittig, aber ob die Wiese nun am Zaun endet, oder am Straßenrand (also z. B. 0,5 Meter neben dem Zaun)…Die zuletzt vorgeschlagene Formulierung lässt diesen nötigen Spielraum.

“Müssen” geht mir zu weit.
Mauern, Zäune etc. stehen längst nicht immer genau auf der Flächengrenze. Bei einer späteren Detaillierung wird der Aufwand und die Fehleranfälligkeit höher, insbesondere wenn ein (unechtes, segmentiertes) MP mit diesen Linien erzeugt wurde.
Wenn die Linien denn an die Fläche geklebt werden, dann zusätzlich zur Flächengrenze und nicht als Mitglied der MP-Relation.

Das Erzeugen eines MP ist halt leider viel einfacher als das spätere Aufteilen.
Das Durchklicken bei übereinander liegenden Linien sehe ich als das kleinere Übel.

Ich würde versuchen, nicht jeden denkbaren Einzelfall abzudecken (da bleiben immer Lücken), sondern an den gesunden Menschenverstand appellieren. Deswegen mein Formulierungsvorschlag mit “reiflicher Überlegung” → wenn Du reiflich überlegt und die widerstrebenden Argumente abgewogen hast, darfst Du auch den Zaun auf die Flächengrenze setzen.

+10!