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

Jetzt muss ich da mal nachfragen: Schon beim Selektieren, wird aus einer Fläche ein MP? Ist da nicht wenigstens ein Aufschneiden notwendig? IMHO nicht mal ein Trennen sollte einen Weg resp eine Fläche teilen, das sollte zwingend nur beim Aufschneiden passieren.

Frage: Wenn eine Fläche (z.B ein Fluss) mit einer Brücke (Weg) überquert wird, ist doch ein Teilen der Fläche gar nicht nötig, oder? Das gleiche gilt doch auch für eine Landuse-Fläche, die von einer Strasse gequert wird. Kannst du mal ein Beispiel sagen, wo der ID eine Fläche teilt, obwohl er das nicht müsste?

Um so genauer man es nimmt um so höher wird die Anzahl der Ways bzw. Relationen… Aber ist das wirklich Sinn der Sache?

Hier für mich eher ungewöhnlich…:
https://www.openstreetmap.org/relation/4007243

Man kann alles aus allem ausschneiden mit wenige klicks in JOSM… aber macht das Sinn? :expressionless:

Hab eine Overpass Abfrage für inner-Ways erstellt. Die in Multipolygone landuse~“farmland|residential” sucht.
http://overpass-turbo.eu/s/DGZ

Gruß Miche

Genau so ist es …

Multipolygonproduktion ist häufig die kleine Schwester von suboptimaler Geometrieaufteilung, aka Pfusch.
lustigerweise verbergen sich dort sogar schon diesbezügliche Lösungsansätze:
https://www.openstreetmap.org/way/69602731#map=17/48.14889/11.77846

@miche101
Wenn ist erstmal die ganze Stadt incl. der Fläche der Durchgangsstraßen zum Wohngebiet erkläre,
geht es erstmal schnell und einfach,
aber nach und nach muss bzw. soll halt der ganze Klumpatsch,
wo dann vielleicht doch keiner wohnt ausgeschnitten werden, z.B.

https://www.openstreetmap.org/relation/6946674#map=15/48.1897/11.8709

Frage: “Aber ist das wirklich Sinn der Sache?”
Antwort: “Nein, das ist offensichtlich Unsinn, besser ist es geometrisch exakt zu arbeiten, dann entfällt sehr sehr häufig auch die scheinbare Notwendigkeit von Multipolygonen.”

Ja diese Relation hab ich auch gesehen… einfach nutzlos… oder ich kenne den Anwendungsfall noch nicht :wink: . Aber mit sowas kann sich dann ein z.B. Renderer rumschlagen… auch wenn es dieser eh richtig angeordnet hätte… weil ich den allermeisten Situationen macht da keiner eine Relationen.

Weil wenn z.B. ein Renderer einen Wald und einen Acker hat was wird der oben zeichnen? Natürlich den Wald über den Acker… wenn das falsch ist braucht es eine Relation…

Bei aller Sympathie für das Vorhaben, MPs zu vermeiden: Mit solchen Annahmen kommt man nicht weit.
Selbst wenn man mal annimmt, dass “Wald über Acker” in irgendeiner Art natürlich ist… Wer sollte diese Liste der Selbstverständlichkeiten für alle Arten von Flächen definieren, führen und pflegen?

Grüße
Max

Naja, dann schau dir mal die history an:
https://www.openstreetmap.org/relation/6946674/history

Um einen bekannten Spruch abzuändern:
“Wer Multipolygone sät, wird Inner ernten.”

Zum Rendern nur soviel: nebeneinander ist immer besser als übereinander und schnellmall Löcher stanzen langfristig keine gute Lösung.
Wo Straßen sind, da ist kein Acker und auch kein residential Punkt

Einspruch: Mindestens Wohnstraßen sind Teil von landuse=residential. Sonst würde es ja nicht highway=residential heißen.

https://wiki.openstreetmap.org/wiki/DE:Tag:landuse%3Dresidential

“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.