On Wed, Nov 06, 2013 at 10:50:32AM +0100, Radim Blazek wrote: > On Tue, Nov 5, 2013 at 5:21 PM, Ouyang Leyan > <[email protected]> wrote:
> Terminology suggestion: > * element layer - layer representing topological elements, e.g. nodes or > edges > * compound layer - higher level layer of compounds from elements, > e.g. polygons formed by edges > Users usually work with compound layers, element layers are only used > for editing or debugging. Terminology accepted, adding aliases: * element layer AKA primitives layer * compound layer AKA features layer > > For the topology editing, I was thinking of considering the topology as a > > special group (or the vector layers as sublayers of a topology layer): > > * When adding a topology, all the vector layers (node, edge, face, etc.) > > would be added at once Note that this is the model used by the "TopoViewer" included with the DBManager plugin. It creates a group and adds different vector layers for the primitives. I suggest you both take a look at it if not done yet, just to have a common reference. > Element layers would be added automatically when user starts editing > of compound layer or user has to explicitly add element layers group > before editing? I guess this depends on the kind of editing we want to allow. One level of editing is, imho, simply selecting which elements/primitives takes part in the definition of the compound. This is an high-precision editing level where it is ensured that no changes will occur in the elements. For this kind of editing I envision a system that would automatically add on the map one or more layers containing candidate elements (one layer per element-type) to let user pick the one he wants. Another level is modifying the elements that compose a compound. I still don't know what would work for this second level, when coming from "editing of a compound layer", but it does sound like a short-cut to open editing of the element layer. Yet another possibility is allowing arbitrary modification of the shape of a compound and automatically add elements in the topology to account for those changes. This is what I've implemented in QGIS for editing of TopoGeometry (aka "compound") layers. > Element layers will be displayed with topological meaning symbology > above compound layers? I.e. for example polygons symbolized according > to attributes + edges symbolized according to topology state? We should have good defaults, but still possibly also allow users to set "template styles" for their element layers. I think it makese sense to allow for symbolization of states, generally. The states could be seen as dynamic attributes of the element tables. We could eventually require a minimum set of attributes for these kind of tables to unify symbology for them. Could you write down a list of the states, to add to the terminology ? > > Only the editing features would have to be modified to deal with the > > topological > > modifications of the other layers and keep everything consistent. Of course, > > the definition of consistent will depend on the kind of topology considered. > > How would be implemented the consistency? Currently each layer > instantiates single provider and providers do not know anything about > each other. The changes have to be propagated to other layers via > provider because of different topology models. It means, that > topological providers have to keep opened data sources in static > members, and editing has to be done on those static members. After > each edit operation all providers/layers using the same data source > has to be informed about the change. How? Signals on provider level, > between providers sharing the same data source? I don't think we want to provide cross-provider topologies, do we ? In that case each provider should take care of the required book-keeping to maintain the link between layers related to the same topology. --strk; () ASCII ribbon campaign - against html e-mail /\ http://www.asciiribbon.org - against proprietary attachments _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
