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

der derzeitige Stand schlägt vor, nur noch Multipolygone mit einem outer way zu empfehlen (bzw. von mehreren outer ways abzuraten), m.E. ist das übertrieben. Einen outer Ring halte ich für sinnvoll als Beschränkung, aber ob der aus einem oder mehreren outer ways besteht ändert nichts an der Übersichtlichkeit, und MPs sind normalerweise einfacher zu bearbeiten als mehrfache übereinandergestapelte ways. Bei letzteren kommt es in der Folge leicht zu falschen (bzw. unvollständigen) Verbindungen.

Auch bei den anderen Punkten gibt es aus meiner Sicht noch Überarbeitungsbedarf:

Der Punkt 3. ist nicht nachvollziehbar dargestellt, wieso sollte das OK sein bei in der Nähe liegenden Teilen und nicht mehr bei weiter entfernten Teilen? Entweder es gibt eine Lösung dafür ohne MP, dann macht es kaum Sinn, die nur teilweise zu implementieren, oder es gibt keine Alternative, dann ist das Abraten davon auch schwierig.

zu 4. “Absolut unerwünscht sind „MP-Teppiche“, bei denen nur die Grenzlinien von Flächen eingezeichnet und dann zu Outer-Ringen zusammengestellt werden. Diese Konstrukte sind für spätere Mapper kaum zu durchschauen und zu bearbeiten.”

Übertriebene Bewertung m.E., wer iD benutzt dürfte nicht mal den Unterschied von verklebten Flächen und solchen mit MP bemerken, für viele andere Editoren, z.B. JOSM oder GoMap!!, gilt: den way selektieren und alle darauf aufbauenden Flächen werden bequem aufgelistet. Im Gegensatz zu übereinandergeklebten Flächen, da muss man erst komplizierte Tastenkombinationen ausführen, um überhaupt an die unteren Flächen zu gelangen. Die Komplexität, die durch das Mappen von “Objekten” entsteht (ein Objekt ein OSM Objekt, z.B. Museumsgebäude und Museuminstitution(en) darin), ist sowohl bei Multipolygonen als auch bei Überlappungen da. Die Relationen sind einfacher für den Mapper, die Überlappungen für Computer und die Leute die die Daten importieren oder weiterverarbeiten (weil Relationen einen “Extradurchgang” erfordern, normalerweise)

zu 5. “Nur Flächen dürfen untereinander verklebt werden”, nein, bestimmte Linien (z.B. Mauern, Zäune) sollen auch verbunden werden (Topologie).

Ich bestreite ja nicht, dass mit MP viel Schindluder getrieben wird, aber das derzeitige Proposal übertreibt es in die andere Richtung, aus meiner Sicht.

Doch, das ist genau der Kern des Vorschlags. Es ist nicht immer gleich zu überblicken, welche Linie zu welchem MP gehört; das Risiko, etwas zu “zerschießen”, ist empirisch belegbar deutlich höher bei MP aus mehreren Outer-Ways. Siehe die regelmäßigen Hilferufe hier im Forum. Insbesondere in Ecken, wo mehrere Flächen aufeinanderstoßen, passieren häufig Unfälle.

Ja. Weil das Thema so umstritten ist, würde ich dazu raten, es hier auszuklammern. Ich befürchte nämlich auch, dass irgendjemand auf die clevere Idee kommt, alle drei (räumlich weit getrennten) Kliniken der Berliner Charité in ein MP zu packen, wenn hier für MPs mit mehreren Outer-Ringen grünes Licht gegeben wird.

Dass iD die Nutzer im Dunkeln lässt, was sie da eigentlich anrichten, sollte nicht der Maßstab sein.- Was meinst Du mit “übereinandergeklebten Flächen”? Miteinander verklebte Flächen? Das ist selbst mit dem verpönten P2 ein Kinderspiel (einen gemeinsamen Node anfassen und solange “#” drücken, bis die gewünschte Fläche gehighlighted wird).

Könntest Du mit einer vorsichtigen Formulierung leben: “Überlege reiflich, bevor du Linienelemente wie Mauern und Zäune auf Flächengrenzen setzt, weil sie dann im Editor möglicherweise nicht klar genug angezeigt werden.”

D.h. das steht da absichtlich so da? Ich war eigentlich von einem Versehen ausgegangen.
Ich würde da klar unterscheiden zwischen Linien, die eine konzeptionell eine Fläche repräsentieren (Straßen, waterways) und solchen, die eine Linie darstellen (bzw. vertikale Fläche), z.B. auch Cliff, coastline, die meisten barrier Linien, etc.
Es geht hier um Topologie, bestimmte Linien müssen idealerweise mit den Flächen verbunden werden.

Flächen sollten generell so wenig wie möglich mit sonstigen Linien verbunden sein, das gilt nicht nur für ways, sondern auch für barriers, natural:tree_row, power:line, usw.
Man muss es im Gegensatz zu den ways bei den barriers allerdings nicht so streng nehmen. Die Wiese endet nicht in Straßenmitte, das ist sicher unstrittig, aber ob die Wiese nun am Zaun endet, oder am Straßenrand (also z. B. 0,5 Meter neben dem Zaun)…Die zuletzt vorgeschlagene Formulierung lässt diesen nötigen Spielraum.

“Müssen” geht mir zu weit.
Mauern, Zäune etc. stehen längst nicht immer genau auf der Flächengrenze. Bei einer späteren Detaillierung wird der Aufwand und die Fehleranfälligkeit höher, insbesondere wenn ein (unechtes, segmentiertes) MP mit diesen Linien erzeugt wurde.
Wenn die Linien denn an die Fläche geklebt werden, dann zusätzlich zur Flächengrenze und nicht als Mitglied der MP-Relation.

Das Erzeugen eines MP ist halt leider viel einfacher als das spätere Aufteilen.
Das Durchklicken bei übereinander liegenden Linien sehe ich als das kleinere Übel.

Ich würde versuchen, nicht jeden denkbaren Einzelfall abzudecken (da bleiben immer Lücken), sondern an den gesunden Menschenverstand appellieren. Deswegen mein Formulierungsvorschlag mit “reiflicher Überlegung” → wenn Du reiflich überlegt und die widerstrebenden Argumente abgewogen hast, darfst Du auch den Zaun auf die Flächengrenze setzen.

+10!

+1

Bin auch sehr dafür. Nach reiflicher Überlegung soll es OK sein. Das hilft jetzt nicht bei der Durchsetzung, weil sich Hardcore-MP-ler dann immer mit “natürlich habe ich reiflich überlegt, und ihr seid alle doof!!!” rausreden können, aber so eine Richtlinie hat ja auch normative Wirkung, nicht nur tatsächliche.

Danke, das hatte ich, wenn ich mich recht erinnere, mal irgendwo in einem anderen Diskussionsthema mitbekommen.
Dies hatte ich wohl vergessen in die Frage zu packen, dass das bereits bekannt… , daher was ist der ganz einfache Grund, warum die API so programmiert wurde? Könnten dann eventuell bei einer höheren Anzahl von Punkten pro Weg etwa verschiedene Editoren zu langsam werden? Falls ja, gibt es dazu “on-the-ground” Messungen?

+10 auch von mir :wink:

Wenn ich das richtig sehe, gab es ursprünglich kein Limit, was üble Performanceprobleme in der API verursacht hat. Seit API 0.6 gibt es daher ein Limit von 2000 Nodes pro Way. Von API-Seite wäre das heute wahrscheinlich handlbar, aber einzelne Editoren sind schon arg langsam mit langen Ways.

Dann gibt’s noch das Thema, dass Versionen immer komplett abgelegt werden, was vor allem beim Hinzufügen oder Löschen von Knoten zu recht viel Redundanz führt, sowohl auf der Datenbank, als auch beim Hochladen.

https://trac.openstreetmap.org/ticket/449#comment:2

Mein Senf dazu (betrifft ausschließlich Landschafts-Flächen-MPs):

  • Einfach so wenig MPs wie möglich erstellen, und wo’s nicht anders geht gibt’s halt nach wie vor MPs.
  • Auch an die Nachbearbeiter denken, die mit dem deinem Zeug umgehen müssen, wenn du selbst schon lange nichts mehr mit OSM machst - Also darauf achten, dass die Flächen wieder einfach aufzulösen/ aufzudröseln sind.
  • Riesige Flächen vermeiden.

Die meisten Riesen Mp’s (Flächen) auf die ich in meiner weiteren Umgebung treffe, sind ca. 10 Jahre alt, wurden von einer Handvoll Kartierern damals erstellt, und sind meist recht ungenau. Es ging wohl damals darum, möglichst viele “weiße Flächen” erstmal irgendwie zu füllen. Aus heutiger Sicht vllt. nicht so schlau.

Habe gerade ein grosses Wald - MP zerlegt mit weit über 60 innern. Auf der betroffenen Fläche gibt es nun wieder neue 5 bis 6 MP. Die Anzahl der inner hat, über alle neuen MP betrachtet, sogar deutlich zu genommen, denn da waren noch etliche Lichtungen (z. B. Äcker, Wiesen) noch nicht erfasst. Mangels genügend querender Straßen konnte ich die MP nicht kleiner machen. Ergebnis also irgendwie ernüchternd, aber die Karte ist natürlich auch viel detaillierter geworden. Nur, wer denkt, man könnte weitgehend OHNE MP auskommen, das wird nix!

Andererseits habe ich in der letzten Zeit auch eine Vielzahl von Sinnlos-MP, welche nur aus aneinander gereihten outer bestanden, entsorgt (durch Umwandlung in einfache Relationen). Was ich an solchen MP in meiner Region finde, stammt weitgehend aus der Frühzeit von OSM.

Nein, das sicher nicht. Aber deinen neuen, kleineren MPs sind doch viel besser zu handhaben als das bisherige Groß-MP. Und das ist, neben der genaueren Erfassung, doch ein großer Gewinn!

Ich werfe hier nochmal zwei Overpass-Abfragen hinein :wink:

Einmal eine die nach Outer-Ways sucht die wenig Punkte haben (<20), aber trotzdem eine Relation “multipolygon” erstellt wurde.
http://overpass-turbo.eu/s/E7Q

Und noch eine… Sinnlose Relationen… nur einen outer-Way und ohne inner-Ways
http://overpass-turbo.eu/s/E7R

…gibt ganz schön viele :confused: … teilweise hatten sie mal inner-Ways

Gruß Miche

Wohl weil diese ‘inner’ mal landuse=construction waren - was ja temporäre Dinge sind.

Gruß
Toni

Hab ich bei dene die ich angesehen hab noch nicht gehabt… aber jetzt wird schon langsam Sinnlos… landuse=construction auch noch auszuschneiden ist ein Blödsinn… soll ma vielleicht noch Schule/Bäcker/Friseur/Hotel/Gasthof/Tankstelle/Metzger/Kirche aus landuse=residential ausschneiden… nur weils sooo und nur so ganz richtig ist??

so wie hier teilweise:
https://www.openstreetmap.org/relation/6946674

landuse aus landuse mittels MP rausschneiden? Ja, so habe ich das MP-Konzept verstanden.

Hat wenig mit dem Konzept MP zu tun. Sondern einfach damit was man unter landuse=residential vs. construction (zB) versteht.

Wenn man darunter ein fertiges Wohngebiet (residential) versteht, und eines welches gerade hochgezogen wird (construction), dann sind dies zwei disjunkte Flächeneigenschaften und man muss die Flächen halt trennen (keine Überlagerung).

Klar, sobald die Baustelle fertig ist, kann man die landuses verschmelzen.

Mir geht es dabei mehr um Baustellen mitten im Wohngebiet, nicht am Rande.

Da beide ‘landuse’ sind und das eine inerhalb des anderen liegt verwende ich ein MP mit outer und inner.

Wenn die Baustelle weg ist wird das zugehörige ‘landuse’ gelöscht, zurück bleibt ein MP mit nur einem outer - so what?

Da kann das MP mit dem einen ‘outer’-Member doch “noch eine Weile” existieren, oder?
Denn zwei Wochen später wird die nächste Baustelle mitten im Wohngebiet gemapped und bumms hat’s MP wieder ein ‘inner’.