Am 27.09.2011 11:49, schrieb Martin Koppenhoefer:
Am 26. September 2011 22:13 schrieb Christian Müller<[email protected]>:
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).
Ich weiß jetzt nicht, ob irgendjemand von euch tatsächlich mappt - aber
JOSM geht, ich wiederhole mich, sehr effizient auch mit unvollständigen
Relationen um - es lassen sich bestimmte Teile nach belieben Nachladen,
ohne dass die Gesamtrelation geladen werden muss. Auch unvollständige
Relationen lassen sich bearbeiten, wenn man weiß, was man tut - sie
lassen sich dort auseinanderbrechen, wo es relevant erscheint, _ohne_
das gesamte Multipolygon (alle Geometrien) in den Editor geladen zu haben.
Weshalb diskutieren wir darüber eigentlich - einen closed way derselben
Länge / desselben Detailgrads müsste schließlich auch in den Editor
geladen werden, um ihn zu bearbeiten - das wiederum _immer_ komplett.
Ich sehe hier den Bezug nicht, den Du zum aktuellen Thema herstellen
möchtest. Eine weitere Frage ist, ob, wenn es solche "Monster" gibt,
nicht schon vorher etwas falsch gelaufen ist.. Schließlich müssen sie
ja erstmal da sein, bevor ich sie auseinandersplitte.
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.
Link? Ich habe mal ein enorm großes Waldstück geteilt, welches
basisgeometrisch erfasst war - ich kann nicht behaupten, dass das
einfacher war.
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.
Die Erklärung trifft auf irgend etwas zu, auf "Monster" vielleicht. Das
Problem, welches Du beschreibst, gibt es doch mit der Methode, die ich
beschrieben habe, überhaupt nicht. Das Multipolygon hat nicht mehr
nodes, als ein basisgeometrisch erfasster "closed way", was die
'outer'-Elemente betrifft und auch die 'inners' wären ohne das
Multipolygon vorhanden.
Will ich es jetzt teilen, stellt sich die Frage, wie die
'inner'-Mitglieder (die wieder Relationen sein können) auf die zwei neu
entstehenden Multipolygone aufgeteilt werden, mehr nicht.
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.
In welchem Editor? Wenn es so ist, wie Du es beschreibst, ist das ein
klares Usability-Problem und kein Problem von Multipolys an sich.
Bei mir (JOSM) entsteht da keine neue Version und ich habe das schon oft
genug gemacht. Wenn ein Weg, der zu einem Multipolygon gehört, geteilt
wird, wird der neue Weg zum /bestehenden/ Multipolygon addiert (an oder
vor der Stelle des alten Weges, der Mitglied bleibt).
Wenn durch diese Operation eine neue Version entsteht, dann evtl.
aufgrund eines Konfliktes?
Du könntest mal wieder ein bisschen Gas rausnehmen aus Deinem
Schreibstil. Diese permanente Besserwisserei nervt ein bisschen.
dito ;-)
Ich
habe nie geschrieben, dass man mit Multipolygonen mehr Nodes
produzieren würde, und darum geht es mir auch nicht.
Es wäre vielleicht besser, die (echten) Probleme mit Multipolygonen beim
Namen zu nennen. Das Konzept /Multipolygon/ ist gut, die
Editorumsetzung dürftig. Warum schließt Du dich dieser Sichtweise nicht
einfach an, wenn es in deiner Gegend ohnehin schon usus ist, sie zu
benutzen? Für mich klang es so, als wenn deine Bedenken im Hinblick auf
Multipolys modell-technischer und nicht usability-technischer Natur waren.
lg
Christian
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de
