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

[Christian Müller]

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