DE:Proposed features/Empfehlung zur Verwendung von Multipolygonen

Dies ist ein Vorschlag zur Verwendung von Relationen als Multipolygone im Gegensatz zur Verwendung von geschlossenen Wegen für die Modellierung von Flächen in Deutschland. Der Vorschlag bezieht sich ausschließlich auf Deutschland.

[Redaktionelle Anmerkung: Aufgrund eines Übertragungsfehlers ist die Zusammenfasssung in ihr Gegenteil verkehrt worden. Richtigerweise geht es um eine Empfehlung für die Verwendung von geschlossenen Wegen zur Darstellung von einfachen Flächen anstelle von Multipolygonen.]

This is a proposed recommendation of the community in Germany regarding the use of relations as multi-polygons versus closed ways to model areas in Germany. If confirmed, it would apply to Germany only.

Empfehlung zur Verwendung von Multipolygonen in Deutschland
Zustand:	Rejected (inactive)
betroffene Elemente:	,
Kurzbeschreibung:	Empfehlung für die Verwendung von Multipolygonen anstatt von geschlossenen Wegen zur Darstellung von Flächen.
Entwurf vom:	2018-11-12
Diskussionsbeginn:	2018-11-13
Abstimmungsbeginn:	2018-12-15
Abstimmungsende:	2019-01-01

Beweggründe

• Unabhängig vom Editor wollen wir es allen Mappern möglichst leicht machen, Daten einzufügen, zu verfeinern, zu aktualisieren oder nicht mehr existente Objekte zu löschen.
• Es fällt nicht nur Neulingen, sondern auch vielen erfahrenen Mappern schwer, in Gegenden mit intensivem Multipolygoneinsatz Landnutzungsdaten zu ändern. Die Folge ist, dass in diesen Regionen Daten nicht oder nur unzureichend aktualisiert werden.
• Nach unserer Erfahrung sind Multipolygone anfällig für Bearbeitungsfehler - vor allem dann, wenn wenn sie aus mehreren Outer-Ways bestehen.
• Aufeinander liegende Ways sind zwar auf den ersten Blick doppelte Daten, aber Relationen sind für Datenauswerter (Renderer) aufwendiger zu verarbeiten.

Proposal

Die Mapper im OpenStreetMap-Forum users:Germany empfehlen nach eingehender Diskussion und Abstimmung, die folgenden Leitlinien beim Bearbeiten von Relationen der Art type=multipolygon, genannt „Multipolygon“ oder „MP“ zu beherzigen:

1. Verwende für eine Fläche, die durch einen einfachen geschlossenen Weg erfasst werden kann und keine inner-Ringe aufweist, kein type=multipolygon, sondern einen einfachen geschlossenen Weg.
2. Ein MP sollte möglichst nur einen geschlossenen äußeren Ring aufweisen. Wenn die Aufteilung eines äußeren Ringes notwendig wird, weil er die zulässige Anzahl von 2000 Nodes übersteigt, ist das ein klares Anzeichen dafür, dass das MP insgesamt zu groß ist. Versuche nach Möglichkeit, große Flächen entlang natürlicher Trennlinien (Straßen, Flüsse, Eisenbahnlinien, Hochspannungsleitungs-Schneisen o.ä.) in handlichere Flächen aufzuteilen. Nachfolgende Mapper werden es dir danken, wenn sie überschaubaren Flächen vorfinden. Dementsprechend unerwünscht sind auch Flächen aus mehreren MP, die sich über ganze Landstriche erstrecken.
3. 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.
4. Vermeide es nach Möglichkeit, die Nodes von Straßen, Bahnlinien und anderer Linienelemente mit Flächen zu „verkleben“. Nur Flächen dürfen untereinander verklebt werden. Überlege reiflich, bevor du Linienelemente wie Mauern und Zäune auf Flächengrenzen setzt. Nachfolgende Mapper werden es dir danken, wenn sie ein klares Datenbild in ihrem Editor vorfinden. Absolut unerwünscht ist das Verkleben von Flächen mit Grenzen, weil sie dann leicht unabsichtlich verschoben werden können.
5. Falls du unbeherrschbare MPs vorfindest und zweifelst, ob du sie selbst korrigieren kann, melde dich im OSM-Forum, auf der Mailingliste Talk-de oder einem anderen, von der Gemeinschaft genutzten Kommunikationskanal(en) und bitte dort um Hilfe. Reparaturen missglückter Editierversuche sind immer aufwendiger als eine Vorbearbeitung durch einen erfahrenen Mapper.
6. Bitte unterlasse es, vorhandene Daten, die nicht dieser Empfehlung entsprechen, ohne konkreten Anlass diesen Empfehlungen anzupassen. Das gebietet der Respekt vor der Arbeit anderer Mapper. Verfeinerst, aktualisierst oder korrigierst du allerdings Daten, kannst du sie den Empfehlungen gemäß umbauen. Änderungen nur des Änderns Willen sind unerwünscht.

Diese Empfehlungen wurden von der deutschen Gemeinschaft im OSM-Wiki abgestimmt, nachdem auf der Mailingliste, im Forum und in der „Wochennotiz“ darauf aufmerksam gemacht wurde. Sie gelten deshalb nur in Deutschland, und deutsche Mapper sind angehalten, sich vor dem Mapping in anderen Ländern über die dort bevorzugte Methode zu informieren.

Beispiele

239022783 239022783

Mehrere Flächen wurden mittels Multipolygonen erstellt. Anschließend wurden diese wieder aufgelöst.

2337327 2337327

merkwürdiges MP bei Roßleben, TH

2236289 2236289

Multipoligonteppich von 14 zusammenhanglose Flächen, die aus 74 äußeren Linien zusammengestellt wurden, die jeweils outer-Abschnitte von anderen Multipolygonen sind.

Übersichten mit Overpass

MP mit vielen Elementen der Rolle outer

Zum Ausführen rechts auf das Symbol klicken!

[out:json][timeout:25][bbox:{{bbox}}];

relation["type"="multipolygon"](if: count_by_role("outer") > 20);
out body;
>;
out skel qt;

Straßen als MP-Begrenzungen

Zum Ausführen rechts auf das Symbol klicken!

[out:json][timeout:100][bbox:{{bbox}}];

relation["type"="multipolygon"];
way(r:"outer")["highway"]; 
(._;>;);
out meta qt;

Tagging

siehe Proposal

Bezug

Modellierung von Flächen in Deutschland

Betroffene Features/Wiki-Seiten

• DE:Relation:multipolygon
• DE:Types of relation
• DE:Area
• DE:Way#Geschlossener_Linienzug
• DE:Multipolygon Examples
• DE:Tag:type=multipolygon
• Verweis von DE:Editing Standards and Conventions möglicherweise sinnvoll
• neu zu erstellende Feature-Seite

Externe Diskussionen

Lange Diskussion im Forum der deutschen Nutzer [1], [2] Auch im Österreich-Forum.

Ankündigung auf der Mailingliste talk-de: https://lists.openstreetmap.org/pipermail/talk-de/2018-November/115642.html

Kommentare

Kommentare bitte vorzüglich im Forum oder innerhalb der Diskussionsseite.

Abstimmung

Voting closed

Voting on this proposal has been closed.

It was rejected with 37 votes for, 24 votes against and 2 abstentions.

Viele hielten das Proposal für schlecht formuliert. Die folgenden Bemerkungen können eine Inspiration für ein neues Proposal sein.

• I approve this proposal. --Kjon (talk) 16:41, 16 December 2018 (UTC)
• I approve this proposal. --Pfad-Finder (talk) 12:50, 17 December 2018 (UTC)
• I approve this proposal. --Falcius (talk) 09:39, 17 December 2018 (UTC)
• I approve this proposal. Notwendig, richtungsweisend und ausreichend. Über Detailformulierungen könnten wir noch jahrelang im Kreis diskutieren. --Nop (talk) 14:33, 15 December 2018 (UTC)
• I approve this proposal. Multipolygone gehören zu OSM und haben ihre Berechtigung. Da wo sie aber durch einfache Wege dargestellt werden können sind sie überflüssig. Sind sie zu groß und man muss minutenlang studieren, bevor man sich Änderungen zutraut, behindern sie nur. Verhindern sie gar das editieren, weil Editoren nichts mehr laden und nur Experten mit speziellen Werkzeugen arbeiten können, sind sie absolut fehl am Platze. Daher befürworte ich eine solche Tagging Guideline. --Robybully (talk) 14:39, 15 December 2018 (UTC)

Multipolygone sind so groß oder klein wie Flächen auch sein können, ich bin einverstanden, dass es jede Menge Multipolygone gibt, die besser als einfache Fläche(n) dargestellt würden, aber die Regeln schießen komplett übers Ziel hinaus. Anstatt darzulegen, welche Multipolygone unnötig sind, werden fast alle Anwendungsgebiete ausgeschlosssen, und es wird behauptet, überlappende ways wären einfacher und intuitiver zu bearbeiten. M.E. wäre eine sinnvolle Regel gewesen zu fordern, die Flächen jeweils so klein wie möglich zu machen (ohne dass dadurch Informationen verloren gehen). Riesige Flächen sind ein Problem, und Multipolygone können zu deren Entstehung beitragen, wenn man sie unüberlegt einsetzt. --Dieterdreist (talk) 09:27, 17 December 2018 (UTC)

• I approve this proposal. --Cg909 (talk) 14:54, 15 December 2018 (UTC)
• I approve this proposal. --streckenkundler (talk) 15:12, 15 December 2018 (UTC)
• I approve this proposal. Ja! Ich fand zwar an einigen Stellen noch geringen Verbesserungsbedarf, bin aber als der Initiator mit dem Kompromiss sehr zufrieden und hoffe, dass eine große Anzahl an Mappern der Empfehlung zustimmen wird. --Nakaner (talk) 15:25, 15 December 2018 (UTC)
• I approve this proposal. --Hca (talk) 15:33, 15 December 2018 (UTC)
• I approve this proposal. --Protoxenus (talk) 16:22, 15 December 2018 (UTC)
• I approve this proposal. --Aixbrick (talk) 16:24, 15 December 2018 (UTC)
• I approve this proposal. --Pyram (talk) 16:27, 15 December 2018 (UTC)
• I approve this proposal. --Geri-oc (talk) 16:43, 15 December 2018 (UTC)
• I have comments but abstain from voting on this proposal. Mein ursprünglich positives Voting ziehe ich hiermit zurück, da mir in der nachfoldenden Diskussion klar geworden ist daß ich die ganze Thematik noch nicht ausreichend verstehe um hier mitreden zu können. Gleichwohl möchte ich anmerken, daß ich mir Empfehlungen hinsichtlich Multipolygonen wünschen würde. Mir sind diese bereits mehrfach als hinderlich aufgefallen. --Ajf3934221-wiki-tue (talk) 22:24, 22 December 2018 (UTC)
• I approve this proposal. --Surveyor54 (talk) 17:25, 15 December 2018 (UTC)
• I approve this proposal. --Mammi71 (talk) 17:50, 15 December 2018 (UTC)
• I approve this proposal. --Dx125 (talk) 17:59, 15 December 2018 (UTC)
• I approve this proposal. --Gogul (talk) 18:50, 15 December 2018 (UTC)
• I oppose this proposal. Meine Einwände zum zweiten Satz in Punkt 4. sind bekannt --Aeonesa (talk) 19:05, 15 December 2018 (UTC)
• I approve this proposal. KISS! --Geofreund1 (talk) 19:06, 15 December 2018 (UTC)
• I approve this proposal. --Wemken (talk) 19:51, 15 December 2018 (UTC)
• I oppose this proposal. Sorry, dass ich versäumt habe, diese Einwände früher zu bringen, aber in der vorliegenden Form ist mir das einfach zu stümperhaft formuliert, auch wenn ich inhaltlich im großen und ganzen zustimme. Ich finde: (I) bei großen Flächen sind MP mit mehreren outern angebracht, das kommt aber in 1. nicht zur Geltung. (II) es gibt durchaus sinnvolle MPs mit *mehreren* äusseren Ringen (z.B. ein benanntes Wohngebiet, das aus zwei disjunkten Teilen besteht), das wird aber von 2. nicht gewürdigt. (III) "nur Flächen dürfen miteinander verklebt werden" und danach dann "überlege reiflich" bei Zäunen ist eine unsinnige Formulierung - das "dürfen" muss dann ein "sollten" werden. (IV) insgesamt ist mir zu viel Geschwafel drin ("nachfolgende Mapper werden es Dir danken"). Eine brauchbare Empfehlung muss klarer sein. Das muss nochmal überarbeitet werden. --Woodpeck (talk) 20:07, 15 December 2018 (UTC)

Schade, daß nach ewiger Disskussion einige Einwendungen und Verbesserungen erst dann kommen, wenn abgestimmt wird. --streckenkundler (talk) 17:34, 16 December 2018 (UTC)

Das ist schade, ja, aber ehrlich gesagt hatte ich wohl einfach zu viel Vertrauen in die Community-Arbeit. Ich dachte, ok, da reden ein paar Leute rüber und arbeiten an der Sache, da wird schon was vernünftiges bei rauskommen. So der tolle Held, dass es ohne mich nicht geht, bin ich ja nun auch wieder nicht. Das, was ich angemerkt habe, hätte jedem auffallen müssen, der sich mit OSM und deutscher Sprache halbwegs auskennt. Da geht es ja nicht um die Inhalte, sondern darum, wie sie missverständlich und widersprüchlich präsentiert sind. --Woodpeck (talk) 14:53, 19 December 2018 (UTC)

Ich bin ja froh, daß Die Disskussion zu mindestens bis zu diesem Punkt angelangt ist und egal, wie gut oder wie verbesserungswürdig die Formulierungen sind, sehe ich doch daß bei vielen das Problem erkannt ist (auch wenn es zurück zur Disskussionsphase gehen würde). Ob es in absehbarer Zeit einen einigermaßen einvernehmlichen Lösungsansatz geben wird, wage ich auch zu bezweifeln. Beispiele zu kruden und seltsamen MP-Konstrukten sind ja reichlich geliefert worden, siehe zuletzt mein jüngstes Beispiel in Weißenfels https://forum.openstreetmap.org/viewtopic.php?pid=730148#p730148 . Ich habe regelmäßig Kontakt zu iD-Mappern, die einfach aus Spaß an der Freude und um des Karten verbesserns Willen mappen. Sie werden sich aber hier oder im Forum nicht zu dem Thema äußern, beschweren sich aber regelmäßig beim ir per PN über diverse MP-Konstrukte, deren Komplexität und deren Größe. Ich überprüfe oder zerteile solche Groß-MP's an bereits im Forum genannten Langschaftselementen auf Anfrage, und ja es ist immer mit einer weiteren Detailierung der Erfassung verbunden.--streckenkundler (talk) 21:10, 19 December 2018 (UTC)

• I approve this proposal. Über einzelne Formulierungen lässt sich streiten, aber die Richtung stimmt --Seichter (talk) 20:23, 15 December 2018 (UTC)
• I oppose this proposal. Beim Verkleben gehe ich mit. Punkt 3 ist meiner Meinung nach aus geometrischer Sicht Unfug. --Morjak (talk) 20:26, 15 December 2018 (UTC)

Dann mache bitte Vorschläge und vor allem Anleitungen (auch und insbesondere für iD) daß Konstrukte wie z.B. https://www.openstreetmap.org/relation/2302605 von Usern möglichst einfach so bearbeitet werden können, daß z.B. am Rande dieser Ackerfläche vorhandene Grünlandflächen abgeteilt werden können( die bei diesem MP auch real vorhanden sind!!)... Punkt 3 ist meiner Ansicht nach der Schlüsselpunkt, um komplizierte Relationen für Nutzer anderer Editorn zu öffnen. --streckenkundler (talk) 22:51, 16 December 2018 (UTC)

• I approve this proposal. --Waldhans (talk) 23:02, 15 December 2018 (UTC)
• I oppose this proposal. Insgesamt zu ungenau von der Formulierung — nicht signierter Beitrag von Unknow74 (talk • contribs) 20:29, 15 December 2018‎
• I approve this proposal. --Miche101 (talk) 15:47, 16 December 2018 (UTC)
• I oppose this proposal. Die Einführung von Regeln ist meiner Wahrnehmung nach, allein von Karten Tile- Produzenten betrieben, und bringt uns Mappern keinen Vorteil blog.addresshistory.org. Speziell der Punkt 3 ist nach meiner Meinung kompletter Unsinn. Ein Defekt des Editors ID. ist heute für viele zerstörte MP Strukturen verantwortlich, von den Befürwortern von Regeln wird dieses Problem für ihre Zwecke instrumentalisiert, daher gibt es dazu keine Diskussion. --addresshistory*org (talk) 16:13, 16 December 2018 (UTC)

Wenn du iD hier alleine die Fehler in die Schuhe schieben willst, kannst du das für dich gerne machen, du machst es dir dann aber zu einfach und es geht aber an der Realität der Entstehung vieler Fehler vorbei... Oft ist es die Verwendung eines falschen Relationstypes (multipolygon anstatt building). Es sind Versuche von Mappern Dinge zu ergänzen bei MP's deren Erstellung mehr 8-9 Jahre zurückliegt und die etliche Quadratkilometer groß sind für eine Landschaft, die recht reich strukturiert ist und keiner bisher z.B. Moore und Seen im Wald ergänzt hat oder meadow, scrub und Forst in einem Acker-MP abgeteilt hat. Es betrifft z.B. auch Parks... Für bestimmte Dinge muß man es sich dreimal überlegen, ob ein MP richtig ist, bei leisure=park halte ich MP's in der Regel für kompletten Unsinn... Die Liste ließe sich fortsetzen. --streckenkundler (talk) 17:34, 16 December 2018 (UTC)

• I approve this proposal. --Abi12563 (talk) 17:27, 16 December 2018 (UTC)
• I approve this proposal. --kartonage (talk) 19:23, 16 December 2018 (UTC)
• I approve this proposal. Grundsätzlich teile ich Einschätzung oben von Woodpeek. Große Seen und Inseln müssen auch MP mit mehreren (langen) outer Linien möglich sein. Ansonsten klare Zustimmung. --HalverHahn (talk) 19:36, 16 December 2018 (UTC)

Bei outer-Linien >2000 Punkte verweigert z.B. JOSM das Hochladen zum Server, dann also 2 (oder ggfs. mehr) outer-Linien anlegen, dies Regelwerk hier ist nur eine Empfehlung. Ich habe übrigens gerade eine Linie durch Entfernen nicht notwendiger Verklebe- (!) Punkte von 2300 auf 1700 nodes abgespeckt, mit gutem Willen geht nämlich Vieles. Warum Multipolygone mit < 2000 nodes (in Summe) in den Außenlinien mehr als 1 outer haben sollten erschließt sich mir nicht, außer es sind Sammelrelationen für mehrere Inseln, Seen usw. --dx125 (talk)

• I approve this proposal. --Thomas8122 (talk) 21:48, 16 December 2018 (UTC)
• I oppose this proposal. ich bin zwar mit den Punkten 5-6 einverstanden, sowie mit der Wortwahl "Empfehlung", aber bei 1-4 sehe ich in jedem Punkt Probleme, obwohl die Regeln sicher oft auch zu einer sinnvollen Repräsentation führen, so gibt es in der Absolutheit doch jeweils so große Probleme, dass man m.E. nur ablehnen kann: 1. MPs ohne Inner machen in mind. 2 Situationen Sinn: zur Trennung von logischen Objekten bei Vermeidung von überlappenden ("doppelten") Objekten und zur Wiederverwendung von Grenzen (Zäune, Mauern) zur Bildung von Flächen. 2. Nimmt den MP eines ihrer Anwendungsgebiete und führt in der Konsequenz zum Schlechtesten beider Welten: überlappende Ways und Multipolygone an derselben Stelle (weil man die Ways für das z.B. wegen vorhandenen inners auch nach diesen Regeln erforderliche MP nicht mehr wiederverwenden kann sondern für das MP einen neuen geschlossenen Way zeichnen muss). Ausserdem gibt es bei Objekten die aus mehreren nicht verbundenen Flächen bestehen gar keine Alternative. 3. Ich bezweifle, dass diese Art des Mappens weniger zu durchschauen ist als überlappende Polygone, in iD sieht man überhaupt keinen Unterschied, auch in JOSM und GoMap!! ist so eine Situation klar, d.h. es bleiben nur noch die <1% Edits von Leuten, die immer noch mit Potlatch editieren, weil es für die diversen POI-Editoren auch keine Rolle spielt. 4. Fängt zwar gut an, aber da dann auch davon abgeraten wird Mauern und Zäune zur Begrenzung von Flächen zu verwenden, sehe ich hier einen großen Schaden für die Topologie, falls sich das so durchsetzt. Diesen Irrweg des absichtlichen Nichtverbindens um jeden Preis kann man jetzt schon an vielen Stellen sehen. 7. Was nicht erwähnt wird, aber eine große Rolle bei der ursprünglichen Motivation zu spielen scheint, ist dass Relationen die Verarbeitung von Daten aufwändiger machen. Bisher war das Dogma aber, es dem Mapper einfacher zu machen, nicht demjenigen, der die Daten auswertet. --Dieterdreist (talk) 09:20, 17 December 2018 (UTC)
• I oppose this proposal. Ich unterstütze zwar das Grundanliegen des Proposals, geschlossene Ways gegenüber Multipolygonen zu bevorzugen und übergroße Flächen sowie MP-Teppiche zu vermeiden, teile aber die u.a. von Aeonesa vorgebrachten Einwände bezüglich des (eigentlich auch themenfremden) Punkts 4 zur gemeinsamen Nutzung von Nodes mit Zäunen bzw. Mauern. --Tordanik 20:13, 17 December 2018 (UTC)
• I approve this proposal. --Chrysopras (talk) 12:25, 18 December 2018 (UTC)
• I oppose this proposal. Ich schließe mich den Bedenken von Woodpeck, Tordanik und insbesondere den Ausführungen von Dieterdreist zu Punkt 4 an. --Whb (talk) 23:38, 18 December 2018 (UTC)
• I oppose this proposal. International mit allen Communities abgestimmt gut, auch wenn keine Lösung für den Umgang mit Namen genannt wird(Soll dann jeder Way den entsprechenden Namen bekommen?). Als Vorschlag das ganze nur in De zu machen muss ich aber ablehen. Es gibt keinen echten Grund dagegen das ganze auf englisch zu übersetzen und als globalen Standard zu diskutieren. --SpaLeo (talk) 12:43, 19 December 2018 (UTC)

Das Thema wurde mit “wir brauchen Regeln für Multipolygone” vorgestellt. Wenn man das international zur Abstimmung bringt ist das völlig unkontrollierbar und unberechenbar, am Ende kommt raus, dass man sich auf keine Empfehlung einigen kann. Wenn man es erst mal in Deutschland macht ist das Feld schon homogener. Es gibt auch andere Gründe dafür: hier gibt es eine relativ reife Karte und eine große Craftmapper community, also Leute denen das Projekt wichtig ist und die Erfahrung im Mappen haben. —Dieterdreist (talk) 17:57, 19 December 2018

Dieters Argumentation halte ich für richtig. Sofern die Mehrheit zustimmt, können wir mal ein Jahr abwarten und in Deutschland beobachten, ob die Empfehlungen funktionieren und die gewünschten Effekte erzielen. Wenn sie sich im Grundsatz bewähren, sollten wir in der Tat eine englische Übersetzung machen, damit sich die anderen nationalen Communities bedienen können. Ich halte aber nichts davon, das Thema auf der Ebene OSM-weltweit zu regeln. Bei den MPs geht es um die Frage, wie man ein vorhandenes Instrument interpretiert und damit arbeitet; etwas anderes ist neues Tagging, wo wirklich weltweite Standards gelten müssen.--Pfad-Finder (talk) 13:23, 20 December 2018 (UTC)

• I oppose this proposal. Siehe die Bedeken von Dieterdreist & Woodpeck. --Michi (talk) 21:22, 19 December 2018 (UTC)
• I oppose this proposal. Kein wirkliches Problem das der überregulierung Bedarf. --Flohoff (talk) 12:33, 20 December 2018 (UTC)
• I oppose this proposal. Punkt 1 ist trivial (KISS). Punkt 4 hat nur mittelbar mit MP-Relationen zu tun und muss daher getrennt geregelt und abgestimmt werden. Punkt 5 und 6 sind nicht MP-spezifisch sondern gelten für alle Mapping-Aktivitäten, sie hier zu wiederholen ist überflüssig. Bleiben Punkt 2 und 3, deren Formulierung für den weniger erfahrenen Mapper zu knapp, zu schwammig und zu abstrakt ist. Bei 2 fehlt der Hinweis darauf, wie verfahren werden soll, wenn aufgetrennte Flächen logisch zusammen gehören und gemeinsame Eigenschaften haben. Bei 3 ist mir unklar was ein "MP-Teppich" sein soll. Ein Hinweis auf KISS und einige Beispiele, wie man mit typischen Situationen umgehen kann, wäre hilfreicher und bräuchte auch keine Abstimmung. --RainerU (talk) 14:48, 20 December 2018 (UTC)

a) Punkt 1 ist zugegebenermaßen trivial, wird aber leider oft nicht beachtet. b) Punkt 2: Wir haben um eine klare Formulierung gerungen, aber eine scharfe definitorische Abgrenzung für jeden denkbaren Einzelfall würde einen Regulierungsmoloch schaffen, den keiner liest und versteht. Einzig gangbarer Weg ist, in solchen Fällen an die Mapper zu appellieren, sorgsam abzuwägen. c) Punkt 3: Gemeint ist so etwas: https://www.openstreetmap.org/relation/2302605 - ein im Grunde simpler Outer-Ring, aber zusammengestückelt aus zig outer-Elementen. Ein einfacher geschlossener Way hätte es auch getan. Leider gibt es einzelne Regionen, in denen solche MP-Konstrukte flächendeckend vorkommen, deswegen "MP-Teppiche".--Pfad-Finder (talk) 23:14, 21 December 2018 (UTC)

• I approve this proposal. --geozeisig (talk) 07:45, 21 December 2018 (UTC)
• I oppose this proposal. Aus den von Woodpeck, Dieterdreist und Tordanik genannten Gründen --geow (talk) 22:07, 22 December 2018 (UTC)
• I approve this proposal. -- Stimme mit allen Punkten ueberein, explizit auch mit den nur thematisch verwandten Punkten, schade, dass man sich in AT nicht ausreichend dafuer begeistern konnte. Gppes 22:15, 22 December 2018 (UTC)
• I oppose this proposal. zugunsten einer besser ausgegorenen Version (an der ich dann auch gern mitgäre) und schließe mich inhaltlich Aeonesa und Tordanik an. Das Anliegen an sich unterstütze ich ausdrücklich und die Zielformulierungen gefallen mir auch, aber der Kern des Proposals, die sechs Punkte, sind teils selbstwidersprüchlich und in einzelnen Formulierungen deutlich zu hart, was den Richtliniencharakter wieder verwässert und Anfänger eher verwirrt, indem Mappingtechniken, die man noch häufig findet und die technisch funktionieren, als quasi verboten gebrandmarkt werden. Das kriegen wir besser hin! --Kreuzschnabel (talk) 22:53, 22 December 2018 (UTC)
• I oppose this proposal. Mein Gegenbeispiel ist immer ein größeres Waldgebiet (konkret: der Deister): der outer ist entweder viel zu unhandlich (>1000 Nodes) oder man braucht hinterher eine Art Sammelrelation, um erkenntlich zu machen, dass das alles zusammengehört. Für Dinge wie Flächenverklebungen hatten wir vor kurzem erst ein Memorandum, dass man dazu den Ball flach halten soll, davon jetzt hier Teile doch wieder zu regeln halte ich für äußerst unglücklich. --Dakon (talk) 13:02, 23 December 2018 (UTC)
• I oppose this proposal. Das Proposal ist zu schwammig. Punkt 4 gehört komplett gestrichen, da nicht Thema des Proposals. Im übrigen teile ich die vielfach postulierte "Übereinstimmung", dass MPs und Linien nicht verklebt werden dürfen/sollten, nicht. Riesenpolygone, die ganze Landstriche abdecken, sind in der Tat ein Ärgernis, v.a. wenn sie ausschließlich für features wie "landuse=*" verwendet werden, wie es allzuoft der Fall ist und was man leicht durch kleinere Einheiten ersetzen könnte. Sobald das MP aber eine größere Einheit - MIT eigenen properties - zusammenfasst, wie z.B. heritage-Relationen (site-), dann haben sie sehr wohl Sinn. Und dann kann Forderung 2 so auch nicht mehr stehen bleiben. Dazu wird aber im Proposal nicht differenziert. Im übrigen halte ich ein Regelwerk, das nur für Deutschland gelten soll, nicht für zielführend. Zecke (talk) 15:35, 23 December 2018 (UTC)
• I approve this proposal. auch wenn ich mit meiner Auslegung der Empfehlung vielleicht nicht mit allen hier d'accord sein dürfte ;-) --Q un go (talk) 20:26, 23 December 2018 (UTC)
• I oppose this proposal. Ich habe meine Meinung schon gesagt: https://forum.openstreetmap.org/viewtopic.php?pid=730902#p730902 Rogehm 01:52, 24 December 2018
• I approve this proposal. --Zartbitter (talk) 15:16, 24 December 2018 (UTC)
• I approve this proposal. Damit die aufreibende Diskussion aufhört! Das Proposal versucht allen gerecht zu werden, und wird damit sehr schwammig. --Fx99 (talk) 07:11, 26 December 2018 (UTC)
• I approve this proposal. --Constantino (talk) 10:30, 26 December 2018 (UTC)
• I approve this proposal. --Hike39 (talk) 17:20, 26 December 2018 (UTC) (UTC)
• I approve this proposal. --sundew 12:30, 27 December 2018 (UTC)
• I oppose this proposal. Leider bin ich zeitlich nicht dazu gekommen, schon an der Diskussion im Forum teilzunehmen, sie ist leider oft auch abgedriftet. Ich habe mir jetzt erst die Empfehlung komplett durchgelesen. Ich denke grundsätzlich stimme ich den Punkten zu, aber auch ich muss sagen, dass ich mich mit einigen Formulierungen nicht anfreunden kann, auch nicht als Kompromiss. Punkt 1 ist klar und ok. Aber schon Punkt 2 habe ich mir mehrmals durchgelesen und verstehe ihn in dieser Formulierung nicht. Was ist ein „geschlossener Ring“? Ist damit, wie in Punkt 1, ein „geschlossener Weg“ gemeint, also in OSM-Sprech ein „Way“? Dann ist das aber doch das, was in Punkt 3 angesprochen wird. Oder soll es bedeuten, ein MP soll nicht aus mehreren nicht verbunden äußeren Linienzügen bestehen? Dann hat das aber doch nichts mit der im nächsten Satz genannten 2000-Punkte-Problematik zu tun. Punkt 2 ist mir also zu unklar ausformuliert und, wenn man sich nachher darauf berufen will, gibt es sicherlich Deutungsprobleme. Punkt 3 stimme ich zu. Punkt 4 stimme ich dem Grunde nach auch zu, aber auch hier wieder die Formulierung: Das ganze ist eine Empfehlung, in den zweiten Satz gehört dann kein „dürfen“. Den Satz „nur Flächen dürfen untereinander verklebt werden“ kann man eigentlich ersatzlos streichen, in den beiden Sätzen davor und danach steht eigentlich schon alles drin. Oben wurde eingewendet, Punkt 4 träfe nicht nur auf MPs zu. Das stimmt, man könnte da eine separate Empfehlung machen, aber falsch ist es hier bei MPs ja auch nicht. Das, finde ich, ist kein trifftiger Ablehnungsgrund. Punkte 5 und 6 sind ok. Zu viel Geschwafel finde ich in dem Text nicht. Das ist hier ja nicht das BGB und wir wollen nicht erst noch einen Kommentar dazu verfassen müssen. --TZorn (talk) 16:24, 27 December 2018 (UTC)
• I oppose this proposal. Ich stimme zu, dass Nodes und Ways von Grenzen für nichts anderes verwendet werden sollen, und dass Multipoligone nicht zu groß werden sollen. Was den Rest des Vorschlags angeht, bin ich aus grundsätzlichen Erwägungen dagegen. Genauere Begründung würde jetzt um diese Uhrzeit zu weit führen. --Mink (talk) 02:05, 28 December 2018 (UTC)
• I approve this proposal. Grundsätzlich halte ich Regeln bzgl. Multipolygonverwendung für gut. Auch wenn die im Proposal als unerwünscht beschriebenen Multipolygone zahlenmäßig nicht so sehr ins Gewicht fallen, verursachen sie doch Schwierigkeiten in der Bearbeitung. Somit wird klargestellt, daß das nicht beste Praxis beim OSM-Kartieren ist und ggf. mit Unterstützung erfahrener OSMler aufgelöst werden kann. Bis jetzt habe ich mit der Abstimmung gezögert und geschwankt, einerseits wegen der falschen Überschrift, die das genaue Gegenteil suggeriert, andererseits wegen Punkt 4, denn gerade Zäune und Mauern können ja flächenbegrenzende Elemente sein; die Verklebung mit Straßen, Flüssen, Bahnlinien ist davon zu trennen, weil deren Linien ein flächiges Element abstrahieren. Mein Fazit war dann aber, besser diese Regeln als keine. --Rainero (talk) 16:21, 29 December 2018 (UTC)
• I oppose this proposal. Im Kern gut, aber die Umsetzung aus den bereits hier oft genannten Gründen nicht gut. Das wichtige Thema wird schon seit Jahren thematisiert aber dann hoppla hopp übers Knie gebrochen, so das selbst ernsthafte Befürworter dagegen sind. Bitte nochmal in Ruhe und mit Bedacht von vorne, selbst wenn es nochmal ein Jahr dauert. Das ist zu wichtig, es ist nicht nur schnödes Taggig, das ist eher Architektur. --Peb12345 (talk) 21:29, 29 December 2018 (UTC)
• I have comments but abstain from voting on this proposal. Das Proposal war sicher gut gemeint, aber leider nicht hinreichend ausformuliert. --Schröcker (talk) 22:03, 29 December 2018 (UTC)
• I oppose this proposal. Grundsätlich bin ich gegen die Verwendung von Multipolygonen, bei denen ein Ring aus mehreren offenen Einzellinien besteht, sowie solchen mit mehreren outer-Ringen (solange es dafür keinen Grund wie bspw. benannte Waldgebiete gibt). Ich halte die Erarbeitung einer solchen Empfehlung grundsätzlich für sehr sinnvoll. Die Formulierungen sind mir jedoch an mehreren Stellen noch zu unausgereift bzw. uneindeutig (s. z.B. Kommentar von Woodpeck). Grammatikfehler wie "wenn sie überschaubaren Flächen vorfinden" erwecken den Eindruck, dass der Text in 2 Minuten getippt wurde und nicht nochmal durchgelesen wurde. (Mir ist jedoch durchaus bewusst, dass viel Arbeit dahinter steckt!) --Klumbumbus (talk) 23:13, 29 December 2018 (UTC)
• I oppose this proposal. Wie viele andere, die mit 'nein' stimmen, bin ich sehr für solche Richtlinien, kann aber aufgrund der handwerklichen Mängel dem konkreten Vorschlag noch nicht zustimmen. Da die Entstehung solcher Richtlinien durch Abstimmung m.w. einen Präzedenzfall darstellt, sollte der Vorschlag selbst klarer formuliert sein. Ich empfehle, nach dem Voting einmal durchzuzählen, wieviele der Nein-Stimmen grundsätzlich für das Anliegen waren, und dies als ein Mandat für eine überarbeitete Fassung zu nehmen. --Polarbear w (talk) 22:25, 30 December 2018 (UTC)
• I approve this proposal. --b*k* (talk) 10:28, 31 December 2018 (UTC)
• I oppose this proposal. Mir ist die Problematik bewust und ich kann die Bewegründe nachvollziehen. In diesem Vorschlag sehe ich keine geeignete Lösung. Ich bin mir nicht mal sicher, ob sich auf der Regulierungsebene eine Lösung findet. Auch ein deutscher Sonderweg in einem internationale Projekt macht für mich keinen Sinn. --Nzara (talk) 12:47, 31 December 2018 (UTC)
• I oppose this proposal. Meine Gründe wurden von anderen schon genannt --Roland5 (talk) 13:49, 31 December 2018 (UTC)