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