Was ist da faul mit dem Waldpolygon?

tippeltappel · 2010-12-28T21:06:34.000Z

Die Doppelfunktion von meadow als inner und outer in zwei verschiedenen Multipolygonen muß wegen der Verschachtelung sein.
Aber das landuse in den Multipolygonen hab ich mal raus genommen.
Setze ich sonst nie.
Kann mich erinnern, daß ich da was probiert habe, weil ich irgendwo las, man solle das machen.
Möglicherweise ist das die Fehlerursache.

Mal sehen, wie das dann in ein paar Tagen auf der Wanderreitkarte aussieht.

Danke für den Tipp.

Gruß
tippeltappel

GeorgFausB · 2010-12-30T16:58:03.000Z

Moin,

tippeltappel:

Aber das landuse in den Multipolygonen hab ich mal raus genommen.
Setze ich sonst nie.
Kann mich erinnern, daß ich da was probiert habe, weil ich irgendwo las, man solle das machen.
Möglicherweise ist das die Fehlerursache.

Früher wurden Multipolygon-Relationen anscheinend eher nur als Render-Hilfen benutzt, heute dagegen als Flächen-Typ.
Die Systematik heute ist daher folgende:

Tags am outer way beziehen sich auf die gesamte Fläche innerhalb des geschlossenen Weges.
Tags an der Multipolygon-Relation beziehen sich auf die von der Relation beschriebene Fläche.
Damit kommen m. W. alle Renderer inkl. Wanderreitkarte zurecht.

Insofern hast Du genau das falsche landuse weggenommen.
(Relation 1121266)

Gruß
Georg

fkv · 2010-12-30T20:30:40.000Z

Die Online-Wanderreitkarte ignoriert Wald-Multipolygone generell. Genauso wie Gebäude-Multipolygone. Vielleicht kann sie überhaupt keine Multipolygone.

In den Garmin-Karten, die man von wanderreitkarte.de runterladen kann, scheinen die Multipolygone hingegen zu stimmen.

de_muur · 2010-12-30T21:14:04.000Z

GeorgFausB:

Früher wurden Multipolygon-Relationen anscheinend eher nur als Render-Hilfen benutzt, heute dagegen als Flächen-Typ.

Als Renderer-Hilfen waren die Multipolygone nie gedacht. Allerdings hat sich in letzter Zeit wohl das uebliche Tagging der multipolygone gewandelt:

Im Prinzip hat man es bei einem Multipolygon mit drei Flaechen zu tun.

A - die Gesammtflaeche innerhalb des Outer-Polygons (Es koennen theoretisch auch mehrere Outer-Polygone sein, aber das sollte man zur besseren Uebersicht tunlichst vermeiden.)

B - die Flaeche innerhalb des Inner-Polygons (Es koennen auch mehrer Inner-Polygone sein, die sich dann aber nicht ueberschneiden sollten. In der Theorie sind auch mehrere Inner-Polygonzuege erlaubt, die gemeinsam eine Flaeche beschreiben, das sollte man aber genauso wie mehrere Outer-Polygone eher nicht benutzen.)

C - die eigentliche Multipolygonflaeche also quais A ohne B.

I - Historisch gesehen hat man bei den ersten Multipolygonen nur die Flaeche C beschrieben, indem man die Inner und Outer-Polygon gleich markiert hat. Waehrend dieser Phase war die Umlaufrichtung der Polygone auch ncoh zwingend vorgeschrieben. Diese Variante ist aber veralltet und mit den heutigen Varianten nicht kompatibel. Sie sollte also auf keinen Fall mehr benutzt werden.

II - Danach war es ueblich, dass man die Markierungen fuer die Flaeche C an die Outer-Polygone gesetzte hat. Die Umlaufrichtung der Polygone war egal, und die Flaeche B konnte eigenstaendig an den Inner-Polygonen markiert werden. Im Vergleich zur gleich folgenden dritten Variante (III) hat dieser Ansatz den Vorteil, dass bei den Renderen auch noch was teilweise brauchbares angezeigt wird, wenn die Renderer die Multipolygon-Relation selber nicht erkennen (eventuell wird das Inner-Polygon beim Rendere vom Outer ueberdeckt, aber die Anzeige des Outer-Polygons ist immerhin sicher gegeben, wenn auch als Flaeche A anstelle von Flaeche C.)

Dieser Ansatz funktioniert auch heute noch, solange man die Multipolygon-Relation selber nicht markiert. Das ist quasi fuer die Auswertunsgprogramme das Unterscheidunsgmerkmal, ob diese Variante II oder die folgende Variante III bei der Markierung benutzt wird.

III - Heute ist es (wohl) ueblich, die Tags zur Beschreibung der Flaeche C in die Relation selber zu schreiben. Daneben kann man gleichzeitig ans Outer-Polygon die Tags fuer die Flaeche A und ans Inner-Polygon die Tags fuer die Flaeche B setzen. Im prinzip ist das die logisch sauberste Markierung, funktioniert aber halt nur, wenn die Auswerteprogramme auch damit umgehen koennen.

Probleme koennen jetzt heute entstehen, wenn man ein urspruenglich nach Variante II markiertes Multipolygon nun nach Variante III erweitert. Deshalb sollte man sich bei einem Multipolygon immer auch die Tags des Outer-Polygons anschauen und dann entscheiden, ob diese wirkloch ans Outer-Polygon (also Flaeche A) gehoeren, oder ob damit nicht eher die Flaeche C gemeint ist, und sie somit in die Relation verschoben werden sollten.

Gruss
Torsten

SunCobalt · 2010-12-30T21:18:11.000Z

GeorgFausB:

Tags am outer way beziehen sich auf die gesamte Fläche innerhalb des geschlossenen Weges.
Tags an der Multipolygon-Relation beziehen sich auf die von der Relation beschriebene Fläche.
Damit kommen m. W. alle Renderer inkl. Wanderreitkarte zurecht.

Das möchte ich mal arg bezweifeln. In den meisten Konstellationen ist es für die meisten Renderer ziemlich egal, ob der landuse Tag im MP oder outer Way ist. Der inner Teil wird trotzdem ausgeschnitten. Ich tagge je nach Potlatch Dichte den landuse Tag mal an den Outer Way und mal korrekt ins MP…ja schlagt mich ruhig. Ich habe noch nirgends ein Problem damit gehabt. Nur eine Ausnahme. Das habe ich neulich durch Zufall gelernt. Will man einen Wald im Wald bspw Nadel- in Mischwald darstellen, klappt das am outer Way nicht mehr.

Basstoelpel · 2010-12-31T08:44:26.000Z

GeorgFausB:

Moin,

Tags am outer way beziehen sich auf die gesamte Fläche innerhalb des geschlossenen Weges.
Tags an der Multipolygon-Relation beziehen sich auf die von der Relation beschriebene Fläche.
Damit kommen m. W. alle Renderer inkl. Wanderreitkarte zurecht.

Kommen alle auch damit zurecht, wenn tags für eine Eigenschaft der gesamten Fläche am outer way steht und tags für eine andere Eigenschaft, die die Relationsfläche betrifft, an der Relation?

Vor einiger Zeit wurden Flächen, deren Eigenschaften mit der Relation beschrieben wurden nicht mehr gerendert, wenn am äußeren Polygon auch tags waren. Ist das noch so?

Baßtölpel

tippeltappel · 2010-12-31T11:45:19.000Z

Vielen Dank für Eure Überlegungen und Erklärungen.
In der neuen Version wird das oben verlinkte Multipolygon nach wie vor nicht angezeigt.
http://www.wanderreitkarte.de/index.php?lon=6.4486&lat=50.4947&zoom=15 (edit 1.1.11 permalink korrigiert)
http://www.openstreetmap.org/?lat=50.4936&lon=6.45011&zoom=16&layers=M

Ein anderes verschachteltes Multipolygon kommt dagegen perfekt heraus:
http://www.wanderreitkarte.de/index.php?lon=6.6207&lat=50.6239&zoom=18
http://www.openstreetmap.org/?lat=50.623375&lon=6.620908&zoom=18&layers=M
Der systematische Aufbau der beiden Multipolygone ist sehr ähnlich.
Gravierender Unterschied sind die Elemente selbst. Im Multipolygon von Burg Eicks kommt weder landuse=forest noch landuse=meadow vor.
Die Grünfläche ist mit leisure=park definiert. (Schloßpark)

fkv:

Die Online-Wanderreitkarte ignoriert Wald-Multipolygone generell. Genauso wie Gebäude-Multipolygone. Vielleicht kann sie überhaupt keine Multipolygone.
…

Das ist völlig falsch.
Worauf stützt Du Deine Vermutung?

Das hier ist ein Wald-Multipolygon auf der Wanderreitkarte:
http://www.wanderreitkarte.de/index.php?lon=6.3032&lat=50.5046&zoom=15 (edit 1.1.11 permalink korrigiert)
http://www.openstreetmap.org/?lat=50.50515&lon=6.30759&zoom=15&layers=M

Deutlich zu erkennen, die per Multipolygon definierten “Löcher”.
Ebenfalls deutlich zu erkennen: Für landuse=meadow sind in der Wanderreitkarte keine Renderregeln definiert
Nop macht das ganz bewußt. Warum auch immer.
Im Composer sind sie übrigens auch nicht als Default hinterlegt.
Wer diese Flächen also sehen möchte, muß die Renderregel nachträglich einfügen.

Gebäude-Multipolygone werden von der Wanderreitkarte ebenfalls angezeigt.
Burg Eicks ist ein prima Beispiel dafür.

Was also verursacht den Fehler?
Aufbau und Anzeigefehler des verschachtelten Multipolygons Hellenthaler Wald - Beobachtungen:

das äußere Multipolygon-Element landuse=forest Rolle=outer wird nicht angezeigt, obwohl die Wanderreitkarte das prinzipiell kann
die daraus ausgeschnittene Fläche Rolle=inner landuse=meadow wird nicht angezeigt, weil die Wanderreitkarte dieses tag grundsätzlich ignoriert
Die nicht angezeigte Fläche landuse=meadow wurde gleichzeitig als weiteres Multipolygon mit der Funktion Rolle=outer definiert, um daraus darin liegende Flächen ausschneiden zu können
die kleinen in landuse=meadow liegenden Flächen wurden mit der Funktion Rolle=inner definiert und sind dem unter 3. genannten Multipolygon zugeordnet. Die drei aus meadow ausgeschnittenen Flächen mit den Tags landuse=forest und landuse=farmyard werden in der WRK dargestellt.

Diese Art von verschachtelten Multipolygonen ist im Prinzip korrekt, funktioniert und wird im Falle Eickser Burg von beiden Renderern korrekt umgesetzt.
Erhebt sich nun die Frage, warum dasselbe Prinzip beim Hellenthaler Wald nicht funktioniert.
Liegt es daran, daß landuse=meadow nicht in den WRK-Renderregeln enthalten ist?
Warum aber werden dann andere Waldmultipolygone dargestellt? Die ausgeschnittenen Wiesenflächen werden zwar nicht als grüne Flächen dargestellt, sind aber als Löcher wahrnehmbar.

Der einzigen Grund, den ich mir für das Fehlverhalten vorstellen kann, wäre, daß der Renderer bei der Bearbeitung der verschachtelten Flächen aus irgendeinem Grund über das nicht definierte Element landuse=meadow stolpert.

Die einzige Möglichkeit, das herauszufinden ist, landuse=meadow durch ein Tag zu ersetzen, das in den Renderregeln enthalten ist.
…

In ein paar Tagen wissen wir mehr.

Ein gutes, neues Jahr!

tippeltappel

fkv · 2010-12-31T18:55:12.000Z

tippeltappel:

Das hier ist ein Wald-Multipolygon auf der Wanderreitkarte:
http://www.wanderreitkarte.de/index.php?lon=11.1064&lat=51.3376&zoom=15

Kannst du eine Relations-ID nennen? In dieser Gegend gibt es einige landuse=forest, aber ich sehe kein einziges auf einer Relation.

Gebäude-Multipolygone werden von der Wanderreitkarte ebenfalls angezeigt.
Burg Eicks ist ein prima Beispiel dafür.

Nein, das ist ein fehlerhaftes MP (bzw. wie von de_muur beschrieben eines von der antiquierten Sorte). Hier sitzt der building-tag nicht am MP, sondern am Way. Und sowas rendert die Wanderreitkarte sehr wohl. Die Relation wird dabei schlichtweg ignoriert. Wenn du sie weglässt, kriegst du das selbe Ergebnis. Der Grund, warum das Gebäude ein “Loch” hat, ist, dass im Loch ein landuse=meadow steckt. Kleinere Flächen werden nach größeren gerendert (oder man kann sagen, sie haben die höhere Priorität, oder sie werden darüber gelegt, es bedeutet alles dasselbe).

Worauf stützt Du Deine Vermutung?

Schau dir mal einen Teil meines Wohnbezirks an:
richtig: http://www.openstreetmap.org/?lat=48.1782&lon=16.37264&zoom=17&layers=M
WRK: http://www.wanderreitkarte.de/?lat=48.1782&lon=16.37264&zoom=17

tippeltappel · 2011-01-01T15:31:47.000Z

Sorry, da hat der Permalink “geklemmt”.
Habe die Links korrigiert.

Darüber, ob das Mulipolygon “Burg Eiks” fehlerhaft ist, kann man geteilter Meinung sein.
Und unter antiquiert verstehe ich auch etwas anderes.
Es ist ein klares, übersichtliches System.

Das neue System finde ich total unübersichtlich.
Denn in Deinem Beispiel läßt sich nicht auf Anhieb erkennen, um welche Flächen es geht.
Die Innenflächen die ich mir angesehen habe, werden von dem Multipolygon alle nicht definiert. Wozu soll das gut sein?

Ich finde das alte System besser und klarer.

In der Wanderreitkarte, ergibt sich durchaus ein großer Unterschied, wenn man die Relation wegläßt.
Dann ist der Wald ohne Löcher.

http://www.wanderreitkarte.de/index.php?lon=6.5158&lat=50.5792&zoom=15
http://www.openstreetmap.org/?lat=50.57852&lon=6.51584&zoom=15&layers=M

Alles Gute zum neuen Jahr
tippeltappel

PS: Das Update vom 31. 12. zeigt die ausgeschnittene Wiesenfläche jetzt korrekt an.
Das falsche landuse ist in den Daten noch nicht enthalten. Da hat wohl eine andere Korrektur gegriffen.
Daher setze ich das falsche landuse jetzt wieder zurück.

tippeltappel · 2011-01-01T16:53:50.000Z

Ein Beispiel für übereinander gestapelte Polygone:
http://www.openstreetmap.org/?lat=50.55602&lon=6.52167&zoom=15&layers=M
http://www.wanderreitkarte.de/index.php?lon=6.5237&lat=50.5568&zoom=16

Die Wanderreitkarte ignoriert auch hier landuse=meadow.
Da kein Multipolygon definiert wurde, hat der Wald keine Löcher.

natural=scrub wird dargestellt
Wer genau hinsieht, erkennt, daß der Wald unter der leicht transparenten scrub-Fläche durchscheint.
Ein deutlicher Hinweis darauf, daß die “Lappen” übereinander gelegt und nicht der kleine in den großen intharsienmäßig eingepaßt wurde.

Ganz anders dagegen dieser Bereich, wo die kleinen Flächen mit Hilfe der Multipolygon-Technik in die große Fläche eingepaßt sind bzw. heraus geschnitten wurden:
http://www.wanderreitkarte.de/index.php?lon=6.5139&lat=50.4280&zoom=16
http://www.openstreetmap.org/?lat=50.428&lon=6.5139&zoom=16&layers=M

Unter “scrub” schimmern jetzt keine Waldsymbole mehr durch.

Gruß
tippeltappel

fkv · 2011-01-01T17:18:08.000Z

tippeltappel:

Das neue System finde ich total unübersichtlich.

Weiß nicht, was daran unübersichtlich sein soll.

einfache Flächen:

Auf den Ring setzt du die Tags, die sich nur auf diesen (oder seine Gesamtfläche) beziehen.

Relationen:

Auf den äußeren Ring setzt du die Tags, die sich nur auf diesen (oder seine Gesamtfläche) beziehen.

Auf den inneren Ring setzt du die Tags, die sich nur auf diesen (oder seine Gesamtfläche) beziehen.

Auf die Relation setzt du die Tags, die sich auf die Differenzfläche beziehen.

Du siehst, nur der letzte Punkt ist was Neues.

Wenn du - wie du es getan hast - die Tags für die Differenzfläche auf den äüßeren Ring setzt, kann der Renderer nicht wissen, welche sich auf die Gesamtfläche beziehen und welche nur auf die Differenzfläche. Beispiel: landuse=forest und access=yes. Bezieht sich nur das landuse=forest auf die Differenzfläche und access=yes auf alles, oder bezieht sich nur das access=yes auf die Differenzfläche und landuse=forest auf alles, oder beziehen sich beide auf die Differenzfläche? Darum das “neue” system, da ist das klar definiert.

Das neue System bietet außerdem den Vorteil, dass man jeden Ring aus mehreren Teilstücken zusammenstückeln kann. Z.B. du hast einen riesengroßen Wald, daneben eine riesengroße Wiese, und die Grenze bildet ein langer Zaun, der so verwinkelt ist, dass du 100 Nodes dafür brauchst. Mit dem alten System müsstest du diesen ganzen Zaun 2x nachzeichnen (für jede Fläche 1x). Mit dem neuen System sparst du dir das. Du machst Wald und Wiese jeweils zu einem MP und hängst den Zaun als outer ein. Das ist dann auch beim Editieren viel übersichtlicher, weil nicht 3 Linien aufeinander liegen.

tippeltappel:

Wer genau hinsieht, erkennt, daß der Wald unter der leicht transparenten scrub-Fläche durchscheint.

Dann habe ich mich in dieser Hinsicht geirrt. Das ändert nichts daran, dass die Wanderreitkarte moderne Polygone nicht rendert. Das ist ein Fehler der Wanderreitkarte, und diese Diskussion ist ein Streit um des Kaisers Bart, weil sie an diesem Programmfehler nichts ändert.

de_muur · 2011-01-01T18:55:17.000Z

fkv:

Das neue System bietet außerdem den Vorteil, dass man jeden Ring aus mehreren Teilstücken zusammenstückeln kann. Z.B. du hast einen riesengroßen Wald, daneben eine riesengroße Wiese, und die Grenze bildet ein langer Zaun, der so verwinkelt ist, dass du 100 Nodes dafür brauchst. Mit dem alten System müsstest du diesen ganzen Zaun 2x nachzeichnen (für jede Fläche 1x). Mit dem neuen System sparst du dir das. Du machst Wald und Wiese jeweils zu einem MP und hängst den Zaun als outer ein. Das ist dann auch beim Editieren viel übersichtlicher, weil nicht 3 Linien aufeinander liegen.

Das sollte man in der Praxis aber UNBEDINGT vermeiden. Dieser Ansatz klingt zwar in der Theorie ganz nett, macht die Datenstrukturen aber so kompliziert, dass da kein anderer Mapper mehr durch steigt (und man selbst ein paar Wochen spaeter wahrscheinlich auch nicht mehr). Es gibt schon genug Leute, die Schwierigkeiten damit haben, wennn mehrere Wege ueberienander liegen, Wenn man nun anstatt mehrerer Wege mehrere Relationen uebereinander stapelt, dann gewintt man da Null Uebersicht, sondern verlagert das Problem nur auf eine hoehere Abstraktionsebene.

Allgemein sollte man zu grosse Flaechenelemente vermeiden. (Sie sind fuer die Mapper zu unuebersichtlich und fuer die Auswerteprogramme erhoehen sie den Aufwand, da diese dann auf uebermaessig grossen Abschnitten Arbeiten muessen.) Riesengrosse Flaeche sollte man stattdessen lieber sinnvoll in Teilflaechen zerlegen, z.B. einen Wald entlang einer Strasse teilen.
Nicht ohne Grund hat man in der letzten API-Aenderung ein Limit fuer die Knotenanzahl eines Ways eingefuehrt.

Gruss
Torsten

errt · 2011-01-01T21:01:28.000Z

@fkv: Aber das widerspricht sich. Es kann nicht sein, dass man einerseits Tags, die sich auf die Gesamtfläche beziehen an die äußeren Wege hängen soll, andererseits aber diese äußeren Wege stückeln und mehrfach benutzen kann. Meiner Meinung nach gilt: Tags am inneren Weg gelten nur für das Innere, Tags am äußeren Weg sowie der Relation nur für die Differenzfläche, wobei man sie an den äußeren Weg hängt, wenn der aus einem Stück besteht und nicht wiederbenutzt werden soll und ansonsten an die Relation. Dinge die für die gesamte Fläche gelten, werden an den äußeren und inneren Weg (bzw. Relation und inneren Weg) getaggt. Alles andere macht doch keinen Sinn.

fkv · 2011-01-01T21:24:59.000Z

de_muur:

Das sollte man in der Praxis aber UNBEDINGT vermeiden. Dieser Ansatz klingt zwar in der Theorie ganz nett, macht die Datenstrukturen aber so kompliziert, dass da kein anderer Mapper mehr durch steigt (und man selbst ein paar Wochen spaeter wahrscheinlich auch nicht mehr). Es gibt schon genug Leute, die Schwierigkeiten damit haben, wennn mehrere Wege ueberienander liegen, Wenn man nun anstatt mehrerer Wege mehrere Relationen uebereinander stapelt, dann gewintt man da Null Uebersicht, sondern verlagert das Problem nur auf eine hoehere Abstraktionsebene.

Ich meine nicht übereinander, sondern nebeneinander (mosaikartig). Einer der häufigsten Fehler auch geübter Mapper ist es, nebeneinander liegende Flächen nicht zu verbinden, weil sie sich damit nicht auskennen. Dadurch bleiben in den Karten hässliche Streifen frei. Hier sind Multipolygone das Mittel der Wahl, und man sollte mal ein Tutorial ins Wiki stellen, damit MP-Mosaike mehr Verbreitung finden. Wenn das passiert, schauen sich die Mapper das eh voneinander ab. Diese Sache wird tendenziell immer wichtiger, denn die Wälder, Äcker und Residentials, die einst isoliert in der Karte standen, treffen mit wachsendem Vollständigkeitsgrad immer mehr aufeinander.

Allgemein sollte man zu grosse Flaechenelemente vermeiden. (Sie sind fuer die Mapper zu unuebersichtlich und fuer die Auswerteprogramme erhoehen sie den Aufwand, da diese dann auf uebermaessig grossen Abschnitten Arbeiten muessen.)

Programme sind geduldig, und der Aufwand hängt nach meiner Berechnung nicht davon ab, ob eine Fläche ein MP ist oder wie viele Members es hat. Fürn Menschen sind große MP natürlich unübersichtlich, da gebe ich dir recht. Als z.B. ein Validator bei http://www.openstreetmap.org/browse/relation/1258056 einen offenen Ring angemeckert hat, musste ich eine Weile suchen…

Riesengrosse Flaeche sollte man stattdessen lieber sinnvoll in Teilflaechen zerlegen, z.B. einen Wald entlang einer Strasse teilen.

Oder in gerader Linie, damit man bei Änderungen an der Straße sich nicht ums MP kümmern muss.

Ja, riesengroße Flächen sollte man teilen, aber man muss halt einen Mittelweg finden, denn eine lange Liste an Relationen ist genauso unübersichtlich wie eine zu große Relation.

Nicht ohne Grund hat man in der letzten API-Aenderung ein Limit fuer die Knotenanzahl eines Ways eingefuehrt.

Das Limit macht die Multipolygone nicht einfacher, wenn man deswegen die Ways in kleinere Stücke zerteilt und damit noch mehr Objekte bekommt. Ich vermute den Grund für das Limit daher woanders: In der EDV ist es seit jeher üblich, für alles, was sehr groß werden kann, Limits zu definieren, damit es zu keinen Überläufen kommt.

SunCobalt · 2011-01-01T21:35:35.000Z

fkv:

Ich meine nicht übereinander, sondern nebeneinander (mosaikartig). Einer der häufigsten Fehler auch geübter Mapper ist es, nebeneinander liegende Flächen nicht zu verbinden, weil sie sich damit nicht auskennen. Dadurch bleiben in den Karten hässliche Streifen frei.

Auch bei MPs bleiben Streifen. Hier mal ein Wald-MP. Vielleicht möchte sich Torsten am vereinfachen versuchen, denn das MP besteht trotz Teilung noch aus mehreren tausen Nodes in den outer Ways. Vor der Teiling waren es ca. 65.000 Nodes in den outer Ways. Ich bin fast verzweifelt und war happy es so hinzubekommen, wie es ist. Ein kariertes Holzfäller-Shirt würde ich auch nicht draus machen, selbst wenn ich mal die Zeit dafür hätte.
http://www.openstreetmap.org/?lat=44.43&lon=22.02&zoom=11&layers=M

fkv · 2011-01-01T22:13:44.000Z

errt:

Es kann nicht sein, dass man einerseits Tags, die sich auf die Gesamtfläche beziehen an die äußeren Wege hängen soll, andererseits aber diese äußeren Wege stückeln und mehrfach benutzen kann.

Ein guter Punkt. Zum Glück kommt es selten vor, dass man beides gleichzeitig braucht. In so einem Fall müsste man halt 2 Relationen anlegen, eine mit dem Loch und eine ohne. Zwar umständlich, aber immer noch besser als im alten System, wo so etwas überhaupt nicht geht.

SunCobalt:

Auch bei MPs bleiben Streifen. Hier mal ein Wald-MP.

Aha. Aber da würde ich sagen, das ist ein Renderer-Bug. Mapnik und Osmarender sind halt noch lang nicht perfekt…

errt · 2011-01-01T23:26:35.000Z

fkv:

Ein guter Punkt. Zum Glück kommt es selten vor, dass man beides gleichzeitig braucht. In so einem Fall müsste man halt 2 Relationen anlegen, eine mit dem Loch und eine ohne. Zwar umständlich, aber immer noch besser als im alten System, wo so etwas überhaupt nicht geht.

Ist natürlich die Frage: Was brauche ich häufiger: Tags gelten für Gesamtfläche oder Tags gelten für Differenzfläche. Dafür müsste man erstmal klären, ob man Lichtungen, die man mit einem Multipolygon ausschneidet noch zum Wald gehören, also das landuse=forest dafür ebenfalls gilt. Ich denke eher nicht - und dann dürfte der Differenzflächenfall häufiger sein. Außerdem ist mit dem alten System (zumindest so wie von mir beschrieben) auch alles darstellbar. Du hängst weiterhin alle Tags an den äußeren Weg (es sei denn, er ist gespalten oder aus sonst einem Grund passt es besser an die Relation) und alles, was bei dir an die Relation kommt an beide ways. Das scheint mir wesentlich logischer und verständlicher als zwei Relationen im von mir gebrachten Beispiel. Und es ermöglicht vermutlich leichteres Fallback-Rendering, wenn ein Renderer die Relationsmethode nicht kennt (wobei der sowieso Probleme hat, spätestens, wenn man den Weg spalten muss).

Und ja, die Streifen sind wohl ein Renderer-Fehler. Ich würde große Flächen nicht aufteilen, sondern höchstens eben die Wege splitten. Schon aus logischen Gründen: Ein Wald=Eine Fläche in OSM. Ich denke, mittlerweile sind die Renderer auch da so weit, dass große Flächen keine argen Probleme mehr machen, oder?

de_muur · 2011-01-02T07:57:41.000Z

fkv:

Ich meine nicht übereinander, sondern nebeneinander (mosaikartig).

Genau diesen Fall meine ich auch. Noch mal praeszieser gesagt: Es ueberschneiden sich hier nicht die Flaechen selber sondern nur ihre Randlininien.

Einer der häufigsten Fehler auch geübter Mapper ist es, nebeneinander liegende Flächen nicht zu verbinden, weil sie sich damit nicht auskennen. Dadurch bleiben in den Karten hässliche Streifen frei. Hier sind Multipolygone das Mittel der Wahl,

Dieser “Fehler” kommt daduch, weil mehrere ueberienanderliegende Linien je nach Editor mehr oder weniger schwer zu handhaben sind.
Und wenn du diese “mehreren Linien” nun durch “eine Lininie, die Mitglied in mehreren Relationen ist,” ersetzt, dann machst du das problem nicht besser sondern noch viel schlimmer. Da steigt ein Anfaenger/Gelegenheitsmapper auf keinen Fall mehr durch und richtet auch bei kleinsten Aenderungen nur voelliges Chaos an.

Man koennte ja darauf hoffen, dass mit vorranschreitender Editor-Entwicklung auch die Unterstuetzung fuer solche Konstrukte besser wird. Da es aber bei OSM nicht DEN Editor gibt sondern jeder sein Lieblingsprogramm in seiner Lieblingsversion benutzt, besteht da eigentlich keine Hoffnung.

Also nochmal: Das Stueckeln der Randlinien von Flaechen sollte man z.Z. unbedingt unterlassen. Das bringt viel mehr Nachteile als Vorteile.

Nebenbei bemerkt: Fuer eine zukuenftige API ist als Erweiterung ein Flaechentyp im Gespraech, der auf diesem erweiterten Multipolygonansatz beruht. Wenn das mal kommt, dann MUSS das ja von allen Editoren ordentlich unterstuetzt werden. Bis dahin sollte man das aber aussitzen und keine kuenstlichen Probleme schaffen.

Programme sind geduldig, und der Aufwand hängt nach meiner Berechnung nicht davon ab, ob eine Fläche ein MP ist oder wie viele Members es hat. Fürn Menschen sind große MP natürlich unübersichtlich, da gebe ich dir recht. Als z.B. ein Validator bei http://www.openstreetmap.org/browse/relation/1258056 einen offenen Ring angemeckert hat, musste ich eine Weile suchen…

Du vergisst, dass eigentlich jedes Auswerteprogramm nur auf einem bestimmten Gebiet der weltweiten Karte arbeitet (Die Renderer z.B. rechnen ja nur relativ kleine Kacheln auf ein mal). Und je groesser ein einzelne Element ist, um so wahrscheinlicher ragt es aus diesem Gebiet heraus und in um so mehr Gebieten tritt es auf. Das Erhoeht den aufwand schon recht deutlich.

Das Limit macht die Multipolygone nicht einfacher, wenn man deswegen die Ways in kleinere Stücke zerteilt und damit noch mehr Objekte bekommt. Ich vermute den Grund für das Limit daher woanders: In der EDV ist es seit jeher üblich, für alles, was sehr groß werden kann, Limits zu definieren, damit es zu keinen Überläufen kommt.

Wenn du irgendwelche Rechnungen mit den Objekten anstellst (z.B. was liegt innerhalb, was liegt ausserhalb), dann steigt bei diesen Rechnungen der Aufwand eigentlich immer staerker als linear mit der Objektgroesse. Klar sind Rechner geduldig. Aber erstens brauchen Rechner zum Rechnen Strom und zweitens wollen wir doch auch alle moeglichst haeufige Updates von unseren Karten/Statistiken usw. Das muss man ja nicht unnoetig behindern.
Es ist also schon effizienter, wenn man zehn Flaechen mit 1000 Randpunkten in der Datenbank hat anstatt einer Flaeche mit 10000 Randpunkten.
Und es hilft eben nichts, wenn man nur die Randlinien in mehrere teile aufspaltet und dieses dann per Multipolygon wieder zu einem Element zusammenfasst. Denn in dem fall hat man es ja wieder mit einem zu grossen Element zu tun.

Gruss
Torsten

de_muur · 2011-01-02T12:27:03.000Z

SunCobalt:

Vielleicht möchte sich Torsten am vereinfachen versuchen, denn das MP besteht trotz Teilung noch aus mehreren tausen Nodes in den outer Ways. Vor der Teiling waren es ca. 65.000 Nodes in den outer Ways. Ich bin fast verzweifelt und war happy es so hinzubekommen, wie es ist. Ein kariertes Holzfäller-Shirt würde ich auch nicht draus machen, selbst wenn ich mal die Zeit dafür hätte.
http://www.openstreetmap.org/?lat=44.43&lon=22.02&zoom=11&layers=M

Was fuer ein Alptraum.

Das zeigt aber ganz deutlich, was ich meine, wenn ich sage, dass zu grosse Objekte nicht handhabbar sind. Wenn man da mal in der Region weitere Details erfassen will, dann wird man das sicherlich noch deutlich weiter aufteilen muessen.

Wahrscheinlich haette man die Daten besser vor dem Import schon mal ordentlich segmentieren sollen. Damit haette man einen Computer beauftragen koennen und muesste sich nicht in Zukunft immer wieder in der OSM-Datenbank damit rumschlagen. Aber dafuer ist es nun zu spaet, also nutzen wir das Ergebniss als abschreckendes Beispiel

Gruss
Torsten

tippeltappel · 2011-01-02T20:47:16.000Z

@ fkv
Es ist schon eigenartig, wie Du darauf herum reitest, daß die Wanderreitkarte keine modernen Relationen darstellen kann.
Wenn dem so wäre, läge es nicht an der Wanderreitkarte, sondern an dem Renderprogramm, mit dem sie erstellt wird. Und das betrifft dann auch alle anderen Karten, die mit diesem Renderprogramm hergestellt werden. Darüber zu diskutieren bringt aber nichts, denn zur Problemlösung trägt das bei den von mir genannten Beispielen nicht bei.

Bei diesen Beispielen war bisher jedes Mal eine winzige, kaum sichtbare Überschneidung von zwei nebeneinander liegenden Multipolygonen die Fehlerursache. Nachdem ich sie gefunden hatte, erschienen die Flächen richtig auf der Wanderreitkarte.
Daß der Mapnik-Renderer die fehlerhaften Multipolygone trotzdem richtig dargestellt hat, spricht für seine Fähigkeit, Fehler zu ignorieren. Deshalb ist der für die Wanderreitkarte genutzte Renderer nicht schlechter. Ich würde ihn eher empfindlicher nennen. Und diese Empfindlichkeit erzieht zu sauberem Mappen, was nicht unbedingt ein Nachteil ist.

Ein anderes Problem ist die Darstellung übereinander gelegter Polygone, die ohne Einbindung in Multipolygon-Relationen einander überdecken.
Bei der Schichtung übereinanderliegender, einfacher Polygone spielen die vom Kartenbastler erstellten Renderregeln eine Rolle.
Zumindest war es bislang so, daß man die Möglichkeit hat Layer zu definieren, mit deren Hilfe die Reihenfolge der “Stapelung” unabhängig von der Größe der Polygone bestimmt wird. Außerdem spielt noch die Reihenfolge der Elemente während des Renderprozesses eine Rolle. Inwieweit sich da das Rendererverhalten eventuel verändert hat, indem beispielsweise die Größe der Polygone im Gegensatz zu früher berücksichtigt werden, kann ich nicht beurteilen. Es ist mir auch ziemlich egal. Jedenfalls war es bei diesem System ursprünglich nicht möglich, Polygone mit derselben Definition sowohl zu oberst als auch zu unterst darzustellen. Beispiel: riesiger Wald - darin große Wiese - darin ein See - darin eine bewaldete Insel. Je nach Aufbau der Renderfolge verschwand entweder der kleine Wald unter der Wiese oder alles unter dem großen Wald.
Diesem Mißstand kamen die Multipolygone mit den outer und inner Definitionen bei, indem mit ihrer Hilfe in die outer-Flächen Löcher geschnitten werden. Schon das einfache System läßt theoretisch eine endlose Verschachtelung zu, indem eine inner-Fläche gleichzeitig als outer-Fläche einer weiteren Relation für darin liegende Ausschnitte definiert werden kann.
Sofern man sich an das einfache Grundprinzip hält, daß mit einem Außenring stets ausschließlich die nächsten Innenringe in einer Relation zusammengefaßt werden, bleibt das ganze klar und übersichtlich. Und wenn jeder Ring auch noch seine Flächentags trägt, weiß man immer, woran man ist.
Wenn der gar nicht so seltene Fall eintritt, daß eine verschiedene Multipolygone überdeckende Fläche definiert werden muß, handelt es sich meiner bisherigen Erfahrung nach um Flächen wie z.B. Naturschutzgebiete, Militärgebiete, Freizeitparks, Freilichtmuseen oder politische bzw. Verwaltungs-Einheiten (Ortschaften etc. )
Solche Flächen sind in Karten, in denen sie nicht transparent gerendert werden, ein Problem. Entweder überdecken sie alle Details oder aber sie verschwinden bei komplett gemappter Landbedeckung mehr oder weniger unter den Details. Je nach dem, in welchem Layer sie stecken. Da helfen auch die modernen Multipolygone nicht. Denn das ist keine Frage ob der Renderer mit Multipolygonen umgehen kann, sondern abhängig davon, welche *.png der Kartenbastler für diese Flächen einsetzt.

Wenn er geschickt ist, sucht er sich für häufig auftretende Kombinationen *.png aus, deren transparente Muster sich gut kombinieren lassen. Dann ergibt sich ein ähnlicher Effekt, wie bei einer Overheadprojektor-Präsentation, wenn nach und nach mehrere Folien übereinander gelegt werden.

Solche übergreifenden Flächen in ein Multipolygon zu stecken, mag für die Analyse der Datenbank theoretisch interessant sein. Und da macht die Auslagerung der Eigenschaften in die Relation auch durchaus Sinn, weil man dann bei jedem Relationsmitglied durch Einsicht in die Relationstags feststellen kann, welcher abstrakten Einheit die Fläche zugeordnet ist. Den Nutzen sehe ich ähnlich wie bei Wanderweg-Relationen. Derartige Zuordnungen können nur in begrenztem Maß mit einem is_in=* oder associated_with=* ausgedrückt werden. In derartige Relationen müßte man dann aber nicht nur Flächen sondern auch Punkte und Wege einbinden dürfen.

Für die optische Darstellung in einer Karte sind diese Bezugsetzungen jedoch erst einmal unerheblich. Mit dem bisherigen System sind ineinander verschachtelte Flächen mühelos mit dem bisherigen Multipolygonsystem darstellbar und gleichzeitig kann eine große, transparente Fläche als einfaches Polygon darüber gezogen werden, das keinerlei Rücksicht auf die Linien der darunter liegenden Multipolygone nehmen muß und diese schneiden darf. Das wird in der Praxis so gebraucht, denn die Grenzen per Definition geschaffener “abstrakter” Flächen richten sich nicht zwangsläufig nach den sich aus “gegenständlichen” Flächen ergebenden Grenzen. So verläuft der Absperrzaun eines Truppenübungsplatzes beispielsweise mitten durch ein großes Waldpolygon, schneidet die Grenzlinien von Wiesen, Heideflächen usw.

So eine Fläche kann man nicht als outer definieren. Das bringt wegen der Überschneidung zwangsläufig Probleme mit sich.
Wurde das bereits bei der Entwicklung des modernen Multipolygons berücksichtigt?
Es müßte ein neues Rollentag her. Etwa in der Art wie Rolle= cover
Dieser Flächentyp müßte von den Renderern so verarbeitet werden, daß das Polygon durch das Tag “cover” automatisch nach oben gelegt wird. Und verschiedene Cover müßten sich schneiden dürfen.

Diese Art von Multipolygonen hat meines Erachtens ausschließlich abstrakten Mehrwert. Für eine korrekte Kartendarstellung kann ich keine Notwendigkeit erkennen. Die ist auch mit einfachen Polygonen möglich.

Eine Ausnahme davon würde sich ergeben, wenn in einem “Cover”-Gebiet Enklaven liegen. Beispiel: riesiger Nationalpark, darin ein Dorf mit Wiesen und Feldern, das nicht den Nationalparkregeln unterliegt. Betrifft Nationalpark Eifel und Wolfsgarten.
Um das korrekt rendern zu können, dürfte Cover nicht automatisch in die oberste Ebene gelegt werden. Vielmehr müßten alle untergeordneten Mitglieder darunter liegen und alle Nicht-Mitglieder darüber.
Das würde bedeuten daß der neue Multipolygontyp ein Pendant für Cover benötigt. So wie es inner/outer gibt, müßte es dann cover/included oder ähnliches geben.

Die Erfassung derartiger Multipolygone stelle ich mir ziemlich fehleranfällig vor. Daher erhebt sich die Frage, wie sinnvoll so ein Aufwand wäre.

Gruß
tippeltappel