mehrfache gestapelte Wege mit vielen Nodes finde ich extrem umständlich zu editieren, man muss alle Knoten selektieren, ungluen, verschieben, und danach ggf. wieder neu verbinden. Nur weil man in JOSM bequem f drücken kann und dann in Sekunden hunderte verklebte Nodes entstehen heisst das nicht, dass man in anderen Editoren nicht große Probleme haben wird, das wieder zu entdröseln.
Für innerörtliche Landuses sollte man m.E. keine MPs verwenden, sondern versuchen, es möglichst kleinteilig zu mappen (z.B. nur innerhalb von Straßen und nicht Straßenzugübergreifend), das ist am einfachsten zu editieren, und skaliert beliebig. Wenn man erstmal ein großes landuse=residential um den Ort zeichnet und dann nach und nach per Multipolygon alle möglichen Flächen wieder davon abzieht, dann entsteht oft nach ein paar Jahren ein “Gestrüpp” von Relationen das keiner mehr anfassen will. Einfache geschlossene Ways mit wenigen Punkten sind da viel besser zu durchdringen und zu bearbeiten.
Ausserorts habe ich hier oft eine ziemlich verschnörkelte Landschaft, wo “Zungen” von Restwäldern in landwirtschaftlich gegliederte Gebiete hineinreichen, die haben oft bis zu hunderte von Nodes wegen ihrer Unregelmäßigkeit, angrenzendes Farmland kann man durch Wiederverwenden der Waldumrisse bequem mit wenigen Clicks mappen, und die entstehenden “Flächenteppiche” (wie das hier genannt wird) sind m.E. einfacher weiterzubearbeiten als derselbe Flächenteppich aus gestapelten Linien, solange sich die Gebiete nicht so weit erstrecken, dass man Probleme hat, sie auf einmal zu betrachten.
Weiterbearbeiten heisst ja oft, dass man noch was gefunden hat, was man zusätzlich irgendwo “dazwischen” einfügen möchte. Mit zwei angrenzenden Multipoligonen muss man lediglich einen Teil des gemeinsamen ways splitten, diesen Teil dann typischerweise aus einer der beiden Relationen rausnehmen, eine neue Grenze zeichnen die an den Splitpunkten verbunden ist, und diese Grenze in die noch offene Relation einfügen, sowie aus der neuen Grenze und dem gesplitteten Way eine neue Relation für das Teil machen, das man ergänzen will.
Ohne Relationen müsste man alle Nodes, die sich auf dem Teil befinden, den man oben gesplittet hat, selektieren, dann ungluen, dann verschieben (damit man noch durchblickt bei den doppelten Nodes), dann so verschieben, dass sich die neue Fläche ergibt. Dann die neue Fläche nochmal komplett zeichnen (in den Platz den man durch das Verschieben geschaffen hat). Je nach Anzahl der Nodes der gemeinsamen Grenzen kommt es drauf an, was weniger Aufwand bedeutet.
Vermutlich gibt es hier ein Missverständnis, weil ich von einem eingezäunten Feld ausgegangen bin (bzw. Zaun/Mauer zur Straße hin, wie es hier üblich ist), und Du den Zaun auf einem anderen Grundstück wähnst als das Feld.
Das hängt auch von der “Intelligenz” des Editors ab.
Bei JOSM ist ein “unglue” unnötig:
Den Weg, nicht mehr zu einer Fläche gehören soll, über zwei Splitpunkte abtrennen, die neue Trennung zum einzufügenden Gebiet zeichnen (daran kommt man auch bei Relationen nicht vorbei). Danach mit C aus der gesplitteten und der neuen Linie die neue Fläche machen und zu Schluss die abgemagerte Fläche z.B. mit (F)olgen an der neuen Linie wieder schließen. (Die letzte Aktion ist die einzige, die man bei Relationen nicht machen muss. Dafür muss man dort Mitglieder löschen bzw. einfügen.)
Es gibt auch noch andere Möglichkeiten, z.B. Aufspalten der alten Fläche mit Alt-X und Verschieben der Trennfläche an die neue Trennlinie, dann noch Umtaggen der abgetrennten Fläche.
Ich kann mich mit beiden Ansätzen bei Flächenteppichen arrangieren, mit “etwas” Übung sind sie kein Hexenwerk (admin-Grenzen z.B. gehen praktisch nur über Relationen). Ich sehe aber pragmatisch, dass Relationen als schwieriger angesehen und deshalb nicht so gern angefasst werden.
Theoretisch magst Du mit der Überlegung (Arbeits-) “Aufwand” Recht haben. Aber die Praxis zeigt, dass sich an die MP-Teppiche niemand rantraut, weil sie mehr (Reindenk-) Aufwand verlangen. Streckenkundler und ich können Dir eine Region an der Landesgrenze Sachsen/Brandenburg nennen, wo seit der Ersterfassung kaum noch etwas tut, weil es zu knifflig ist. (dort kommt noch erschwerend dazu, dass viele Flächengrenz-Elemente gleichzeitig Highway-Tags tragen).
Wenn Openstreetmap nicht das Schicksal von Wikipedia erleiden soll (nämlich das Veralten), sollte alles gefördert werden, was künftigen Mappergenerationen die Arbeit an den Bestandsdaten erleichtert.
Zu Deinem Beispiel: Ich nehme lieber gestapelte Flächen-Ways auseinander als herauszufinden, welche Relation nun links und welche rechts eines gemeinsam genutzten Ways liegen. Und wehe, man vergisst, irgendwelche überstehenden Zipfelchen zu bereinigen oder Lücken zu schließen.
verstehe ich nicht. Wenn Du in JOSM den Weg anklickst, siehst Du im Tags-Fenster alle Relationen, und sie werden auch auf der Karte hervorgehoben wenn Du sie anklickst. In iD klickst Du einfach die Fläche an, und kümmerst Dich gar nicht um die Relationen.
Was mir da grade aufgefallen ist: iD erstellt automatisch und ohne weitere Rückfrage Multipolygonrelationen, wenn man einen Node einer Area selektiert und “split” drückt (als 2. Split-Node sucht iD sich zufällig einen “gegenüberliegenden” aus, wie es aussieht). Wenn man das nun zweimal macht für aneinandergrenzende Polygone dann bekommt man 2 Multipoligone, wo der mittlere Weg doppelt ist, jeweils in einer der beiden Relationen. Das sind die Stellen, die ich zu den unangenehmsten zähle: gleichzeitig mehrere Multipoligone und gestapelte ways an derselben Stelle. Vielleicht kommen Teile der Multipoligonproblematik ja auch daher, dass die Leute einen Editor benutzen, wo sie automatisch Dinge machen, die ihnen gar nicht bewusst sind.
Da ist es egal, sowohl bei Relationen als auch bei (dann nicht mehr) geschlossenen ways machen selbst kleine Lücken (oder Selbstüberschneidungen) die Geometrie ungültig.
https://wiki.openstreetmap.org/wiki/Editor_usage_stats
Josm und iD, die das beide beherrschen, werden für rund 88% der Changesets bzw. knapp 96% der Edits genutzt, im Rest sind z.B. GoMap!! und Vespucci die das auch können. Klar, wenn man darauf besteht mit einem Editor zu arbeiten, dessen Entwicklung anno dazumal aufgegeben wurde, dann braucht man sich auch nicht wundern dass bestimmte Dinge umständlich sein können.
so klar ist das mit dem Wald nicht (obwohl ich es auch so machen würde). Bei Straßen machen wir auch für jede sich ändernde Eigenschaft einen neuen way obwohl der Name ihrer Fortsetzung nicht zufällig derselbe ist, sondern weil wir es logisch als eine Straße sehen. Das zugehörige Datenmodell (street relation) haben wir dagegen weitgehend über Bord geworfen.
Ich finde, Straßen sind ein schlechtes Beispiel. Wenn zwei Wege mit dem gleichen name=xyz sich einen oder mehrere Knoten “teilen”, dann ist es recht simpel, dass wieder zu einem Objekt zusammenzubauen. Bei zwei MP mit gleichem Namen ist das ungleich schwerer.
Bei einem “Wald” ist nicht klar, was dazu gehört, wenn es um den Namen geht. Waldnamen beziehen sich meistens grob auf Gebiete wo Bäume wachsen, aber Lichtungen oder Seen gehören evtl. auch dazu obwohl da keine Bäume wachsen, ggf. gehört die Straße auch zum Wald? Zumindest bei Waldwegen gibt es da vermutlich weitgehend Einigkeit.
Bei Straßen ist es auch nicht klar, weil die nicht immer linear sind sondern auch Verzweigungen und sogar Unterbrechungen haben können, alles nicht so einfach, man kann es oft so oder so sehen.
Danke für den Hinweis. Ich habe den Tenor der Diskussion so wahrgenommen, dass monströse Multi-MPs wie “Pfälzer Wald” unerwünscht sind (Post #234-#239), es aber sauber begründete Fälle für MPs mit mehreren Outer-Ringen gibt (Post #182-#196). In dieser Situation harte Regeln aufzustellen halte ich für aussichtslos. Da entsteht ein Regulierungsmoloch, der am Ende weder dem Mapper hilft noch jede denkbare Konstellation abdeckt. Falls jemand eine wasserdichte Formulierung hat, die nicht länger ist als der jetzige Absatz 2, bitte her damit! Ich denke, dass der jetzige Text von Absatz 2 genügend Spielraum lässt, um in weiser Abwägung jeden Einzelfall angemessen zu würdigen.
User dx125 wies mich auch auf eine nette Konstellation hin… die Radeweger Erdlöcher…https://www.openstreetmap.org/relation/8864899 …eine Sammlung von größeren und kleineren Gewässern gleichen Namens…
Wenn man eine Umgrenzungslinie findet, kann man das zunächst mittels boundary=protected_area + protect_class=7 + ect. erfassen… Damit erfasst man aber nicht, daß die Radewger Erdlöcher als solches ihren Namen haben… Für mich ist diese Situation zunächst einmal ein Fall von einer Relation mit type=site und dem Namen… vielleicht fällt uns da auch was anderes ein…
Man hätte ja etwas schreiben können wie: “Dies ist ein Vorschlag, Multipolygon-Relationen nur dann zu verwenden, wenn eine Lösung mit geschlossenen Wegen nicht möglich ist”. Aber dann hätte man sich den ganzen Rest sparen können.
wenn ich bedenke, wie viele nur die - missverständlichen - Überschriften bzw. Kurzbeschreibung lesen (werden) - werde ich mich nicht wundern, wenn der Schuss nach hinten losgeht … da wird genau das Gegenteil “empfohlen” und “vorgeschlagen”!
Nein, absolut nicht. Ich habe die Passage falsch aus dem Proposal extrahiert. Leider hatte aber Nop schon abgestimmt als mir das aufgefallen ist. Ich mich nicht mehr getraut das zu ändern. Kann man das noch geradebiegen ohne das die ganze Abstimmung von vorn beginnen muss?
