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

Oder wyos Vorschlag aus #128 unterstützen, iD eine Way-Auswahl-Möglichkeit zu spendieren.

–ks

Beispiel 1: forest und residential mit überlappenden Ways
Click:

ALTGR/Click

Beispiel2:
Multipolygon

nachher

Hier wird zwischen der Anzeige des MP-Ways und des gesamtem MP unterschieden.

Hattu auch ALT GR festgehalten und dann geklickt?

Gruss
walter

Klärt erstmal, welche Betrübssysteme ihr jeweils benutzt. Bei Walter vermute ich Ubuntu.

–ks

Ich verwende Windows, da ist weder bei AltGr ein Effekt noch bei STRG+Alt.

um beim Beispiel zu bleiben: https://www.openstreetmap.org/#map=18/50.10967/8.09435&layers=N

Alle folgenden Aktionen jeweils ohne irgend eine Zusatztaste , oder oder so zu drücken!

ersten beiden Bilder:
Klicke ich auf die Linie, kommt zuerst eine der beiden Flächen, beim zweiten Klick dann die andere

das zweite Bilderpärchen:
klicke ich auf eine (mögliche) inner-Fläche: kommt entweder die Innerfläche oder dann die Relation.
Klicke ich auf eine (mögliche) outer-Fläche: kommt entweder die outer-Fläche, die dieser zugehörigen Relation oder es kommt die angrenzende Fläche ohne Relation… wenn diese auch Teil einer Relation ist, dann kommt hier auch noch die Relation…

ich klicke mich also bei der Linien am Mauszeiger nacheinander durch alle Elemente… für mich ideal, kein Problem…

Wenn ich dann noch auf den Stützpunkt selbst klicke, wird auch dieser mit einbezogen. bewirkt nur die Funktion Pan (vergrößern/verkleinern) des ausgewählten Elementes.

Umgebung: Win7 64 Bit, JOSM: 14382

Sven.

PS: mir ist aber so, als wenn wir das Thema mit dem durchklicken der Elemente bei JOSM vor vielen Jahren schon mal hatten (Zeit der 7000er bis 8000er Version??) und eine Einstellung irgend eines Wertes in den erweiterten Einstellungen bei JOSM ein anderes Verhalten hervorrufte (war Chris66 als Fragender involviert?)… Wann das war, weis ich nicht mehr, eventuell kann ich mich aber auch täuschen…

Da geht es mit Festhalten der Alt-Taste beim Klick auf ein Linienbündel. Bei dem, wovon streckenkundler schreibt, ist vermutlich in den Einstellungen etwas umgestellt, dass auch ohne Alt-Taste zwischen den Linien und Relationen durchgewechselt wird. (Alt-Gr und Strg+Alt haben unter Windows die selbe Funktion - bei JOSM zum vergrößern/verkleinern von Objekten).

Edit: Typo und Erklärung zu Alt-Gr/Strg+Alt

Franz

Stimmt.

Aber ich glaube mer schweifen ab. Daher werde ich dieses Thema hier nicht weiter kommentieren.

Gruss
walter

Als bekennender P2-Nutzer sehe ich jetzt auch kein Problem, übereinander liegende Linien zu selektieren: Einen der gemeinsamen Nodes anklicken und dann wiederholt die #-Raute-Taste drücken, bis der gewünschte Linienzug markiert ist.

Wenn iD das nicht kann, ist das in der Tat misslich.

Ich sehe jetzt aber auch keinen Vorteil darin, bei dem konstruierten Beispiel auf ein MP mit 4 Outer-Elementen umzusteigen. Bis ein Außenstehender kapiert, wie sich das MP zusammensetzt, geht auch Zeit um.

Als Pragmatiker würde ich Zaun, Hecke, Bach so zeichnen, dass sie nicht millimetergenau deckungsgleich mit den Grenzen des Landuses sind. In der On-the-Ground-Realität ist das sowieso häufiger der Fall als in den theoretischen Diskussionen in diesem Forum…

+1

Die abstrakte Bachlinie verläuft in der Mitte des Baches - es ist immer ein Abstand zum Wiesenrand vorhanden. Dasselbe gilt für Hecken, Straßen und Mauern und wie tausendmal diskutiert auch für Straßen. Es gibt also keinen Grund die Linien exakt übereinander zu legen.

Ich sehe allerdings auch daß der Thread sich in Detaildiskussionen verzockt hat und das Originalthema verloren hat.

Naja zu 100% kann ich auch nicht sagen, wie das passiert ist, denn wenn Linien zerschnitten werden, wie auch wenn osm-Wegrichtungen von Linien geändert werden, wird (/kann) das von den grafischen OSM-Änderungssatz-Betrachtertools meist nicht so ganz schön transparent angezeigt (/werden). (OT: PS: kennt da jemand einen solchen Viewer der zweiteres anzeigt?)

Von daher gehe ich mal davon aus, dass der iD-Benutzer, der dieses MP erzeugt hatte, vermutlich den (nun alten) Punkt node/359963895 (Dieser ist der interessanteste, da dort die 1D-Linien getrennt sind, sich also von dort beidseitig 2 Wegstücke entfernen, welche zusätzlich Rel.-routeninfo’s enthalten und Teil der anliegenden 2D-Objekt-Flächen sind (also zumindest vor Deiner Änderung waren)) aus unbekannten Grund bearbeiten wollte, dies ihm aber nicht gelang, weil er die von mir zuletzt genannten Bearbeitungs-Optionen a) und b) nicht kannte…

Bzgl. reproduzieren werde ich mal schauen, wenn ich das nächste Mal selbst wieder an so einer Konstrution (verbundene 1D und 2D Objekte) sitze…

i.O. - Nebenbei, jetzt ist Dir mit JOSM wohl genau das passiert, was ich bei Option a) am Ende erwähnt hatte:

Du hast das “wertvollere” Wegstück, welches eine längere Geschichte enthielt gelöscht:
https://pewu.github.io/osm-history/#/way/32063709

Dies scheint zumindest schon mal kein ausschliessliches iD-Issue zu sein :wink: Magst Du dieses Wegstück wiederherstellen?

–snip-- (Beitrag wieder entfernt. Ach, lassen wir’s gut sein, man soll niemanden unnötig reizen :sunglasses:)

OT: man sollte bestimmte Dinge nicht tun, wenn man eigenlich ins Bett müsste…

mache ich Abend.

Sven

Hallo,

ich habe eine Erwiderung auf die Argumente von Jochen Kern in meinem Benutzer-Blog veröffentlicht.

Das ist eine Detailfrage, über die man beim Formulieren der Regelung nachdenken muss. Ich tendiere zu einem überlappenden Way. Mit der mittleren Maustaste ist es in JOSM etwas fummelig zu mappen. Aus der Perspektive eines Autors eines Qualitätssicherungstools bin ich für möglichst wenig Ausnahmen, da diese sich teils schwer herausfiltern lassen und es leider zu viele Mapper gibt, die jede Meldung eines Qualitätssicherungstools für einen Fehler erachten. :frowning:

Ich bin selbst unentschieden und eigentlich denke ich, dass sie der Entwickler in mir dem Mapper in mir unterzuordnen hat. Andererseits weiß ich nicht, ob ein Multipolygon für die Fläche (z.B. ein Umspannwerk) und ein Way für dessen Zaun für einen Mapper mit wenig Multipolygon-Erfahrung einfacher oder schwerer zu bearbeiten ist als zwei überlappende Ways. :confused:

Viele Grüße

Michael

Bearbeiten ist das Eine. Verstehen ist das Andere.
Meiner Erfahrung nach liegt das Problem eher darin, dass “nicht EDV-affine” Mapper das Konstrukt “Multipolygon” bzw. “Relation” nicht verstehen. Man sieht das dann häufig, dass Wälder und dergleichen mit “Löchern” mit einer durchgehenden Linie in einem Zug erfasst werden:
http://tools.geofabrik.de/osmi/?view=geometry&lon=-48.62439&lat=-17.66135&zoom=13&overlays=self_intersection_ways,self_intersection_points,single_node_in_way
Wer mag, der darf das aufdröseln :wink:

Pfad-Finder und Nop sehen das pragmatisch und auch im Sinne des KISS-Prinzips konsequent richtig!

Hallo Michael,

Ich bin gerade wieder mal auf einen Changeset gestoßen, wo ein offensichtlich erfahrener Mapper ein als geschlossene Linie erfasstes landuse=residential in ein Multipolygon mit zwei Inner-Elementen umgewandelt hat. Obwohl ich diesen Faden von Anfang an mit wohlgesonnenem Interesse verfolge, kann ich nach 10 Tagen und fast 150 Beiträgen keine “Community Regeln” erkennen, die mir den Umgang mit solch einem Fall erleichtern. Dabei handelt es sich um eine Situation, die typisch ist für Dörfer überall in Deutschland und dem Rest der Welt.

Soll man hier den Weg des Multipolygons konsequent weiter gehen und alle bereits existierenden Landuse-Enklaven als Inner-Elemente hinzufügen? Oder soll man das Wohngebiet in eine Vielzahl geschlossener Linien aufteilen, die sich weder mit anderen Landuses noch mit Straßen überlappen? Obwohl ich grundsätzlich für das Vermeiden von Multipolygonen bin, würde ich hier doch für die erste Lösung plädieren, weil sie insgesamt weniger aufwändig zu erstellen und zu pflegen ist. Letztlich läuft das auf eine pragmatische Einzelfallentscheidung hinaus und die “Community Regeln” reduzieren sich auf eine einzige Regel: Vermeide Multipolygone wo immer es geht.

Hallo rainerU,

wer sagt denn, dass der gesamte Ort von einem landuse=residential-Polygon umgeben sein muss? Wenn man darauf nicht besteht, kann zwar trotzdem kein Multipolygon vermeiden, aber man hält es klein:

  • Der Teil des Ortes westlich der Rot sollte ein eigenes Polygon sein.
  • Der Teil östlich der Rot sollte eine Multipolygon-Relation sein, die die Bauplätze als Inner enthält, sofern sie nicht am Rand der Fläche liegen. Wenn ich es richtig sehe, hat die Osthälfte nachher fünf Inner, wobei https://www.openstreetmap.org/way/647747089#map=19/48.29996/9.89939 nicht dazu gehören wird.

Viele Grüße

Michael

Entweder das (ich bin im 2felsfall auch für eher kleinräumiges Flächen-Erfassen mit überschaubaren OSM-Objekten). Oder man begreift die Grasflächen als Teil des Wohngebiets. Wenn es keine Viehweiden oder Heuwiesen sind, ist landuse=meadow ohnehin falsch, dann ist es landuse=grass.

–ks

Du hältst also ein Multipolygon mit fünf Inner-Mitgliedern nicht für unerwünscht. Es gibt sicher auch Konfigurationen, wo auch acht oder neun akzeptabel sind. Da frage ich mich, was die ganze Diskussion soll.

Ich habe am Changeset einfach mal nachgefragt, weil wenn, dann sehe ich da noch mehr “inner” Flächen. Ma gucken, was der Kollege antwortet :wink:

An seiner Stelle würde ich antworten: Ok, ich nehme die anderen 13 landuses auch noch in das MP auf. Dann erklärst du mir, dass ich paar davon herauslassen kann. Dann lege ich noch ein paar neue Meadows und Grasses an und nehme die mit in das MP auf. Und am Ende haben wir ein MP mit 10 Inners. Ist es das, was wir wollen?