Multipoligon -> mehrere Outers-Wege

schmalzlocke · 2010-01-23T16:50:07.000Z

Hallo,

es geht um den Reichswald bei Kleve.
Dort ist es sinnig, mehrer Outer-Elemente zu setzen, sonst wird der Weg riesig lang.
Doch: Dürfen diese Wege auch den Schlüssel landuse=* haben? Denn: Eigentlich ist landuse=* ja nur für Flächen. Meine Idee währe da, die Attribute in der Relation mitzugeben. Mapnik und T@H rendern auch richtig, aber wenn ich selbst render bleibt die Fläche leer. Das gleiche Tritt auch bei CloudMade auf.

Wie löst ihr sowas???

Gruß Elmar alias Schmalzlocke

kuede · 2010-01-23T17:32:29.000Z

Eine Lösung habe ich zwar nicht, aber die Variante mit mehreren outer-Ways und den Tags in der Relation gibt’s in der Gegend um Mailand häufiger (scheint da Importe gegeben zu haben). Das Problem dürfte da dann natürlich auch irgendwann die Richtung der outer-Ways sein. Weiss der Renderer immer, was aussen bzw. innen ist (oder muss es irgendwann wie bei Gewässern/Küstenlinien gehandhabt werden)? Ich präferiere eigentlich die zerstückelten Flächen, da die Übersichtlichkeit irgendwann zu leiden beginnt. Es sollen ja auch Nicht-Profis noch einigermassen mappen können.

de_muur · 2010-01-23T19:13:39.000Z

kuede:

Ich präferiere eigentlich die zerstückelten Flächen, da die Übersichtlichkeit irgendwann zu leiden beginnt. Es sollen ja auch Nicht-Profis noch einigermassen mappen können.

Sehe ich genauso. Die erweiterten Multipolygone sind zwar in der Theorie ein nettes Konstrukt, aber fuer meinen Geschmack viel zu kompliziert fuer so ein offenes Projekt. Da haben ein paar Informatiker ihren Spieltrieb freien Lauf gelassen, und dabei ein wenig die praktische Anwendbarkeit aus den Augen verloren.

Gruss
Torsten

EvanE · 2010-01-23T21:40:04.000Z

de_muur:

kuede:

Ich präferiere eigentlich die zerstückelten Flächen, da die Übersichtlichkeit irgendwann zu leiden beginnt. Es sollen ja auch Nicht-Profis noch einigermassen mappen können.

Sehe ich genauso. Die erweiterten Multipolygone sind zwar in der Theorie ein nettes Konstrukt, aber fuer meinen Geschmack viel zu kompliziert fuer so ein offenes Projekt. Da haben ein paar Informatiker ihren Spieltrieb freien Lauf gelassen, und dabei ein wenig die praktische Anwendbarkeit aus den Augen verloren.

Hallo Torsten, schmalzlocke

So besonders groß kommt mir der Reichswald nicht vor.
Wieviel Knoten sind es denn insgesamt?

Der Kottenforst (ein großes Waldgebiet zwischen Köln und Bonn)
ist in mehrere Teilstücke geteilt. Das ist deutlich leichter zu handhaben
insbesondere in Hinblick auf innenliegende Flächen als eine sehr lange
Relation, die zudem in viele Wege gesplittet ist.

Den Reichswald würde ich in drei Stücke aufteilen mit der Gocher Straße und
der Grunewaldstraße als Grenze zwischen den Teilstücken.

Edbert (EvanE)

Nightdive · 2010-01-23T22:24:56.000Z

An der Stelle ist es eher absolut unsinnig den Wald in mehrere Stücke zu teilen.
Solche Konstrukte erhöhen die Komplexität extrem und gerade Anfänger sind absolut überfordert mit solchen Konstruktionen. Es gibt dann noch Leute die es noch weiter treiben und viele Flächen die aneinander grenzen mit solchen Multipolygonen erstellen, da bin selbst ich überfordert (Ich zähle mich nicht zu den Anfängern).

Das wird hier stellenweise auch schon gemacht :
http://www.openstreetmap.org/browse/relation/369665/
http://www.openstreetmap.org/browse/relation/369650/

Ein Multipolygon mit mehreren outer Flächen sind sinnvoll, wenn es viele Nodes gibt und man an die API Grenze kommt. Die API Grenze liegt bei 2000 Nodes pro Way.

An dieser Stelle sind es geschätzt nichtmal 200 Nodes, ich verstehe nicht warum man das an dieser Stelle splitten sollte außer man will das Editieren an dieser Stelle für Anfänger unmöglich machen.
Ich würde das sofort als eine normale Area umbauen wenn ich auf diese Stelle treffen würde denn ich betrachte solche zerstückelungen als fehlerhaft.

Nun zu der eigentlichen Frage:
Landuse= ist ein Area Tag und bedeuted das die Elemente in sich geschlossen sein müssen.
Das Multipolygon ist geschlossen und kann damit ein landuse Tag haben, die einzelnen Stücke jedoch nicht.

PHerison · 2010-01-23T22:27:59.000Z

Der Vorteil, grosse Gebiete in ein Multipolygon aufzuteilen, liegt darin, dass bei einem versehentlichen Verschieben nur der Teilabschnitt betroffen ist. Der Teilabschnitt laesst sich leichter restaurieren, wenn andere Mapper im Nachhinein schon einzelne Punkte wieder an ihren Platz gerueck haben.

Nightdive · 2010-01-23T22:36:29.000Z

Ein versehentliches Verschieben lässt sich am einfachsten korrigieren wenn der Wald aus einer einzelnem Stück besteht.

Wald in Potlatch öffnen, Wald markieren, h drücken und richtige Version auswählen.

Hier ein Beispiel wo ein Multipolygon für eine Fläche absolut gerechtfertigt ist:
http://www.openstreetmap.org/browse/relation/273006/

(Hatte ich gerade repariert weil der Bodensee ausgelaufen war)

Ebbe73 · 2010-01-23T22:52:04.000Z

Erst einmal "“theoretisch” allgemein, die (meiner Meinung nach) sinnvolle praktische Umsetzung s.u. (nicht alles was theoretisch geht, ist praktisch sinnvoll):

Maximale Punktanzahl je Linie/Kontur:
De maximal möglich Anzahl von Punkten je Linie/Polygonkontur liegt bei 1000. Die Renderer und JOSM haben bis zu dieser Grenze bei sonstiger Fehlerfreiheit keine Probleme. Ob die Arbeitsgeschwindigkeit in Potlach bei sehr vielen Punkten stark runter geht, weiß ich nicht genau. Ggf. sollte man deshalb überlegen, eine Linie ab 400 oder 500 Punkten aufzutrennen. Bei weniger als 400 oder 500 Punkten ist dies sicher auch für Potlach nicht erforderlich.

Multipolygone mit einer Außenkontur aus mehreren Linien:
Bei Multipolygonen, deren Außenkontur aus mehreren Linienzügen besteht, sollte man logischerweise die Flächenattribute wie landuse=forest, name=xyz dem Multipolygon und nicht den einzelnen nicht geschlossenen Linien zuweisen.

Rendering von Multipoygonen:
Die Renderer sollten keine Probleme haben Multipolygone darzustellen, wo die Außenkontur aus mehreren Linie besteht und innerhalb dieser Fläche zusätzlich noch Innenpolygone ausgeschlossen werden. Es würde Probleme geben, wenn man mehrere komplett voneinander getrennte Flächen zu einem Multipolygon kombiniert und dann noch innerhalb dieser Einzelflächen Innenpolygone bestehen. Da kann ein Renderer fast nur scheitern.

Bei sehr großen Polygonen kann es aber auch so Rendering-Probleme geben. Da die Renderer mit Kacheln arbeiten, kann es passieren das eine Kachel komplett innerhalb eines Multipolygons liegt, innerhalb der Kachel selbst aber keinerlei Punkte irgendeiner Innnen- oder Außenkontur des Multipolygons sind. Der Renderer kann dann ggf. nicht erkennen, dass die Kachel innerhalb eines Multipolygons liegt, welches er zu berücksichtigen hat.

Die (ggf. abweichende) sinnvolle “Praxis” und “Dein Fall” Reichsforst:

In Bezug auf die Punkteanzahl liegt jener weit unter 1000 und auch 400 bis 500, daher gäbe es diesbezüglich keinen Grund jenen aufzuspalten. Größenmäßig sollte es an sich auch noch keine Probleme geben, da könnte der Reichsforst aber schon grenzwertig sein.

Ich würde den Wald daher wie EvanE in zwei oder drei Teilstücke aufspalten. Mit drei Teilstücken meine ich drei jeweils geschlossene Polygone, also kein großes Multipolygon aus drei Außenlinien. Dann gibt es zwar aufeinanderliegende Konturen an den Schnittstellen, dennoch ist die Übersichtlichkeit und spätere Bearbeitbarkeit so erfahrungsgemäß am besten. Ob Du den Wald entlang der Straßen aufspaltest oder irgendwo quer im Wald, bleibt Dir überlassen. Beim Aufspalten entlang der Straßen sieht man in Mapnik keine störenden Linien, dafür hat man eine weitere Überlagerung mit der Linie der Straße.

Außerdem gibt es bei der Schnittkante nebeneinanderliegenden Flächen die Diskussion, ob man die Randkurven/-linien der Flächen exakt aufeinander legt oder ganz dicht nebeneinander. Wenn zwischen den Flächen kein “Leerraum” wie eine Schneise u.ä. ist, würde ich persönlich die Randkurven aufeinander erstellen, d.h. unter Verwendung derselben Knotenpunkte an der Schnittkante.

Sollte innerhalb eines der zwei oder drei Teilstücke ein Innenpolygon z.B. aufgrund einer Lichtung ausgeschnitten werden, erstellst Du für dieses Teilstück ein einzelnes Multipolygon, so hast Du ggf. am Ende für den gesamten Reichsforst drei nebeneinanderliegende, aber voneinander unabhängige Multipolygone. Das verringert die Fehleranfäligkeit bei späteren Veränderungen durch andere deutlich, wie ich aus eigener Praxiserfahrung mit mehreren im Laufe der Zeit vorliegenden Variationen in meiner Mapping-Gegend weiß.

Die Zuweisung der Flächendefinition wie landuse=forest kann braucht dann auch nur bei den jeweiligen Flächen zu erfolgen und nicht noch zusätzlich beim Multipolygon. Das erhöht die Übersichtlichkeit weiter.

Ein Problem ist nur die Namensvergabe. Da man drei Polygone nebeneinander hat, muss man jedem den Namen Reichsforst geben und hat diesen damit drei mal nebeneinander. Das könnte man zwar wieder irgendwie übergeordnet kombinieren, ich würde aber einfach mit dem zwei- oder dreifachen Wald leben. Ich würde den Namen übrigens den Außenkonturen geben und nicht den Multipolygonen, welche Lichtungen u.ä. auschließen. Die Lichtungen gehören namensmäßig ja auch zum Wald. Bei strenger Sichtweise würde man sie dann, wenn man den Namen dem Multipolygon gibt, aber daraus ausschließen.

Wie gesagt, so handhabe ich das. Ich bin aber immer offen für andere Ideen. Insgesamt sind “wir” hier aber anscheinend alle der Meinung, keine sehr starke Aufsplittung vorzunehmen, sondern nur ein (Nightdive) bis maximal drei (EvanE) Multipolygone für den ganzen Wald zu verwenden. Das bleibt dann letztendlich die individuelle Freiheit.

PHerison · 2010-01-23T23:14:57.000Z

Nightdive:

Ein versehentliches Verschieben lässt sich am einfachsten korrigieren wenn der Wald aus einer einzelnem Stück besteht.
Wald in Potlatch öffnen, Wald markieren, h drücken und richtige Version auswählen.

Stell Dir mal einen (Teil-)Waldflaeche mit vielen Knoten vor, die jemand versehentich verschiebt, es aber erst nach ein paar Tagen merkt. In der Zwischenzeit haben meherer User einzelne Knoten wieder an ihren richtigen Position zureuck verschoben… Da ist es doch einfacher bei einem Teilstueck (eines Multipolygon) die H-Taste zu druecken, als die kompletten Aenderungen an dem Waldstueck ungeschehen zu machen.

EvanE · 2010-01-23T23:28:38.000Z

Nightdive:

…Hier ein Beispiel wo ein Multipolygon für eine Fläche absolut gerechtfertigt ist:
http://www.openstreetmap.org/browse/relation/273006/

(Hatte ich gerade repariert weil der Bodensee ausgelaufen war)

Richtig schräg, je nach Renderer wird im Moment mal der Obersee, der Untersee oder der
Bodensee nicht als Wasserfläche gerendert. Auslaufen pasiert in keinem der Renderer.
Kann aber am Zeitversatz der Kachel-Updates liegen.

Ich finde den Bodensee könte man sehr gut in einzelne, geschlossene Flächen splitten:

Obersee, Untersee (das wird wohl schon so gemacht).
deutscher Teil, östereichischer Teil, schweizer Teil.
den deutschen und schweizer Teil müsste/könnte man von der Größe her
vielleicht noch einmal unterteilen.
Bei breiten Flüssen wird das Ufer (= die Wasserfläche) ja auch aus pragmatischen
Gründen in einzelne Abschnitte unterteilt.

Edbert (EvanE)

EvanE · 2010-01-23T23:43:14.000Z

Ebbe73:

…
Ein Problem ist nur die Namensvergabe. Da man drei Polygone nebeneinander hat, muss man jedem den Namen Reichsforst geben und hat diesen damit drei mal nebeneinander. Das könnte man zwar wieder irgendwie übergeordnet kombinieren, ich würde aber einfach mit dem zwei- oder dreifachen Wald leben. …

Unter anderem deswegen schlug ich die beiden großen Straßen als Grenzen vor.
Ob genau darauf, links und rechts daneben oder links resp. rechts als gemeinsame
Grenze ist erst mal unwesentlich. Das mache jeder, wie es für ihn am einfachsten ist.

Bei einer großen Fläche den Namen mehrmals zu haben, kann durchaus praktisch sein.
Man hat ja oft nicht die ganze Fläche im Blick. Mit mehreren Teilflächen hat man die
Chance auch bei einem kleineren Stück einen Namen zu sehen.

Ansonsten weitgehende Zustimmung zu deinen Ausführungen.

Edbert (EvanE)

Ebbe73 · 2010-01-24T00:03:26.000Z

EvanE:

Bei einer großen Fläche den Namen mehrmals zu haben, kann durchaus praktisch sein.
Man hat ja oft nicht die ganze Fläche im Blick. Mit mehreren Teilflächen hat man die
Chance auch bei einem kleineren Stück einen Namen zu sehen.

Exakt! Das empfinde ich “bei mir im Harz” auch eher als Vorteil denn als Nachteil.

Nightdive · 2010-01-24T02:17:45.000Z

EvanE:

Nightdive:

…Hier ein Beispiel wo ein Multipolygon für eine Fläche absolut gerechtfertigt ist:
http://www.openstreetmap.org/browse/relation/273006/

(Hatte ich gerade repariert weil der Bodensee ausgelaufen war)

Richtig schräg, je nach Renderer wird im Moment mal der Obersee, der Untersee oder der
Bodensee nicht als Wasserfläche gerendert. Auslaufen pasiert in keinem der Renderer.
Kann aber am Zeitversatz der Kachel-Updates liegen.

Das war falsch ausgedrückt, ich meinte da hat jemand den Stöpsel gezogen.
Das wird gerade alles neu gerendert, das sollte funktionieren nur das einfachste Objekt, der in sich geschlossene (ohne Relation) Obersee ist immer noch leer.

Ich finde den Bodensee könte man sehr gut in einzelne, geschlossene Flächen splitten:

Obersee, Untersee (das wird wohl schon so gemacht).

deutscher Teil, östereichischer Teil, schweizer Teil.

den deutschen und schweizer Teil müsste/könnte man von der Größe her
vielleicht noch einmal unterteilen.

Ich finde das jetzt schon so ok, das lässt sich ohne Probleme bearbeiten.
Den Obersee abzutrennen macht Sinn weil er einen eigenen Namen hat (Überlinger See).

EvanE · 2010-01-24T03:13:36.000Z

Nightdive:

EvanE:

Richtig schräg, je nach Renderer wird im Moment mal der Obersee, der Untersee oder der
Bodensee nicht als Wasserfläche gerendert. …

Das war falsch ausgedrückt, ich meinte da hat jemand den Stöpsel gezogen.
Das wird gerade alles neu gerendert, das sollte funktionieren nur das einfachste Objekt, der in sich geschlossene (ohne Relation) Obersee ist immer noch leer.

Der Obersee ist nur in Mapnik leer, in den anderen drei ist er gefüllt.
Warten wir mal morgen ab .

Nightdive:

EvanE:

Ich finde den Bodensee könte man sehr gut in einzelne, geschlossene Flächen splitten:

…

Ich finde das jetzt schon so ok, das lässt sich ohne Probleme bearbeiten.
Den Obersee abzutrennen macht Sinn weil er einen eigenen Namen hat (Überlinger See).

OK, jeder wie er mag.
Mit gerade mal 4 Segmenten ist die Relation noch übersichtlich.
Der Gnadensee (Untersee bei mir) ist ja durch den Seerhein vom Bodensee getrennt.

Edbert (EvanE)

schmalzlocke · 2010-01-24T13:46:35.000Z

Danke für eure antworten. In den nächsten Wochen werde ich dann mal den Reichswald “umbauen”!

Schönes Restwochenende