Supaplex030 (2024-04-08 20:08:00+00:00): Hallo Wilfried,
ich hoffe du hattest einen guten Urlaub :) Und Danke für deine Rückmeldung hier.

Zu (a): Der einfachste Grund, warum es sinnvoll ist, zwei verschiedene "deckungsgleiche" Objekte auch in zwei verschiedenen Geometrien zu erfassen, ist, dass diese Objekte auch spezifische Eigenschaften (wie Höhen, Materialien, Oberflächen, Farben...) haben, die zwar oft – zumindest am Anfang – nicht erfasst werden, aber mit der Zeit hinzukommen (können). Teilen sich mehrere Objekte eine Geometrie, lässt sich nicht mehr klar zuordnen, auf welches Objekt sich ein solches Subtag bezieht.

Es ist nicht schlimm, wenn man diese Trennung bei der Erfassung von Objekten nicht umsetzt, da solche Attribute ja – wie gesagt – ohnehin oft (noch) nicht detailliert erhoben werden, aber wenn die Geometrie schonmal getrennt ist, sollte man sie nicht mehr zusammenführen.

Eine "Datenredundanz" entsteht dabei eigentlich nicht, denn Linien sind in OSM nur eine Sammlung ihrer Stützpunkte und die Stützpunkte sind ja identisch.

In der Tat ist es insbesondere für neue User nicht immer einfach, aufeinander liegende Geometrien/Linien zu unterscheiden – alle Editoren bieten dafür aber Möglichkeiten, sich durch die deckungsgleichen Geometrien zu wählen und aufeinander liegende Linien sind kein ungewöhnliches Phänomen in OSM.

Ja, im Datenmodell von OSM gibt es derzeit keinen Datentypen für Flächen, sondern diese müssen bei der Interpretation der Daten für geschlossene Linien abgeleitet – in machen Fällen schlicht geraten – werden. In jüngerer Zeit wird darüber wieder vermehrt diskutiert und es gibt Überlegungen, einen Datentypen für Flächen einzuführen (siehe insbesondere die Studie von Jochen Topf im Auftrag der OSM Data Working Group aus dem Jahr 2022: https://media.jochentopf.com/media/2022-08-15-study-evolution-of-the-osm-data-model.pdf).

Sollte dies eines Tages passieren, wäre es spätestens dann – je nach Implementierung – keine gute Idee mehr, linien- und flächenhafte Objekte in einer Geometrie abzubilden. (Ja, Bordsteinkanten sind Linien und keine Flächen, eine grasbewachsene Fläche hingegen keine Linie – der Ufervergleich hinkt hier etwas, da das eine mit dem anderen nichts zu tun hat, sondern in manchen Fällen eben nur am gleichen Ort auftritt.)

Zu (b): Man muss hier ganz klar zwischen Warnungen und Fehlern unterscheiden: Fehler sollten nach Möglichkeit behoben werden, Warnungen sollen die Aufmerksamkeit des Users auf eine "Datensituation" lenken um zu schauen, ob hier ggf. Handlungsbedarf besteht. Je nach dem, wo man sich befindet bzw. wie die Daten an einem Ort erhoben wurden, besteht in den meisten Fällen aber gar kein Handlungsbedarf.

Erfahrungsgemäß nimmt der Anteil von "Fehlalarmen" zu, je detaillierter/komplexer/kleinteiliger Daten in OSM erhoben wurden. Daten-Validatoren wie die Warnungen von JOSM arbeiten festgelegte Regeln ab, die eben manchmal zu unspezifisch sind – dafür lassen sie sich dann aber einfach und weltweit anwenden und warnen vor allem unerfahrene User vor möglicherweise versehentlichen Kartierfehlern. Das ein User beispielsweise zwei mal die selbe Linie (mit unterschiedlichen Attributen) zeichnet, könnte in vielen Fällen tatsächlich ein Versehen sein, den User dank des Validators dann korrigieren können. In anderen Fällen (wie hier) ist es Absicht, aber das kann die Regel nicht wissen.

Insbesondere sollen Warnungen helfen, selbst erstelle Daten zu prüfen. Bei bereits bestehenden Daten ist die "Fehlalarm-Quote" mMn sehr hoch. (Ich kann im Übrigen gar nicht nachvollziehen, auf welche Warnungen du dich in JOSM beziehst, denn ich sehe in den hier diskutierten Fällen gar keine Warnungen – möglicherweise, weil ich "unwichtige" Warnungen nicht aktiviert habe. Es gibt dafür diverse Einstellmöglichkeiten.)

Einen Satz, den ich in OSM-Diskussionen schon häufiger gelesen habe, ist jedenfalls: "Warnungen kannst du ruhigen Gewissens ignorieren, wenn du sie nicht selbst produziert hast."

Zu (c): Ich weiß nicht genau, worauf du dich hier beziehst, aber grundsätzlich haben wir wohl keinen Dissens, dass das Wiki normalerweise eine gute Leitlinie ist (da OSM-Diskurse hier am ehesten dokumentiert werden) und sich Editoren daran orientieren sollten.

Ich befürchte aber, dass wir hier über Dinge diskutieren, die im Wiki nicht so klar beschrieben werden, da letztendlich keine der Varianten "falsch" ist, sondern sich für verschiedene Mapping-Situationen anbieten und mit den beschriebenen Vor- und Nachteilen behaftet sind.

Ich hoffe, du kannst meine Motivation jetzt besser nachvollziehen, die mich zu dem Kommentar bzw. dem Revert hier geführt hat?

lg, Alex