Hi Martin,
Am 28.09.2011 10:45, schrieb Martin Koppenhoefer:
wenn wir von einer Nachricht zur nächsten den Bezug vergessen bringt
die Diskussion wirklich nichts. Der Bezug war: "im Zweifel lieber
fragmentieren als zusammenfassen".(*)
lecker. Ich weiß nicht, ob die Möglichkeit, bestimmte Bezüge nicht
herstellen zu können, rechtfertigt, anderen das Vergessen vorzuwerfen.
Es macht keinen Sinn, im Kontext dieser (*)-Regel, von einem Unterschied
zwischen MP und closed ways zu sprechen, denn sie passt durchaus auf
beide dieser Arten, Flächen zu erfassen. MP bilden da /keine/ Ausnahme.
Deshalb habe ich die Frage gestellt, weshalb Du (*) überhaupt als
Argument bringst - es ist kein Argument für oder gegen eine bestimmte
Mappingpraxis, wenn alle Praxen Möglichkeiten der Fragmentierung bieten.
"closed way"-Flächen können bel. fragmentiert werden, man zerreißt dabei
i.d.R. das Original. MP-Flächen können fragmentiert werden, ohne das
Original zu zerreißen, sie fragmentieren UND fassen zusammen.
Ein Argument gegen MP-Flächen ist, dass solche MP, die sehr viele
Flächengrenzen zu einer Fläche zusammenfassen, so groß werden können,
dass ".. sie nicht mehr handhabbar sind. .. und deshalb sollte man sie
nicht nutzen.." Erstens trifft das nur für MPs zu, die größer sind als
ihr "closed way"-Pendant (die also schon zusammenfassen..) und zweitens
bedeutet die Möglichkeit, dass man zusammenfassen /kann/, nicht, dass
man zusammenfassen /muss/. Drittens /ist/ die Nicht-Verwaltbarkeit von
wirklich umfangreichen MPs hauptsächlich ein usability-Problem, dass
sich u.a. schon dadurch lösen lässt, dass umfangreiche MP in
Kind-Relationen ausgelagert werden können. Z.B. durch Gruppierung der
10.000+ outer ways in Kind-Relationen, die dann als 'outer' an einer
Eltern-Relation teilnehmen.
Die /Möglichkeit/ mit MPs komplexe Flächen mit 10.000+ Grenzsegmenten zu
bilden, bietet Lösungen für Probleme, welche mit "closed ways" überhaupt
nicht, oder mindestens genauso schwer, zu lösen sind. Weshalb sollte
man also "closed ways", welche in solchen Grenzbereichen ebenso
versagen, in ein besseres Licht rücken, als MPs, die zwar die
/Möglichkeit/ bieten, in solche Bereiche vorzudringen, aber erst dort
schwer zu handhaben 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.
In welchem Editor? Wenn es so ist, wie Du es beschreibst, ist das ein
klares Usability-Problem und kein Problem von Multipolys an sich.
nein, das Problem ist dem Datenmodell immanent, wie sollte das denn
sonst funktionieren?
Du schriebst: Beim Splitten eines ways, entsteht eine neue Version des
kompletten Multipolygons. /So/ entstünden schnell /Unmengen/ an
Versionen von riesigen Objekten.
Ich schrieb: /Dies/ ist ein usability Problem. /Das/ /Unmengen/ von
Objekten erzeugt werden, liegt doch nicht am Datenmodell - dieses zwingt
den Programmierer deines Editors mitnichten, jedes Mal eine neue Version
eines MP zu erzeugen, wenn ein way member gesplittet wird.
Wenn durch diese Operation eine neue Version entsteht, dann evtl. aufgrund
eines Konfliktes?
das verstehe ich nun nicht
Manchmal in JOSM, und das betrachte ich pers. auch als Krankheit, kannst
Du eine Relation mit dem Rel.-Dialog öffnen. Du kannst dort lustig ways
hinzufügen und entfernen. Da dieser Dialog natürlich nicht modal
arbeitet, kannst Du im MapView, während der Dialog noch geöffnet ist,
die Basisgeometrien ändern, sprich ways splitten oder löschen, die an
der Relation teilnehmen.
Da das ganze Prozedere nicht synchronisiert stattfindet, kann, wenn der
Relationen-Dialog geschlossen wird, dieser eine andere Version der
Relation vorhalten, als das im Editor geladene Dataset -> Konflikt wird
erzeugt. Üblicherweise verschwindet aber nach Lösung des Konflikts die
ungewünschte Version der Relation wieder.
Evtl. könnte der Relationen-Dialog selbst Observer des DataSets sein, um
das zu vermeiden. Aber dies und das Erzeugen von Unmengen neuer
Versionen in einem Editor sind für mich editor-spezifische Details.
... dass man aufpassen sollte, diese
nicht zu groß und komplex werden zu lassen, weil sonst
a) die Bearbeitung schwierig und langwierig wird
+/- 1 Das ist momentan evtl. richtig, je nach tatsächlicher
Komplexität. Dies trifft aber z.T. auch auf riesige "closed ways" und
dergleichen zu. Das ist, in beiden Fällen, zunächst ein
usability-Problem, welches sich mit MPs einfacher lösen lässt, als mit
"closed ways" - letztere lassen sich im Editor nicht getrennt laden
(obwohl das denkbar ist, schließlich ist ein Weg auch nur eine
Knotenliste, welche sich als Relation interpretieren lässt).
b) im Laufe der Zeit unzählige Versionen der Relation entstehen, weil
jede kleine Änderung eine neue Version entstehen lässt
Das verstehe ich nach wie vor nicht, und war ein Grund, weshalb ich auf
deine ursprüngliche mail dazu geantwortet und nachgefragt habe. Was
meinst Du damit?
c) das Rendern und andere Weiterverarbeitung unnötig aufwändig werden
Aberglaube. Es ist ein anderer Aufwand, nicht mehr oder weniger unnötig
als der, den man ohne MP betreibt. IIRC werden MPs z.B. von Renderern
ohne zu Murren gehandhabt. Zudem ist es möglich, simple Tools zu
schreiben, welche Dir Multipolygone in closed ways konvertieren -
probiere das mal anders herum. Bestimmte Arten der Weiterverarbeitung
profitieren durch MP.
Tools, die nicht MP-fähig sind, lassen sich immer noch mit konvertierten
Datensätzen füttern, in welchen MP durch closed ways aufgelöst wurden.
Dies ist anders herum nur mit _erheblichem_ Mehraufwand zu lösen, bzw.
gar nicht - da dürfen dann fuzzy-Regeln aufgestellt werden, wann zwei
Flächengrenzen gleich (sprich eine) sind - eine Entscheidung, die
sinnvollerweise nur der Mapper treffen kann und sollte.
Lieber fragmentieren als zusammenfassen war dazu die Empfehlung. Je
größer und gröber man das anfängliche Polygon macht, um so komplexer
wird tendenziell (je nach Kontext) das entstehende Multipolygon-objekt
im Laufe der Zeit.
Wie gesagt, deine Auffassung finde ich nicht verkehrt, nur die
Schlussfolgerung. Jedes noch so komplexe und große MP (sprich Fläche)
lässt sich auch fragmentieren, ohne dass man es (sie) auflöst.
Betrachte dazu nochmal die dt. Grenze (oder die dt. Fläche, wie Du willst).
* Die Fläche lässt sich mittels "closed/overlapping way" fragmentieren
(indem z.B. die Flächen der Bundesländer als closed ways erfasst werden).
* Die Flächengrenze lässt sich mittels "relations" fragmentieren (indem
z.B. die Streckenabschnitte der dt. Grenze einzelner Bundesländer in
einer Relation erfasst werden, und alle diese als 'outer' an der
Superrelation teilnehmen).
Es bleibt zu beobachten, dass dem Wunsch nach Fragmentierung in beiden
Konstellationen prinzipiell entsprochen werden kann. Mehr noch, und das
hatten wir bereits diskutiert: Die Erfassung der Gesamtfläche über die
Teilflächen (closed ways) hat klare Nachteile:
In ersterem Fall lade ich, um die Gesamtfläche D zu bearbeiten,
alle Teilflächen / Bundesländer, also auch alle Flächengrenzen, die
innerhalb D liegen. Das geschieht bei der Verwendung von MP nicht
notwendigerweise - da lässt sich die gewünschte Flächengrenze
bearbeiten, __ohne__ dass ich alles laden /muss/. Genau das war aber
dein Argument: dass ich alles laden müsste, um mit MP sinnvoll umzugehen.
Mit MPs /kann/ alles geladen werden, um sie zu editieren,
/muss aber nicht/.
Mit closed ways /muss/ alles geladen werden, um sie zu editieren.
Dass MPs komplizierter zu handhaben seien, als ein closed way (bei
gleicher Komplexität!), ist ein Mythos, eine urban legend, oder was auch
immer, der sich u.a. deshalb trägt, weil der Editorsupport schwächer
ist, als der für closed ways. Anstatt aber etwas am Editorsupport zu
verbessern, reden wir uns lieber ein, dass MPs schlecht, kompliziert,
usw. seien, obwohl sie in der Tat viele Probleme lösen, die man mit den
ausdrucksschwächeren Methoden der "closed/overlapping ways" tagtäglich hat.
In dem Moment, in welchem statt einer einzigen Fläche, mehrere
angrenzende Flächen betrachtet werden, ist klar, dass MPs tatsächlich
die bessere und einfachere Wahl sind, die Realität zu modellieren, als
geschlossene Wege. Schließlich besteht die Welt nicht aus einer
einzigen Fläche, wenn wir sie aufteilen.
Grüßle,
Christian
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de
