Multipolygonwahnsinn - oder: Durchblick war gestern!

Ja, die deutsche Version sollte eine Übersetzung der englischen sein, mehr nicht. Verbesserungen bitte immer erst in die englische Version einbringen. Ausnahmen sind sprach- oder länderspezifische Eigenheiten, z.B. habe ich auf de:access ein paar Anmerkungen zu Mopeds/Motorfahrrädern gemacht, weil eine 1:1-Übersetzung irreführend wäre.

Gar nichts halte ich davon, Empfehlungen für oder gegen komplexe MP ins Wiki reinzuschreiben. Denn darüber herrscht kein Konsens. Vielmehr sollte reingeschrieben werden, dass (bzw. in welchen Fällen) das ein Streitthema ist, und was die Pros und Contras sind.

Nun, mein Vater war Architekt. Um ein Haus zu bauen brauchst du Pläne für den Maurer, den Zimmermann, Elktriker, Installateur etc. Jeder bekommt seinen eigenen individuellen Plan. In der Zeit vor CAD und Plotter wurden die Pläne also manuell mit durchpausen jeweils von Hand gezeichnet. Dabei enthielt jeder der Pläne allgemeine Dinge (z.B. Mauern) und wurde danach um spezifische Informationen ergänzt.

Nach deiner Logik müsste man aber die Umrisse der Mauern nicht noch mal zeichnen, denn der Elektriker kann sich diese Informationen ja aus dem Plan der Mauerer holen. Auch in OSM gibt es ja relativ unabhänige “Pläne” mit Grenzen, Landnutzung und Strassen.

Andersherum kann man es auch sehen: Nach deiner Logik zeichnen Elektriker, Maurer, usw. ihre eigenen Mauern und stehen anschließend mit unterschiedlichen Maßen da.

Ich bin auch der Meinung, vorhandene Wege für MPs zu nutzen. MPs mit gemeinsamen Grenzen sind übersichtlicher und weniger fehleranfällig als 3 übereinander liegende Wege bzw. Flächen.

Pro MP:

  • Laufen mehrere Linien übereinander, ist es im Editor schwieriger, die gewünschte auszuwählen.

Contra MP:

  • Das Auftrennen großer MPs, um sie bspw. in zwei Hälften zu zerlegen, ist sehr aufwendig. Während die outer-Elemente noch leicht aufzutrennen sind, ist das Neuverteilen der inner-Elemente sehr mühsam.
  • Solche farmland- und meadow-MPs spiegeln falsche Tatsachen wider: Die darin zusammengefassten Acker- oder Wiesenflächen haben nichts miteinander zu tun, das MP wird allein als “Farbrolle” missbraucht.
  • Mapper vergessen oder merken oft gar nicht, dass neu eingetragene Flächen innerhalb eines MP liegen und ausgeschnitten werden müssten (Bauernhof als Insel im Acker usw.) QA-Tools wie der OSM Inspector machen auf solche Fehler nicht aufmerksam, da sie nur die Relationsmitglieder auswerten.

Fairerweise muss ich noch sagen, dass einige deiner Argumente nur gegen so riesige MPs wie in deinem Beispiel sprechen, nicht gegen das Konzept an sich. Sollte man vielleicht sorgfältiger trennen.

Ich möchte dieses Thema an sich hier NICHT reinziehen und darüber diskutieren, aber ganz übel wird es, wenn ein complex-Multipolygon-Liebhaber gleichzeitig ein Landuse-an-Straßen-Kleber ist. Dann sind die Straßen zigfach gesplittet und gleichzeitig Teil mehrerer Multipolygone. Ich hatte schonmal einen Fall, wo die Straßen zigfach gesplittet wurden und jeder kleine Parkplatz (1-5 Plätze) und jede kleine Grünfläche im Wohngebiet als MP erstellt wurde. Da sich der betreffende Mapper allerdings entschieden hat, keine CT-Entscheidung zu treffen (wohl mal wieder ein “spezieller” Mapper…), habe ich das alles gelöscht und in einfacher Form neu erstellt, die Straßennamen waren zum Glück “sauber” von einem Zustimmer vorhanden. Wer dann da etwas ändern will, der hat wirklich seinen Spaß im Relation-Dschungel. Und da kann dann natürlich auch einiges kaputtgehen.

Wenigstens einen Vorteil hat das allerdings gegenüber der anderen (und von mir genauso gehassten, aber - anderes Thema) Lösung, bei der “simple” Polygone direkt auf den Straßen kleben: man trifft immerhin die Straße sofort und muss sich nicht erst durch zig andere ways wühlen und ggf. ungluen.

Ich bin auch dafür, die Strukturen möglichst einfach zu halten, also MPs nur dort, wo es sein muss. Für mich sind das nur “gelöcherte” Flächen. Grenzen sind für mich etwas eigenständiges und keine klassischen Multipolygone und sollten hier rausgehalten werden. Zumal die meisten Grenzen völlig losgelöst von “realen” Objekten existieren - nur weil der Wald teilweise gerodet oder der Fluss begradigt wurde, läuft die Grenze nicht automatisch anders.

Es gibt genügend Prüftools, außerdem schaut man sich Änderungen eh nachher in Mapnik an und dann fällt ein Fehler gleich auf. Ich finde es sogar gut, wenn ein Fehler auffällt. Wenn man beim Nachzeichnen von Linien einen Fehler macht, bleibt der Fehler jahrelang drin und nachher weiß man nicht mal, ob das mit Absicht so gezeichnet wurde.

Solche Performanceprobleme gehen gehen null, weil die Systeme immer leistungsfähiger werden.

Siehe oben. Obwohl der Datenbestand immer umfangreicher wird, ist Mapnik immer schneller geworden.

So große Relationen sollte man aufteilen. Nicht wegen Speicherplatz, sondern wegen Übersichtlichkeit.

Hört sich nach SW-Bug an.

Das tun sie sowieso, egal wie man die Daten erfasst.

Darüber kann man streiten.

Wege werden sowieso zerschnibbellt: für Brücken, maxspeed- und tracktypeänderungen, neuerdings auch für Spurmapping… Darum sehe ich das Problem eher umgekehrt: Die vielen kurzen Straßenstücke als Grenzabschnitte machen das MP unübersichtlich. In beiden Fällen ziehe die Straßen gern 1x für die MP-Grenze nach. Das ist ein Kompromiss: Straßen und Flächen beeinträchtigen einander nicht, und man muss die Straßen nicht mehrmals nachzeichnen, sondern nur 1x.

Das größte Problem, wenn man mit vielen MP arbeitet, und das hast du gar nicht gelistet, ist vielleicht, dass man dann im Editor eine lange Liste an Relationen hat. Da ist kaum mehr zu sehen, was was ist. Aber das ist ein Problem von Relationen generell.

Auch das ist eine Frage der Größe.

Bei administrativen Grenzen ist das absolut sinnvoll, weil entweder jeder Weg eine eigene Bedeutung hat (Straßenmitte, Eisenbahn, Fluß/Bach, …) oder nur eine Grenze ist (kann man mit boundary=administrative am Weg kennzeichnen). ALs Grenze gehört ein Weg jedoch zu mindestens zwei Gebieten.

Bei Häusern an Häusern jedoch würde es einen erheblichen Mehraufwand bedeuten, Außenwände und Zwischenwände einzeln zu zeichnen und für jedes Haus noch eine passende Relation zu erzeugen. Aus dem Grund wird das auch kaum gemacht.

Ich denke (wie schon von anderen angemerkt), dass man großflächige Objekte (mehrere zig Quadrat-Kilometer) und kleinflächige Objekte (z.B. Häuser an Häuser) getrennt betrachten sollte.

Wenn man, wie im Wiki vorgeschlagen, die Taggs an die Relation macht (unabdingbar bei mehreren Wegen für einen outer-Ring), dann hat man das Problem, dass nicht mehr unmittelbar erkennbar ist, um was für ein Objekt es sich handelt.

Edbert (EvanE)

Das Problem besteht bei “nomalen” Flächen auch, spricht also nicht gegen MPs.

Ich sehe das Problem nicht.

Zeichne ich den Bauernhof direkt auf das Feld, wird es auch von keinem Tool bemängelt, obwohl es falsch ist. Also ist das kein Grund gegen MPs.

Das Aufsplitten des äusseren Weges ist mit und ohne MP nötig.

Bei MPs kommt jetzt noch das Kopieren der Relation und das manuelle umsortieren der Wege zu den zugehörigen Relationen dazu.

Ohne MP (bzw auch bei MPs, deren outer aus einem Weg besteht) gibt es eine super Hilfe: utilsplugin2 “Split Object”. Zwei Punkte und eventuell noch den zugehörigen Weg selektieren. “Split” (Alt-X). Fertig (Tags werden mit kopiert)

Willst du deinen Beitrag eventuell noch einmal überdenken und gegebenenfalls korrigieren? Analog zur Meinung von “mdk” steigt auch in meiner kleinen Welt die Anzahl der Fehler mit wachsender Komplexität der Aufgabe. Das ist dann der Grund, warum die erste praktische Fahrstunde auf einem Parkplatz oder Privatgelände beginnt.

Die laxe Art, mit der du m. E. fundierte Argumente “abbügelst” lässt jetzt nicht gerade eine grosse Bereitschaft, Argumente des Gegenübers auch Ernst zu nehmen, erkennen.

Gruss Christian

… und um auch zum eigentlichen Thema beizutragen: Ich mag Multipolygone auch nicht soooo sehr und meide sie deshalb eher, aber:

Ist es möglich “Daumenregeln” zu definieren. Also dergestalt:
Ein Multipolygon kann entweder mehrer outer ways oder inner enthalten. Sind beide Elemente nötig ist auf eine Superrelation auszuweichen."

Oder: “Ein Multipolygon mit mehr als n verschiedenen Typen von inner ist ‘schlechte Praxis’.”

Gruss Christian

Ein großer Wald mit einem Teich und einer Wiese drin benötigt eine “Superrelation”? Was ist das eigentlich? Und wird das nicht noch komplizierter?

Ehrlich gesagt finde ich das eingangs von Nop erwähnte Beispiel nicht besonders gelungen. Teils war ein MP wirklich nötig und teils war es nun nicht so schlimm wie er dargestellt hat. Ich persönlich habe kein Problem mit MP und finde, dass man die beherschen sollte wenn man in OSM Flächen erfasst. Aber krampfhaft MP zu verwenden wenn es auch anders geht, mache ich auch nicht. Wenn im Wald eine Lichtung ist, nehme ich ein MP statt den Wald zu teilen…wobei ich keine Ways von anderen Objekten wie Straßen, Feldwegen etc mitbenutze

Nein, aus meiner Sicht benötigt der grosse Wald eine Relation und die im Vergleich dazu kleinen Flächen der Wiese und des Sees werden ohne Zusammenhang zum Wald “darüber geklatscht”. Ist nicht schön im Sinne der “reinen Lehre” aber bis wir wirklich mehr Datentypen als “Punkt und Strich” haben ein m. E. akzeptabler Kompromiss, der sich darauf verlässt, dass existierende Renderer kleine Flächen über grosse “malen”.

Meine Frage zu den Daumenregeln zielt ja gerade darauf ab, “Krampf” greifbar zu machen …

Gruss Christian

P. S. Mit “Superrelation” meine ich Relationen, deren Member auch Relationen sind.

Ich bin sehr dafür.

Das muss man nie. Die Multipolygon-Elemente werden in ihrer Bedeutung durch das Multipolygon niemals verändert und behalten ihre Bedeutung (Außer bei dieser grauenhaften alten Multipolygonart, bei der die Tags nicht ins Multipolygon kommen).

Das ist ganz normal. Bei den Wegen machen wir das dauernd. Die angegebenen Punkte haben meist keine Bedeutung und wo sie doch eine haben, spielt sie überhaupt keine Rolle. Kein Mensch denkt darüber nach, was mit dem Straße passiert, wenn einer seiner Punkte eine Ampel ist – und zwar zu Recht. Kein Mensch kommt auf die Idee, der Weg würde sich verändern, wenn man die Tags eines seiner Punkte ändert. Multipolygone verhalten sich zu Wegen genauso wie Wege zu Punkten. Kein Mensch kommt auf die Idee, man müsste alle Wege durchsuchen, um einen Punkt verstehen zu können. (Mit “Weg” und “Punkt” meine ich hier OSM Way und Node.)

Es gibt auch jetzt kein Ausstanzen. Das ist nur ein immer wieder abgeschriebener Fehler der Beschreibung, der das eigentlich einfache Multipolygon kompliziert erscheinen lässt. Die Elemente des Multipolygons werden alle ausnahmslos als Linien betrachtet, ihre Tags spielen nur für sie selbst eine Rolle und sie geben schlicht und einfach den Rand der zu beschreibenden Fläche an.

Weide

Dem kann ich Weide nur in allen Punkten voll zustimmen.

Gruss
Walter

+1

Hallo,

kann mir jemand den Sinn dieses Multipolygons erklären?
http://www.openstreetmap.org/browse/relation/164755

Gruß

ja, eigentlich gehören die Tags dieses Wegs
http://www.openstreetmap.org/browse/way/19046066
ins MP. Das ist eine Fussgängerzone. Und da wo die Gebäude stehen, wurde Löcher in die Fussgängerzone geschnitten. Ist formal auch korrekt…wo ein Gebäude ist, ist keine Fussgängerzone.

Vielleicht werden dort auch Multipolygone von dieser Person bewußt verwendet, um Änderungen von nicht versierten OSMlern`zu verhindern.
Gruß
Peter

Stimmt, wenn man bedenkt dass die Fußgängerzone ein highway ist und kein landuse macht das natürlich Sinn.