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

“Verbreitet” ist so einiges ungutes, ich behaupte ja nicht, dass dies illegal wäre, ich sage nur,
dass die dabei generierten “Multipolygonalen Schein-Enklaven”
https://www.openstreetmap.org/relation/6946674#map=18/48.18523/11.86931
(hier an einem highway=secondary)
geometrischer Pfusch sind, der langfristig dann ohnehin verbessert werden muss.

OT:Wie kann man eigentlich den Buhcstabnedreher in der Überschrift korrigieren?

Dsa knan nru dre Thraed-Eröffenr.

–sk

Danke für den Hinweis, ich habe es erledgit.

Vielen Dank für eure Beiteiligung bislang. Ich werde mir eure Kommentare mal in Ruhe nochmal durchlesen und prüfen, für welche Teilaussagen zu Multipolygonen die Aussage “Das ist ein wohl recht breiter Konsens im OSM-Forum” richtig ist. Die Mailingliste Talk-de werde ich selbstverständlich nicht außer Acht lassen und auch dort um Kommentare bitten, bevor ich einen Entwurf verbreite.

EDIT: “und auch dort um Kommentare bitten, bevor ich einen Entwurf verbreite” ergänzt.

k.A. muss irgendeinen Grund gehabt haben… :confused: in 10 Jahren ändert sind ja einiges :wink: Änderungssatz war mit 3D die Kirche… immer wieder schön :slight_smile: :slight_smile: http://demo.f4map.com/#lat=48.1916560&lon=11.8687841&zoom=19&camera.theta=62.762&camera.phi=-9.167

Ich würde ganz stark vermuten, daß das die Möglichkeiten von Overpass leider übersteigt… Für “Touching inner Rings” müsste ausgewertet werden, ob bei den Inner-Rollen innerhalb eines MP’s mindestens zwei der aufeinanderfolgenden Stützpunktkoordinaten gleich sind.

Typischerweise ist das aber eine (geometrische!) Topologieregel, die man erst wirklich gut beim Vorhandensein des echten Datentyps Polygon prüfen kann(*)… In Verarbeitungsschritten von OSM zu PostgreSQL kan man das sicher dann machen, allein auf Basis von reinen OSM-Daten dürfte das schwierig werden.

(*) den OSM aber eben noch immer nicht nicht hat, was wiederum begründet, daß OSM für solche Flächen eben diese MP-Konstrukte für Flächen hat…

An der Stelle hinken übrigens auch irgendwelche Vergleiche, welcher Mapper wieviel Relationen angelegt hat… Es gibt in der Zahl angelegter Relationen pro User keine Aussage, wie sich diese auf solche hier besprochenen (durchaus notwendigen) Flächenkonstrukte beziehen, oder auf z.B. (linienhaften) Routenrelationenen, ect. (=andere in OSM verwendete Relationstypen) verteilt. Es ist zunächst nur eine stupide, nichtssagende Zahl…

Sven

Mit dem Marktschwaben-Residential kann ich pragmatisch betrachtet leben. Es ist flächenmäßig nicht bildschirmsprengend, es gibt nur ein Outer, und ob man eine Secondary durch eine Wohnbebauung als Unterbrechung desselben ansieht, ist Geschmackssache. Bei einer Autobahn sähe ich auch eine “Trennwirkung”, aber bis hin zur Bundesstraße (nicht: Kraftfahrstraße) halte ich es für vertretbar, ein residential drüberzuziehen. Trennen würde ich dann nur, wenn a) die Ortsteile beiderseits der Straße zum Beispiel eigene Namen haben oder b) ein Gesamtresidential bildschirmsprengend groß wäre.

Ortrand https://www.openstreetmap.org/#map=16/51.3704/13.7599 und Kraußwitz ist so ein ganz klarer Fall - an der Bebauung beiderseits von Grenzstraße/Grenzweg ist kein Unterschied zu erkennen, aber im Norden ist Ortrand in Brandenburg und im Süden Kraußwitz in Sachsen.

Naja du schreibst ja schon selbst “Trennwirkung”… wenn man hier auf die Sprache achte dann sagt man ja auch man fährt durch eine Ortsschaft und nicht links und rechts liegt die Ortsschaft… oder man fährt durch den Wald… und im Wald ist ein See usw. usw. Trennt man das kann man diesen Bezug nicht mehr leicht herstellen bzw. nur schwer… also kann mit viel mühe auch der Schuss auch nach hinten gehen… :confused:

So wie hier… fahr ich da durch oder liegt das links und rechts… maxspeed=50 könnte da helfen… https://www.openstreetmap.org/relation/6292132 . Außerdem die Linien neben der Straße finde ich sehr störend beim mappen… was ich auch gut und gern auch auflöse wenn ich dort was mappe… :expressionless:

mfg Miche

Nein. Da habe ich miss missverständlich ausgedrückt. Ich war wohl implizit davon ausgegangen, dass wir über die Split/Teilen-Operation (Scherensymbol) sprechen. Habe es oben editiert.

Trennen teilt weder Weg noch Fläche.
Teilen (Scherensymbol) teilt den Weg, aber nicht die Fläche, da das Multipolygon erstellt wird.
Ein ein wirkliches Teilen der Fläche, wird in iD bisher nicht direkt unterstützt.

iD teilt keine Flächen. Was schon lange vorhanden ist, ist das Ticket auf Github.

Moin…Im Zuge einer Bearbeitung in diesem Gebiet, bin auf diese Relation gestossen.
Macht die überhaupt Sinn ?

https://www.openstreetmap.org/relation/3203488#map=13/53.4558/8.4842

Dies könnte man aufteilen entlang der durch das Multipolygon verlaufenden Strassen, Bahntrasse und was sich sonst noch anbietet, natürlich ohne Verkleben, sondern parallel. So ein Multipolygon sollte man in der vorliegenden Form nicht neu anlegen, das kann man kleinteiliger gestalten, und die (meisten) MP-inner sind als normale Relationen möglich, das kann man mit JOSM gut umbauen, falls gewünscht, bin ich behilflich.

Ich habe mir das in JOSM angesehen.
sehe ich das falsch, wenn ich sage das Ding ist total kaputt ?
nicht geschlossen etc.
Ich mache da nichts dran.

MPs, deren Aussenring nicht geschlossen war, habe ich hin und wieder schon repariert. Wenn man vor hat, das Monster-MP ganz aufzulösen und durch kleinere Einheiten zu ersetzen, löst man das beschädigte MP besser auf und gliedert die frei gewordene Fläche neu. Ich schau es mir heute abend an, habe gerade kein JOSM.

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.