Was ist da faul mit dem Waldpolygon?

[de_muur]

@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