Was ist da faul mit dem Waldpolygon?

rab · 2010-12-28T20:20:26.000Z

Lösch mal das innere Multipolygon (meadow als outer)
Gruß
rab

edit: Du hast in deinen Multipolygonen noch zusätzlich einen Landuse gesetzt

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