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

Ich sehe da keine Fehler. Zwei Member mit Outer, die miteinander verbunden sind, der Rest sind inner, mit denen aus der Wiese ausgestanzt wird.

Nach Sichtung in JOSM ist das so.

Meine Ansicht zu diesem speziellen MP: zu groß, zu schlecht bearbeitbar. Es müssten jetzt eigentlich noch mehr Flächen, die bereits gemappt sind (und weitere die noch zu mappen wären, da nicht “Wiese”) als inner zum Wiesen-MP hinzu, dann wird es noch unübersichtlicher. In meiner Region würde ich so etwas zerlegen in übersichtlichere kleinere Einheiten. Spätestens an der nächsten größeren Straße, Bahntrasse, Kanal hat das MP aufzuhören :wink:

Die Diskussion hier belegt, dass das MP nicht ohne weiteres wartbar ist → Zerlegen! :slight_smile:

Ich fange jetzt mit dem Zerlegen an und bitte alle Anderen, dieses MP und alles was innerhalb ist, bis auf Weiteres nicht anzufassen,
damit man sich nicht ins Gehege kommt :wink: Wird sicher nicht perfekt, aber besser als der Ist-Zustand.

Mit der Abwicklung dieses MPs bin ich jetzt durch: es ist weg!
So was braucht niemand. Dort nicht und Anderswo meist auch nicht.
https://nrenner.github.io/achavi/?changeset=64581915
Es hatte etwas über 20 Elemente und war damit von der Größe her noch “im Mittelfeld”, z.B. links nebenan liegt Eines mit 69 Elementen…

Langweilig :wink:
Versuch mal die natural=wood MP in Japan zu verbessern, so eines wie dieses gibt es dort überall:
https://www.openstreetmap.org/relation/1330990
Knapp 600 Wege, keiner davon auch nur annähernd in der richtigen Position. Wenn ich den Import-Müll sehe, denke ich immer, in D ist es ja noch recht harmlos.

Besser spät als nie:

+1.

Während ihr die Multipolygone aufdröselt, klebt gerade ein Südkoreaner alle Wälder in seinem Land zusammen: maphunter36 - bislang hat er nicht auf Ansprache reagiert.

Ich habe mal bei der Abfrage in Zeile 11 das “> 1” durch “>= 1” ersetzt. Damit werden auch die MP gefunden, die nur einen outer haben, also eine ganz normale Fläche sind. Wäre das OK, oder handle ich mir damit Probleme ein (z.B. false-positives, d.h. es werden MP angezeigt, die tatsächlich so korrekt gemappt sind)?

Jetzt muss ich mal blöd nachfragen: Ist es jetzt angesagt, auch vollkommen korrekte MP zu entsorgen, nur weil sie nicht nötig sind? In meiner Heimat haben andere Mapper so ziemlich alle Flächen als MP erfaßt. Ich fasse die eigentlich nur an, wenn ich die Bedeutung ändern will, sprich, wenn etwas falsch oder nicht mehr aktuell ist. Kann ich aber erst machen, wenn neue, bessere Luftbilder da sind.

In meinen Augen Ok…

MP’s mit nur einem Outer und keinem inner können durch simple Flächen ersetzt werden oder wenn der Outer-Ring nicht geschlossen ist, es eh ein Ringfehler…

Sven

Frage doch per CS oder PN die Mapper ob er mal hier ins Forum schauen kann. Dann kann er auch seinen Standpunkt (vielleicht vor Jahren) darlegen. Oder er stimmt dem sogar zu.

Meine Meinung und Absicht: Nur Ändern des Änderns wegen halte ich für nicht richtig. Da kann man seine Zeit sinnvoller investieren. Wenn jedoch bei der Zerlegung der Multipolygone gleichzeitig das in OSM Erfasste mit neueren Luftbildern abgeglichen wird und es auch zu inhaltlichen Verbesserungen kommt, ist es in Ordnung.

Wenn man Multipolygonfehler repariert, weil ein Mapper eines zerschossen hat, und sich in einem Multipolygon-Teppich wiederfindet, kann man aber schon das betreffende Multipolygon und seine Nachbarn zerlegen. Es sollte einen Anlass für das Zerlegen geben.

+1

Danke für die Rückmeldung.

MP’s mit nur einem Outer, mein Kommentar zu diesen hier https://forum.openstreetmap.org/viewtopic.php?pid=726318#p726318

Die Situation für Östereich kenne ich nicht und ich werde mich auch mangels Ortskenntnis und aufgrund der doch etwas größeren Entfernung von Südbrandenburg weitestgehend aus dem Mapping in Österreich raushalten. So richtig kann ich aber deine Aussagen aber nicht nachvollziehen…

Hier mal eine Abfrage von 1-Elemente-Relationen für Brandenburg: http://overpass-turbo.eu/s/DOl…ist doch SEHR überschaubar.

Was aber meiner Ansicht nach durchaus ein großes Problem ist, sind übergroße Acker- und Waldmultipolygone deren Ursprung neben einzelnen Mappern vor allem auch in den Landsat-Zeiten zu suchen sind. In meinen Augen hat es sich oft keiner die Arbeit machen wollen (oder getraut), die Dinger überhaupt mal in annehmbare Größen zu zerteilen. Viele dieser MP’s schließen (besser schlossen) hier gut und gerne mal 2 bis drei Ortschaften ein und landuse=farmland ist über alles drübergebügelt, was nicht bei drei auf den Bäumen ist… Wiese, Buschland, Forst, Wald, ect…

Wenn dann noch hinzukommt, daß das MP-outer aus mehreren Linien, womöglich auch noch Straßen zusammengesetzt ist, ist es selbst mit JOSM ein echte Qual, dort wenigstens simple Geometriefehler zu beseitigen, geschweige denn mal eine Teilfläche zu aktualisieren. Mich haben schon gelegentlich Mapper angeschrieben und darum gebeten, mal hier in Brandenburg das eine oder andere solche Riesen-MP zu zerteilen, ich hab das dann auch gerne gemacht, auch weil dann der Wiederstand von iD-Mappern auch in diesen Arealen mal was zu machen, nicht mehr gegeben ist.

Sven

Möchte an dieser Stelle an meinen im Frühjahr im AT-Forum gestarteten Thread erinnern. Hier habe ich die Situation im Grenzgebiet AUT-HUN-SLO angemerkt, ganz besonders auf der HUN-Seite. Von den HUN-Mappern bin ich mehrmals per Privater Nachricht via OSM.org z.T. wüst beschimpft worden, weil ich begann, MPs zu zerteilen, zu aktualisieren - kurzum: wartbar zu machen. Denn, die Region entstammt (halb-)automatischen Imports aus den 2000er Jahren und vieles ist nicht up to date dort.
Meiner Meinung nach sollte es generelle Regeln für MPs geben, nicht nur rein nationale (DE/AT oder so) im Speziellen was deren Größe (Fläche wie auch Mitglieder des MP) betrifft.

Ja, die Größe ist oft das Problem… Ich habe mich am Wochenende hier in Brandenburg dahingehend herangetastet, daß derzeit Zunächst MP’s mit zwei oder mehr outer-Rollen und mehr als 25 inner-Rollen einer näheren Betrachtung unterzogen werden können… nicht jedes ist aber ein Kandidat für eine sinnvolle Verkleinerung, da hier zum Teil sehr strukturreiche größere Waldlandschaften gibt. MP’s in Ackerlandschaften hingegen sind für mich prädestiniert dafür, verkleinert und vor allem detailliert werden zu wollen.

Sven

[Mod-Edit: Beleidigende Inhalte entfernt]


Nochmal: Die Welt ist kein /Siedler von Catan/ - Spielbrett, wo man die einzelnen
Flächen greifen und nach Belieben neu rekombinieren und aneinanderlegen kann (und wo
auch immer eine noch so kleine Lücke tatsächlich zwischen den Hexagon-Plättchen
verbleibt).

Flächen und Flächengrenzen der Realität sind hingegen kontinuierlich, sie fließen
ineinander über, selbst dort wo der Mensch Anlagen installiert, um sie sichtbar bzw.
unüberwindbar werden zu lassen. Multipolygone werden diesen Aspekt in besonderem
Maße gerecht, weil sie diese Beziehungen von Flächen der Realität unmittelbar ab-
bilden.

Es ist Unsinn Flächen der Realität ohne ihre Nachbarn denken zu wollen,
genau das passiert aber bei der Nutzung von “closed ways” als Flächenersatz: Sie
verletzen in der überwiegenden Zahl der Fälle zwei Gebote aus den “best practices”
die das Projekt sich selbst gegeben hat:

  • Bilde die Realität vor Ort ab (“ground truth”).

  • Benutze ein OSM-Objekt für ein Objekt der Realität (“one object, one feature”).

Zu “ground truth” ist der Fakt zu beachten, dass fast alle Flächen keine homogene
Flächengrenze besitzen (“closed ways” aber genau das modellieren). Werden mehrere
angrenzende Flächen durch “closed ways” modelliert, werden i.d.R. mehrere Flächen-
grenzobjekte mehrfach modelliert, wodurch eine Verletzung des zweiten Gebots
stattfindet - und zwar _regel_mäßig.

Außerdem bieten “closed ways” bis heute keine klare semantische Separation der Tags,
die entweder das lineare Feature oder die umgebene Fläche bezeichnen können. Ein
beliebtes und anschauliches Beispiel hierfür ist das Tag barrier=hedge, welches auf
einem “closed way” sowohl den Flächenumriss, als auch den Flächeninhalt auszeichnen
kann. Diese semantische Uneindeutigkeit besteht mit Multipolygonen nicht, und es
ist bei konsequentem Einsatz von MP klar, dass Tags auf den Flächengrenzen bzw.
Flächengrenzsegmenten stets das lineare Feature und nicht die umgebene Fläche aus-
zeichnen.

“closed ways” sind eine Krücke aus den Anfangstagen von OSM, in denen man glaubte,
man käme ohne eine klare Separation von Flächen- und Wegtypen aus. Allein die frühe
Ergänzung von Multipolygonen als Relationstyp zeigt deutlich, dass man da falsch
lag und diese Separation wichtig ist, gerade wenn man Daten in einem sich evolutionär
weiterentwickelnden Datenmodell richtig interpretieren will: Da der Katalog an Tags
nicht abgeschlossen bzw. abschließbar ist, lässt sich auch nicht definieren,
welche Untermenge davon auf “closed ways” nun zur Interpretation als Flächentag bzw.
Umrisstag führen solle.

Die bisherigen Diskussionen sind zum großen Teil dem Entwicklungsstopp der OSM-API
geschuldet, die noch nie einen dedizierten Flächentyp unterstützt hat und eben diese
Interpretation Nutzern und Anwendern (mit häufig mangelhaften theoretischen und
praktischen Kenntnissen) seit Jahren bzw. Jahrzehnten überlässt. Warum die deutsche
Community das nicht erkennt und stets mit Regeln und Verboten versucht irgendwas im
“nationalen Alleingang” (das dann natürlich als internationales Vorbild zum Selbstläufer
werden soll) zu richten, ist mir unbegreiflich. Evtl. kann sie mit der entstandenen Viel-
falt nicht umgehen, oder sie versteht sie eben nicht. Diejenigen die “closed ways”
als Krücke sehen, versuchen schließlich auch nicht -weder mit mechanischen edits
noch mit pseudo-legitimierten Regelungen- alles in ein MP-Korsett zu zwängen.

Eine wirklich nachhaltige Lösung kann m.E. erst stattfinden, nachdem man sich dazu
entschieden hat, einen bestimmten Flächendatentyp durch die API serverseitig anzu-
erkennen und zu unterstützen. Solange aber serverseitig alles erlaubt ist, wird die
Vielfalt in der Datenrepräsentation mitsamt Konflikten und Diskussionen weiterhin
Bestand haben.

PS Die Verwendung des Terminus “Overpass Turbo” im Changeset Kommentar war
in der Tat ein Schreibfehler, man möge es verzeihen.