Am 26. September 2011 22:13 schrieb Christian Müller <[email protected]>: > 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 _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
