OT
Langer Rede kurzer Sinn. 
https://en.wikipedia.org/wiki/TL%3BDR
EDIT: Orthografie verbessert.
„Des Kaisers, neue Kleider“? „Langer Rede“ ist ein Genitivattribut, da kommt kein Komma dahinter 
–ks (wie klugscheißend)
Deswegen schreib ich auch (hoffentlich) immer “Lange Rede, kurzer Sinn”
Gruss
Walter, KöavD
Damit nicht noch eine Anfrage kommt: Köttelanspitzer vom Dienst
Da unser MP-Freak “seine” Wiki-Seite http://wiki.openstreetmap.org/wiki/DE:Multipolygon_Examples mit Zähnen und Klauen sogar gegen Gormos moderaten Warnhinweis und meine vorsichtige Ergänzung verteidigt (die, da hat Walter recht, eigentlich viel zu schwach formuliert ist), frage ich mich langsam, ob wir diese ohnehin teils sehr abgedrehten Beispiele nicht einfach ganz löschen und auf die ebenfalls vorhandene, zumindest auf den ersten Blick etwas vernünftiger aussehende Beispiel-Liste unter http://wiki.openstreetmap.org/wiki/DE:Relation:multipolygon/Examples verweisen sollten. OK, auch nicht perfekt … 
Hat jemand eine konstruktivere Idee, wie man diesen peinlichen Edit war um die Wiki-Seite beenden könnte? Es muss doch wenigstens erlaubt sein, einen Warnhinweis einzubauen. Oder gehört das OSM-Wiki einigen wenigen (einem) MP-Freak?
PS: Dank an NOP fürs erneute Wiederbeleben des immer wieder gemeuchelten Warnhinweises! 
Ich hätte da noch den “Wink mit dem Zaunpfahl” - Sperren des OSM-Accounts bis eine Reaktion auf die Bitte zur gemeinsamen Diskussion erfolgt. Leider muss ich allen Teilnehmern sagen, dass der im Wiki dafür vorgesehene Weg (Diskussionsseite des Wiki-Beitrages) nicht gegangen wurde. Da steht nur alter Kram und nichts zum aktuellen Auffassungsproblem 
Sprecht ihn dort noch 1 bis 2 mal an und wenn dann wiederum kommentarlos reverted wird, der “Zaunpfahl”.
Gruss
walter
ps: dennoch halte ich sein Schweigen hier im Forum für stark grenzwertig.
Ich hab ja auch nur “meinen Weg” beschrieben und der geht natürlich mit Josm. Ein allgemeingültiges Verfahren für “in welchen Flächen befindet sich dieses Objekt?” hab ich auch nicht parat.
Mit PostGIS geht das natürlich, aber wer will denn gleich eine Live-DB aktiv halten, nur um sowas zu finden? Ich habe so eine DB, mache das aber auch nicht damit. Da suche ich lieber “kreativ”. Und das mit dem “Suchgraben” klappt bei mir ganz gut.
Eventuell fällte den Overpass-Leuten was ein?
Ja, leider. MP mit Potlatch zu bearbeiten, ist ja anscheinend ganz gut möglich aber das mit iD zu tun, ist mMn schon fast “kriminell”
Oben in der URL-Zeile: http://www.openstreetmap.org/#map=12/-1.7560/29.9467 map=12 —> Zoom-Level 12
Gruss
walter
+1. Null Problemo. Soll ich mal dafür eine kurze Wiki beschreiben, gerade mal für Wälder, Wiesen und Teiche? ID - 
P.S. Hatte aber gedacht, Potlatch ist nicht geeignet für Einsteiger. In vielen Fällen geht’s aber meißt viel schneller (nicht komfortabler), wenn man die kurzen Schritte kennt.
Erg.:
Nö, deswegen “Ergänzende Beschreibungen” mit der imho besseren MP Erklärung dazugefügt.
Vielen Dank für den Hinweis! Habe ich gemacht:
http://wiki.openstreetmap.org/wiki/DE_talk:Multipolygon_Examples#Warnhinweis_und_Revertierungen
Ihr könnt den Text gerne ergänzen/verbessern. – Ich habe ihn ergänzend auch auf seiner User talk-Seite (nochmals) darauf hingewiesen. Dort hat er übrigens bereits Stellung genommen: https://wiki.openstreetmap.org/wiki/User_talk:Cmuelle8. Da die User-talk-Seite aber der falsche Ort für Sachdiskussionen ist (ich habe jene Stellungnahme auch gerade erst zufällig entdeckt), habe ich ihn nochmals um Teilnahme an der Diskussion hier gebeten.
Hallo,
vielleicht noch ein Gedanke eines Novizen zu diesem Thema:
MPs mögen mathematisch vermutlich das sauberste Modell sein und man kann es von ganz außen beginnen (‘Erde ist inner von Sonnensystem’), aber ein wesentlicher Aspekt bei einem gemeinschaftlichen Mitmachprojekt sind die Einstiegshürden. Nicht jeder hat Mathe studiert. Was nützen die schönsten MPs, wenn’s dann kaum einer pflegen kann? OSM lebt von den Daten und von der Pflege - verteilt, überall vor Ort. Da muß das Eintragen so simpel wie möglich sein. Und bei einem Haus will ich nicht die ganze Chain bis zum Sonnensystem pflegen müssen.
Es ist klar, dass sowas dann vom Auswerter mehr Intelligenz erfordert (was wird wie überdeckt), aber diese Intelligenz investiert man einmal bei Auswerter, und fordert es nicht von jedem Mapper.
Servus Wolfgang
Ich halte es für sinnvoll, die Diskussion im Wiki weiterzuführen, das ist mein Fehler, damit nicht gleich angefangen zu haben.
cmuelle8 macht den Vorschlag, “Vor- und Nachteile können bei Bedarf auch auf einer dedizierten Seite aufgezeigt werden, die sich explizit mit den Unterschieden beschäftigt - ohne dabei die Beschreibungs- und Beispielseiten die speziell einer Form der Modellierung gewidmet sind, zerpflücken zu müssen”. Das finde ich gut.
Weitere Wiki-Diskussion hier https://wiki.openstreetmap.org/wiki/User_talk:Cmuelle8#Komplexe_MPs .
Doch bevor wir unnötig die verschiedensten Argumente wiederkäuen, empfehle ich einen Blick in den thread
http://forum.openstreetmap.org/viewtopic.php?id=16911 (vielleicht kann Nop mal den Schreibfehler im Titel berichtigen
Sind nur gut 550 Beiträge, aber zeigen ein seinerzeit deutliches Meinungsbild im Forum zum Thema, das auch in anderen threads immer wieder hoch kommt.
Vielleicht wäre vieles einfacher, wenn wir uns endlich entschließen würden, die simple features als GIS-Standard auch in OSM konsequent umzusetzen, wonach z.B. unsere Multipolygone gar keine sind. Wer mehr wissen will:
http://www.ikg.uni-bonn.de/vorlesungsarchiv/GIS_III/Folien/Pack-and-Go/unzip/gisIII.10_v33.ppt
http://www.ikg.uni-bonn.de/vorlesungsarchiv/GIS_III/Folien/Pack-and-Go/unzip/gisIII.10a_neu.ppt
Was ich davon halte, dass jeder in der Wiki nach seinem Befinden Beiträge zu etablierten Tags beliebig abändern kann, werde ich hier nicht kundtun 
+1000. Ich bin nicht der Meinung, dass die Frage “MP ja/nein” immer nur eine Sache subjektiver Entscheidung ist, wie jener User uns suggeriert, sondern dass es durchaus auch objektive Gesichtspunkte gibt, nach denen zumindest in ganz einfachen Fällen MPs zu meiden sind und zudem manche Formen von MPs (v.a. mit Straßen o.Ä. als outer-Linien) eigentlich immer und überall zu meiden sind.
Eigentlich wollte ich jetzt hier nicht dazwischengrätschen aber vielleicht liest Jaeger52 ja noch mit.
Du hast im 1000 Seelen-Dorf Eltingshausen und Umgebung 250 überlappende Gebäude hinterlassen und ausnahmslos alle Hausnummern bei name=* eingetragen. Vielleicht kannst Du ja da nochmal einen Blick draufwerfen nachdem Du die Lichtung in die Multipolygon- Waldfläche gezaubert hast. Danke
Also, ich fasse mal zusammen, soweit ich das hier geschriebene richtig verstanden habe:
- Die im August 2015 eingeführte Form der Schraffur-Darstellung ist kein bug, sondern eine erzieherische Maßnahme und bleibt so.
- Hintergrund ist der Wunsch nach korrekter Topologie und der feuchte Traum einer quasi automatischen Auswertungsmöglichkeit von Flächendaten.
Meine Frage:
Werden von dieser “Topologischen Korrektheit” zukünftig auch Flächen betroffen sein, die derzeit noch keine Schraffur besitzen, sprich muss ich mich auf weitere seltsame Überraschungen (z.B. Fläche “natural=wood” auf Fläche “landuse=grass” geht nicht mehr) einstellen?
Die Entscheidung dafür wurde hier getroffen. Ein paar Argumente für und wider die Anordnung der Bäumchen über anderen Flächen tauchen in der Diskussion auf. Auch welche, die nicht erzieherisch oder von feuchten Träumen motiviert sind.
Meine Glaskugel sagt, das kann passieren. Falls sie die Leute dort auf github darauf einigen, dass Gras eine Signatur bekommt und dass diese Grasbüschel über Bäume, Zoos, Spielplätze, Teiche gesetzt werden, werden sie über diese Flächen wachsen (analog zu Sumpfgras über Wald im derzeitigen Stil). Wobei man da nicht allzu viele Variationen zur Verfügung hat, soweit ich das verstehe: Wer Gras über Spielplätze wachsen lassen will, muss es auch über Bäume wachsen lassen, oder ganz massive Änderungen vornehmen.
Alle anderen Karten betrifft das natürlich nicht. Deren Stilisten haben eigene Vorstellungen und auch beim OSM-Mapnik-Stil kann man mitreden. Im Zweifel würde ich durch Multipolygone kleine Flächen in grösseren Flächen ausschneiden, um sicher zu sein, dass die kleinen Flächen ohne Einfluss der grossen gerendert werden.
Grüße, Max
Oder man macht es wie bisher, denn wir taggen nicht für den Renderer.
Oder ist das Thema Ausschneiden im Wiki dokumentiert?
Ich persönlich werde nicht innerhalb eines landuse=residential jedes landuse=grass oder innerhalb eines landuse=forest jedes building=yes als inner definieren. Denn das mag zwar datenlogisch sauberer sein, macht es uns aber fast unmöglich, neue Leute zum Mitmappen zu animieren. Wir müssen da durchaus Grenzen festlegen von kleinen Flächen, die per default als inner von großen gelten, auch wenn das große gar kein MP ist – um den Mappingvorgang einfach zu halten. Wollen wir eine Wiki-Mitmach-Geodatenbank sein oder ein Präzisions-GIS? Letzteres kann nur von Fachleuten gepflegt werden, die sich intensiv in die Datenstrukturen reingedacht haben.
–ks
Vielleicht wäre alles einfacher, wenn wir endlich aufhören, von Auschneiden zu reden. Ein Polygon hat Ränder. Mindestens ein äußerer geschlossener Rand bildet das Polygon. Aber auch innere geschlossenene Ränder können das Polygon und die dafür definierten Eigenschaften begrenzen.
Bevor man sich darüber echauffiert, ob kleinere landuse/natural ausgestanzt werden müssen (IMO ja), sollte man erstmal gegen das in manchen Gegenden unsinnige Mappen von nicht notwendigen MPs vorgehen.
Verweise da nur auf den Thread: Durcheinander MP-Relationen
Nochmal: Es zwingt einen niemand, korrekte GeoDaten zu erfassen. Das Ausschneiden machen wir nicht für irgend einen Renderer,
sondern nur um anzuzeigen, dass die Flächeneigenschaft des MP nicht für dessen Inner-Fläche gilt.