Ich finde nichts was mich einschüchtert.
Ich beschäftige mich gerade mit einer Videoanleitung zur Bearbeitung von Multipolygonen für den Editor ID, und bin nun einigermaßen irritiert darüber, bislang lediglich eine Anleitung zum Zerstören von Multipolygonen gefunden zu haben. https://help.openstreetmap.org/questions/55984/splitting-a-multipolygon-into-two-in-id
Es ist einigermaßen absurd, anstatt den Editor ID zu reparieren, oder diesem die Fähigkeit zum Zerstören von Multipolgonen zu verbieten, die Lösung für dieses Editor Problem, in “Regeln für Multipolgone” zu suchen.
ID. ist ein Schadprogramm
ID zeigt das Verhalten eines Schadprogramms, und die Empfehlung
https://help.openstreetmap.org/questions/55984/splitting-a-multipolygon-into-two-in-id
ist sehr seltsam.
Schauen wir uns das Verhalten des Editors Go-Map!! an, so warnt dieser korrekt:
“Cnat´t extend Way, Extending a way which belongs to a Route or similar relation may damage the relation”
Solange ID. keine vergleichbare Warnung ausgibt, sollten wir die Verwendung von ID vorläufig einschränken, oder wenigstens eine offizielle Warnung ausgeben.
Wie man hier sieht,
https://wiki.openstreetmap.org/wiki/Editor_usage_stats#More_complex_analyses
gibt es Reihe von Editoren mit korrektem Verhalten, auf deren Verwendung sollten wir unter Verzicht auf den Editor ID. einstweilen verweisen.
Ich gehe davon aus, dass der relativ hohe Anteil an OSM Edits, beim Editor ID. aus HOT Aktivitäten stammt, und daher diese Statistik nicht repräsentativ ist. Probleme aus Hot Aktivitäten, sind aber sehr wohl Thema.
Das hier https://forum.openstreetmap.org/viewtopic.php?id=61207 ist eine Bekämpfung lediglich der Symptome, das Fehlverhalten des Editors ID. wohl eine der wesentlichen Ursachen für aktuelle Missing Boundaries.
edit: GoMap!! Warnmeldung + Missing Boundaries
Großes Kino hier, die Empfehlung wird jetzt schon komplizierter als die MP `s 
Yepp, war zu erwarten. 
Ich finde den Gesprächsfaden zusehends interessant, und spannend.
Wenig kompliziert wäre es, dem Editor ID. Regeln beizubringen. Zum Beispiel diesem vorläuft Edits von solchen Linien zu verwehren, welche Mitglied in einem Multipolyon sind.
Das aktuelle Phänomen, regelmäßig auftretende Lücken in Grenzen, sogenannten Missing Boundaries könnte man so wesentlich eindämmen.
Dazu wäre eine Auswertung interessant, welcher Editor am meisten beim Verursachen solcher Lücken verantwortlich ist.
@addresshistory*org Deine zwei letzten Beiträge sind off-topic. Bitte eröffne einen neuen Thread und versuche nicht, in bestehenden vom Thema abzulenken, wie du das schon im österreichischen Forum oft genug gemacht hast.
Das Lösen von Problemursachen kann restriktive Regeln überflüssig machen, sofern man mit offenen Karten spielt kann ein solcher Dialog funktionieren.
Edit: Lösen von Problemursachen/+Korrektur
Ein Einwand, der aber auch jeglicher Sachlichkeit entbehrt. Denn erstens geht es keineswegs darum, die Verwendung von Multipolygonen weitgehend zu verhindern, sondern nur darum, ihren Einsatz auf Kontexte zu beschränken, wo sie gebraucht werden. Zweitens wird das nicht mit Problemen bei ihrer Verarbeitung begründet, sondern bei ihrer Wartung durch die nächste oder übernächste Mappergeneration.
Mit Michaels Firma habe ich nichts zu tun, aber als Mapper unterstütze ich die Initiative, weil es auch mir die Arbeit erleichtert, mich beim Aktualisieren von Flächennutzungen nicht erst in ein MP-Konstrukt hineindenken und bei der Bearbeitung jedes Ways immer alle betroffenen MPs im Blick haben zu müssen.
–ks
Probleme sollten wir dort lösen, wo diese entstehen. Abstrakte Regeln in unserer OSM Wiki, werden ID. Laien und auch HOT User sicher nicht erreichen. Daher mein Vorschlag, dem Editor ID. das Bearbeiten von Multipolygonen vorläufig zu verwehren, und anschließend übrig bleibende Probleme neu zu bewerten.
Und was sind die Ursachen, das es kompliziert statt einfach gemappt wird?
Eine Fläche kann aus einem way erstellt werden.
Warum dann -zig einzelnen way’s die wiederum zu anderen Flächen gehören (können) oder noch schlimmer selbst eigene ways sind.
Ganz einfach für alle!
Wenn etwas nicht einfach dargestellt werden kann, dann eben etwas komplizierter.
Und wenn das nicht langt, kann es spezialisieren werden.
Aber die “Spezialisten” sollten dann nicht "meckern, wenn durch “einfache” Mapper Fehler erzeugt werden: Oder es sich keiner traut dort Veränderungen vorzunehmen, obwohl seit Jahren sich vieles verändert hat.
Ich denke hier kann uns nur eine Auswertung von Neis weiterhelfen.
[Mod Hut auf]
Edit: Anstößiger Text entfernt.
Unterlasse solche Unterstellungen und persönlichen Angriffe.
Ich forder Dich auf, selbigen Text umgehend selbst zu entfernen - ich räume dann die Zitate auf. Solltest Du dem nicht nachkommen droht eine Sperre.
[Mod Hut ab]
+1. So geht es mir auch.
Ich habe mir Deinen Film angesehen. Vielen Dank für die Mühe, die Du Dir gemacht hast! Das ist jedenfalls weitaus konstruktiver als die wilden Beschimpfungen und Verschwörungtheorien, die von MP-Freuden in diesem Thead (und anderswo) schon verbreitet wurden. Allerdings wird es Dich Dich traurig machen, dass Dein Film mich nicht überzeugt hat. Ich halte in diesen und ähnlichen Fällen die im hier diskutierten Proposal vorgeschlagene Arbeitsweise, die MPs auf diejenigen Fälle beschränkt, in denen sie nötig sind, immer noch sowohl für einfacher als auch für wartungsfreundlicher.
+1.
es sind nicht nur Einfriedungen oder gar nur Mauern und Zäune, wo Flächen durch Linien begrenzt werden, und diese Linien auch selbst etwas darstellen. Weitere Beispiele sind retaining walls, cliffs, Küstenlinien, cutlines, tree rows und mehr…
Ich frage mich bei der ganzen Diskussion, wie man bei diesen Regeln Anfängern noch Multipolygone erklären soll.
Der Schlüssel zum Verständnis von Multipolygonen ist doch, dass keinerlei Tags der Member irgendeinen Einfluss auf die Bedeutung des Multipolygons haben und Änderungen am Multipolygon keinen Einfluss auf die Bedeutung der nicht geänderten Linien haben. Exakt so wie bei Ways: Änderungen an den Tags der Stützpunkte einer Linie haben keinen Einfluss auf die Bedeutung der Linie und Änderungen an der Linie haben keinen Einfluss auf die Bedeutung der nicht geänderten Punkte der Linie.
Kann denn das Aufbauen von Regeln für die Zusammenhänge zwischen nicht zusammenhängenden Dingen wirklich Probleme lösen? Mit fällt da der Satz ein: “Die meisten Probleme wurden ‘Lösungen’ genannt als sie entstanden.”
Da hatte ich es nicht gut beschrieben.
Die genannten weiteren “Linienelemente” sollte man nach Möglichkeit auch nicht auf die Flächengrenze / MP-Grenze legen, sondern parallel daneben.
@Weide
“Ich frage mich bei der ganzen Diskussion, wie man bei diesen Regeln Anfängern noch Multipolygone erklären soll.”
Ich hatte als Anfänger auch Verständnisprobleme bezüglich Multipolygone.
Es wird auch MIT Regeln kein von Anfängern leicht zu überblickendes Thema.
Das ist nicht zu erwarten.
Zumindest wir NICHT-Anfänger können aber versuchen die Flächen so neu zu gestalten bzw. um zu gestalten, dass es Anfänger zukünftig leichter haben.
@Pfad-Finder und @Nakaner
+1
Lasst euch nicht entmutigen !
Aha. Würden die Dinge wirklich nicht zusammenhängen, dann hätten wir die Probleme nicht und bräuchten Regeln nicht.
Häufige Wiederholungen machen Deine Aussage
aber auch nicht besser.
Wenn die Fllächenbegrenzungen und die Linienelemente in der Realität deckungsgleich sind, sind sie auch übereinander zu mappen. Alles andere ist noch nicht mal Mappen für die Renderer sondern gegen sie, weil man dann auf der Karte im ungünstigsten Fall Lücken sieht, die keine sind.
Das gegensätzliche Negativbeispiel wäre, das man Polygone mit Straßen verklebt und damit straßenbegleitende Sachen wie Alleen, Straßengräben und Grasflächen ignoriert.
Wir sollten in der Datenbank, die Realität so nah wie möglich abbilden. Die Generalisierungen sind dann Sache der Renderer.
Nochmal: Es geht hier nicht um ein absolutes Verbot/Gebot. Sondern jeder Mapper für sich sollte reiflich überlegen, ob es absolut unvermeidbar ist, in einem konkreten Fall Linienelemente auf eine Flächengrenze zu setzen oder ob es möglicherweise im Interesse späterer Mapper sinnvoller ist, die Generalisierung der on-the-Ground-Wahrheit so auzulegen, dass beides getrennt geführt wird.