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

[Martin Koppenhoefer]

Am 28. September 2011 16:19 schrieb Christian Müller <cmue81 at gmx.de>:
>>>> 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?
> 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.


nochmal: wie sollte das denn sonst gehen? Liegt sehr wohl am
Datenmodell. (klar, die Version entsteht erst beim Hochladen, nicht
bereits beim Splitten im Editor).


> 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.


ach so, das meinst Du. Das ist in der Tat eher ein Editor-Problem
(evtl. könnte der Editor Änderungen in der Karte in den Fenstern der
geöffneten Relationen jeweils live nachführen). Konflikte durch
parallele Edits (verschiedener Mapper) entstehen allerdings auch
(weiterer Punkt) um so eher, je ausgedehnter ein Objekt ist.


>> 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.


ich meine nicht beim Importieren des MP in den Editor. Wenn ein Wald
sich über 2500 km² hinzieht, mit allen kleinen Lichtungen und anderen
inner ways, dann musst Du beim Rendern das komplette Monster in jedem
einzelnen zoom18-Tile betrachten (glaube ich zumindest), obwohl nur
ein winziger Teil in Deinem Kartenausschnitt liegt. Wenn man den Wald
an jeder größeren Straße auftrennt, wird er kleiner (weniger Versionen
bzw. kleinere Versionen, schneller zu rendern, weniger potentielle
Konflikte).


Es ist natürlich richtig, dass man sowohl mit Einzelflächen als auch
mit Multipolygonen eher groß oder eher fragmentiert arbeiten kann,
aber wenn man von vornherein riesige Flächen erzeugt ist es sehr
wahrscheinlich, dass der nächste Mapper da einfach per Multipolygon
was rausschneidet. Je mehr das machen, um so eher wird das ein
Monster. Wenn man dagegen fragmentiert beginnt, dann ist die Chance
größer, dass der nächste Mapper so weitermacht und irgendwann aus
diesem Flickenteppich ein Bild wird (übrigens ein detailliertes, weil
von vornherein kaum Vergröberung drin ist).

Mit Deinem Plädoyer für Multipolygone bei Grenzen rennst Du offene Türen ein.

Gruß Martin