Nicht alle aber ein nennenswerter Teil unserer MP-Probleme kommt aus unserer bescheuerten Sprechweise in Bezug auf Multipolygone: “ausschneiden”, “zwei Dinge als Multipolygon mappen”, “verschachtelte Multipolygone”. Wir schießen uns damit selbst in Knie. Deshalb mal ein paar provozierende Behauptungen:
Man mappt niemals ein soundso und ein soundso mit einem Multipolygon. Mit einem MP wird immer nur eine einzige Sache gemappt.
Man sollte bei MPs nie über das Ausschneiden von Flächen nachdenken. Nach Beantwortung der Anfangsfrage “Wo ist der Rand dieser Fläche?” sollten im Gedankengang überhaupt keine Flächen mehr vorkommen.
Über verschachtelte Multipolygone braucht man nicht nachzudenken. Jedes MP kann seine eigenen Probleme haben … aber die Verschachtelung macht keine neuen Probleme.
-MPs haben eine ganz große Ähnlichkeit mit OSM-Ways. Niemand kommt auf den Gedanken, dass ein Way seine Punkte “miteinander verheiratet” oder dass die Tags der Punkte irgendeine Bedeutung für den Weg haben. Exakt so wie sich ein Way zu seinen Punkten verhält, verhält sich ein MP zu seinen Members. Ihre Tags spielen keine Rolle und sie werden auch nicht irgendwie “miteinander verheiratet”.
Niemand kommt auf den Gedanken, dass ein Way seine Punkte “miteinander verheiratet” oder
dass die Tags der Punkte irgendeine Bedeutung für den Weg haben.
Hm, ich dachte bisher, dass einzelne Punkt durchaus Bedeutung für den Weg haben: z.B. barrier = bollard, noexit = yes, highway = turning_cycle.
Und MP mit shared outer oder innen sind echt ein Graus …
Ja. Du beschreibst die sinnvolle Anwendung von MPs
Eine abwertende Sprechweise kommt (bei mir zumindest) dann hoch, wenn mit MPs Sachen gemacht werden, die späteres Editieren erschweren.
Dazu zähle ich erstens das Zusammenklicken von kilometerlangen MPs aus Dutzenden von outer-Members. Ist leider in JOSM furchtbar einfach: alle Ways selektieren und Strg-B drücken. Das von mir als Jugendsünde angelegte http://www.openstreetmap.org/relation/5302560 löse ich demnächst mal wieder auf Multi-Outer-MPs sind beim Editieren schon deshalb ärgerlich, weil die Fläche erst dann richtig dargestellt werden kann, wenn sämtliche outers heruntergeladen wurden (was in JOSM zwar einfach geht, aber halt auch gemacht werden muß). Davor zieht der Editor gezwungenermaßen gerade Verbindungslinien zwischen den Endpunkten der ihm schon vorliegenden outers, was zu der Annahme verleiten kann, da stimme etwas nicht. Und wenn er bei einem Monster-MP noch gar keine Outers heruntergeladen hat, merkt der nächste Bearbeiter gar nicht, daß er sich in einem MP befindet, und mappt Teilflächen zwangsläufig falsch.
Dazu zähle ich zweitens das Zusammenfassen mehrerer separater Flächen in einem MP (ja, man kann mehrere Sachen mit einem MP mappen, wenn auch keine unterschiedlichen), z.B. alle landuse=farmland um ein Dorf herum. Das ist IMHO kompletter Unsinn – wo liegt da der Vorteil gegenüber einzelnen geschlossenen Ways? Auch das erschwert nur späteres Bearbeiten.
Multipolygone sind kleinräumig eine sehr gute Sache. Man muß nur wissen, wann man aufhören muß.
Für den Weg ja, aber nicht für den Way Dem OSM-Way ist es vollkommen wurscht, ob jeder seiner Nodes ein barrier=nato_wire trägt. Erst demjenigen, der der Way als Weg benutzen will, ist es nicht mehr egal.
Ein einzelnes MP mit begrenzter Menge an Members und klar erkenntlichem Zweck kann man normalerweise verstehen und dann auch editieren.
Für den Computer ergibt sich bei Verschachtelung nichts neues. Für den Menschen geht allerdings schnell der Durchblick wie die Dinge zusammenhängen und welche Änderung welche Folge hat verloren. Von daher macht es in der Praxis einen gewaltigen Unterschied.
Für mich ist das, was “zwischen den Rändern liegt”, die Fläche. Das ist für mich ein abstraktes GIS-Objekt, mit dem ich in weiteren Schritten arbeite.
EIN MP → EIN Objekt: simple.
EIN Rand oder mehrere Ränder → EIN Objekt: komplex
Für mich beschreibt ein MP eine Fläche. Und ich mache danach mit Flächen Abfragen wie "was liegt hier drin? (st_contains), “welcher Teil der Strasse liegt in welche Stadt?” (st_intersects) oder “wie gross ist die bewohnte Fläche der Stadt?” (st_area), …
Da interessieren mich die Ränder überhaupt nicht.
Deine Aussage verstehe ich nicht ganz: Sind verschachtelte MP für dich nun “gut” oder “böse”?
Für mich sind die “sehr böse”.
Ich hab nicht deutlich genug gemacht, dass es mir um die technischen Schwierigkeiten beim Erzeugen oder Beurteilen der Richtigkeit von Multipolygonen geht.
Es geht mir also hier nicht um die Nutzung fertiger MPs, sondern hauptsächlich um das Anlegen. Da sollte man nicht an das Addieren oder Subtrahieren von Flächen denken, sondern einfach an das Erfassen aller Ränder.
Auch bei den Verschachtelungen geht es mir nicht um Sinn oder Unsinn von so etwas. Es geht mir darum klar zu sagen, dass man mit dem Verständnis normaler Multipolygone auch verschachtelte verstehen, beurteilen und ändern kann. Es gibt keine zusätzlichen Verschachtelungsregeln oder Ausnahmen, die man gesondert lernen müsste.
Je mehr technische Probleme man hat, desto eher besteht man auf der gewohnten Lösung der Probleme und desto weniger ist man offen für Diskussionen über Vereinfachungen und bessere Lösungen.
+1 (ebenso für den Rest). Eine super Formulierung, mit der fast alles gesagt ist! Nur leider wird sie offenbar verschieden verstanden, genau wie bei den Alloholica, bei denen man ja auch “wissen [muss], wann man aufhören muss”: man kann offenbar nach MPs regelrecht süchtig werden. Jedenfalls drängt sich mir dieser Eindruck auf, wenn ich an unseren MP-Freak denke, der auf “seiner” Wiki-Seite nicht einmal einen laschen Warnhinweis dulden will [1], und an Orte, in denen sogar simple Gebäudeumrisse als MPs gemappt werden, nur weil sie einen Wandabschnitt teilen …
Jedenfalls drängt sich mir dieser Eindruck auf, wenn ich an unseren MP-Freak denke, der auf “seiner” Wiki-Seite nicht einmal einen laschen Warnhinweis dulden will [1], und an Orte, in denen sogar simple Gebäudeumrisse als MPs gemappt werden, nur weil sie einen Wandabschnitt teilen …