[Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel

Martin Koppenhoefer dieterdreist at gmail.com
Di Sep 27 09:49:08 UTC 2011


Am 26. September 2011 22:13 schrieb Christian Müller <cmue81 at gmx.de>:
> Am 23.09.2011 13:01, schrieb Martin Koppenhoefer:
>> Nicht, dass ich Multipolygon-relationen nicht auch sinnvoll finde und sie
>> so oft es Sinn macht auch anlege und nutze, aber je größer man die anfangs
>> grob gezeichneten Gebiete (z.B. Wälder) anlegt, um so größer ist die Chance,
>> dass 100 Versionen später daraus unübersichtliche Monster geworden sind, die
>> Otto-Normal-Mapper überhaupt nicht mehr anfasst (die brauchen schon einige
>> Minuten bis sie überhaupt in den Editor geladen sind, und dieser wird dann
>> u.U. so langsam, dass man nicht mehr vernünftig arbeiten kann).
>
> Von welchem Editor sprichst Du denn?  JOSM geht mit so etwas effizienter um,
> als mit closed- bzw. overlapping ways.


Damit Du ein Multipolygon sinnvoll aufteilen kannst, musst Du es
zuallererst mal in den Editor laden. Alleine das dauert schon ewig bei
sehr großen Mulitpolygonen. Ab einer gewissen Größe (wie Frederik
treffend beschrieben hat) geht es praktisch gar nicht mehr (weil der
Editor zu langsam wird).


> Und:  Du trägst nicht gerade zur Verbreitung von Multipolys bei, indem Du
> "Monster" und "Mythen" kreirst, damit sie in dem unrecht schwachen Licht
> stehen bleiben, welches sie derzeit karg beleuchtet..


Von "Mythen" war bei mir keine Rede, schau einfach mal nach Japan in
die Wälder und versuche, einen der Riesenwälder in kleinere Stücke zu
teilen.


>> Auch bei der Datenverarbeitung sind diese Monster extrem ungünstig (s.
>> Japan), weil man z.B. für die kleinste Render-Kachel immer gleich einen
>> riesigen Bereich (zig-tausende von Nodes) betrachten muss. Wenn man dagegen
>> von vornherein nach der Maxime im Zweifel lieber fragmentieren als
>> zusammenfassen arbeitet, ist das für die kommende Entwicklung gesünder.
>
> Ja, klar..  Weil "lieber fragmentieren als zusammenfassen" != "zig-tausende
> Nodes".  Klingt nicht gerade überzeugend.


Ich erkläre es nochmal langsam: Milliarden Nodes haben wir sowieso in
der Datenbank. Ein Problem wird es dann, wenn sehr viele Nodes alle zu
einem Objekt gehören (weil um dieses zu bearbeiten, zumindest für
manche Bearbeitungen wie Teilungen, alle geladen werden sollten).
Solange die Nodes alle in verschiedenen kleineren Objekten liegen ist
das kein Problem: man bearbeitet einfach lokal das kleine Stück, das
gerade im Editor liegt, und braucht sich um den Rest, der entfernt in
einem anderen Objekt liegt, nicht scheren.


> Ein Gebiet, welches sauber mittels multipolys gemappt ist, ist
> datenverarbeitungstechnisch einfacher zu handhaben und vor allem auf
> wesentlich vielfältigere Art und Weise, als das jetzt der Fall ist.


"Als das jetzt der Fall ist"? In meiner Umgebung gibt es sehr viele
Multipolygone, wo bist Du denn, dass das alles überlappende Ways sind?
Sobald man an einem riesigen Multipolygon mit hunderten von Membern
irgendwo einen way teilt entsteht gleich eine neue Version des
kompletten Multipolygons. So entstehen sehr schnell Unmengen an
Versionen von riesigen Objekten.


>  Außerdem, ungleich deiner auf Unkenntnis beruhenden Behauptung, dürften
> multipolygon-gemappte Gebiete klar Nodes einsparen, anstatt, wie von Dir
> behauptet "zig-tausende" zu produzieren.


Du könntest mal wieder ein bisschen Gas rausnehmen aus Deinem
Schreibstil. Diese permanente Besserwisserei nervt ein bisschen. Ich
habe nie geschrieben, dass man mit Multipolygonen mehr Nodes
produzieren würde, und darum geht es mir auch nicht.

Gruß Martin




Mehr Informationen über die Mailingliste Talk-de