Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

Generell verstehe ich nicht, warum immer wieder von Regeln gesprochen wird. Ich verstehe die Punkte als offizielle Empfehlungen (ohne verbindlichen Charakter, also auch ohne drohende resultierende Benutzersperren), die hiermit aber nochmal gesammelt und später explizit bekannt gemacht werden sollen, zu denen dann immer mal verwiesen werden kann und/oder die sich später jeder (der dazu steht) selbst in seiner lokalen (wiki und/oder OSM)-Profilseite einbinden kann.
Korrigiert mich gerne, falls ich damit falsch liege.

Ach stimmt, dann müsste eigentlich nicht nur wie bereits geschehen im Proposal von ‘Regel’ zu ‘Empfehlung’ geändert werden, sondern dann müsste auch der Titel hier im Faden dementsprechend angepasst werden :wink:

Ohne Gewähr auf OT Ab-/Ansätze bzlg iD-Editor, hängt aber teilweise mit MPs und Relationen zusammen.

Super, freut mich falls meine Anregung zur Aktion geführt hat :slight_smile:

Würde ich nicht so sagen, iD ist immerhin noch mein Lieblingseditor :slight_smile:

Schade ist natürlich, dass Du die Anleitung (noch) nicht fertigstellen konntest :frowning:

ABER, vielen Dank für den Verweis zu dem Ticket auf der “help”-Seite!
Ich habe mich nämlich von dort auf 2 weitere Ebenen (bei github) durchgeklickert und bin dann bei einem sehr interessanten Beitrag[1] gelandet. Dort wird ein Workaround beschrieben, wie für die Aufteilung(Zerschneidung) eines Flächenelements eine unerwünschte (die Merkmale werden auf die einzelnen Mitglieder verteilt und stehen nicht mehr übergeordnet an der Relation) MP-Erstellung vermieden werden kann.

Das hilft ungemein und spart schon mal viel Zeit. Das kann man nämlich auch anwenden, um 1D und 2D Objekte zu trennen, die unnötig verbunden sind. Also wenn sich beim 1D/2D-Verbund das 1D Objekt zusätzlich noch zu Routenrelationen zugeordnet ist, denn dann sind die 1D way-Endpunkte (sehr ähnlich wie bei MP-Konstrukten mit nur Outer-Ringen) wie verschweisst.

Keine Ahnung, ob es Dir hilft, die in [1] erwähnte Methode in der von Dir angestrebten iD Anleitung einzubauen.
Generell, könnte diese Methode von [1] auf irgendeiner wiki-Seite, auf welcher es um solche Themen geht, eingetragen werden?

Also vielen Dank nochmal für die Wegweisung zu diesem interessanten Workaround!

Nichtdestotrotz kommt sehr vermutlich für Neumapper weder die JOSM Anleitung noch die etwaig kommende iD-Anleitung in Frage zwecks der Handhabung von MPs, von daher bitte MPs mit nur Outer-Ringen gerne vermeiden, dort wo es eben geht.

Ansonsten weiterhin bitte den iD-Editor nicht einfach abschalten wollen, sondern bitte entweder bei Issues Änderungsideen eintragen, oder bei Pulls fertige Softwareänderungen zu Problemlösungen zur Einbindung vorstellen.
Kann man bestimmt auch in Deutsch eintragen, die Softwarespezialisten beherrschen heutzutage sicherlich: Anfragen-Beispielübersetzung Das Übersetzer-Tool kommt ja netterweise mittlerweile auch ab und zu in der Wochennotiz zur Anwendung :slight_smile:

Hier auch mal was positives zum iD-Editor, seit der neusten Version 2.12 wurden wieder eine Menge neue Sachen implementiert, siehe:
https://github.com/openstreetmap/iD/blob/master/CHANGELOG.md#2120
Einen ziemlich grossen Anteil hat wohl dieser Benutzer:
https://github.com/quincylvania
der seit ca. 3 Monaten aktiv ist. Vielen Dank dafür! :slight_smile:

Ein kleiner Höhepunkt ist, das einige Funktionen hinzugekommen sind, die die Handhabung und die Anzeigetransparenz von Relationen betreffen:
=> z.B. wenn man rechts mit der Maus über Relation fährt werden jetzt die Linien der Relationsmitglieder hellblau hinterlegt angezeigt
Habe das ausprobiert und auch damit bereits Routen(Bus/Rad)rel.-Lücken geschlossen, dies spart eine Menge an Zeit…

[1] https://github.com/openstreetmap/iD/issues/969#issuecomment-350927272

Bitte nicht immer wieder dasselbe Fass aufmachen:

ja, der Bauer wird aus technischen Gründen wahrscheinlich einen Abstand halten müssen zum Zaun, man kann diese Fläche zwischen Zaun und gepflügtem Feld aber wohl als landuse=farmland sehen, oder siehst Du das anders?

Man kann diesen Streifen jenseits des Zauns aber auch als uneingefriedete Fortsetzung der Kuhweide ansehen. :slight_smile:

Der springende Punkt ist aber ein ganz anderer: Thema der ganzen MP-Diskussion ist doch die Wartbarkeit und (Un-) Übersichtlichkeit des Datenbildes. Die Empfehlungen sollen jeden Mapper dafür sensibilisieren, dass er es selbst in der Hand hat, ob es in fünf Jahren einem anderen Mapper leicht- oder schwerfällt, Daten zu ändern. Es liegt meines Erachtens auf der Hand, dass die gemeinsame Führung von Flächengrenzen und Linienelementen in den meisten Fällen (nicht allen*) das Editieren eher erschwert als erleichtert.

*) so ein Fall könnte zB das erwähnte Umspannwerk sein. Wenn da noch mal angebaut oder rückgebaut wird, bleibt der Zaun immer noch auf der Flächengrenze.

ja, das sehe ich anders. Aus rechtlichen Gründen hat nicht der Bauer Abstand zum Zaun zu halten, sondern der Zaun Abstand zum Feld. Damit gehören die 50cm zwischen Zaun und Feld rechtlich zu dem Grundstück, auf dem der Zaun steht - völlig gleich wie dieses genutzt wird - und definitiv nicht zum farmland. Nachzulesen in nahezu jedem Nachbarrechtsgesetz der Bundesländer.

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.

Ich nix JOSM. Ich P2. :slight_smile:

OT: Schön, wenn ein Editor das kann. Aber OSM wird von mehr als einem Editor erstellt.

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.

Ich habe noch einen Kommentar auf der Wiki-Seite gefunden, möglicherweise wurde das aber hier schon diskutiert:

Gibt es in dem Punkt noch Klärungsbedarf?

Abgesehen davon sind nun, soweit ich das sehe, alle Fronten geklärt. Ich würde (nach Klärung des o.g. Kommentars) vorschlagen, zur Abstimmung überzugehen (dokumentiert im Wiki unter: https://wiki.openstreetmap.org/wiki/DE:Proposal_process#Abstimmung).

Tigerfell

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.

Ich habe es noch nie benutzt, aber vielleicht hilft da das wikidata oder wikipedia tag?

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.

https://wiki.openstreetmap.org/wiki/DE:Proposed_features/Empfehlung_zur_Verwendung_von_Multipolygonen

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…

Er schickte mir auch ein Foto eines Schutzgebietsschildes: https://upload.wikimedia.org/wikipedia/commons/8/8b/Radewege_erdel%C3%B6cher.JPG

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…

Sven