On Tue, Nov 5, 2013 at 5:21 PM, Ouyang Leyan <[email protected]> wrote: >> > Topology models are usually using multiple geometry types (e.g. nodes, >> > edges). Multi geometry type layers may also be useful for non > >> > topological layers. How difficult would it be to support multiple >> > geometry types in a single layer? >> The path I took for postgis topology was instead to keep layers >> separated. They are still correlated one-other (changes in one layer >> may result in changes propagating to other layers), but they are >> still seen as separate layers in the layer management, so that you >> can set their visibility independently and/or style them differently. >> >> I think it may be useful to have support for mixed geometry types >> within a single layer but don't feel any urgent need for them to >> edit topologies. >> >> How do you like the separated layers approach ? Do you think it could >> work for GRASS topologies ? I guess one limitation of it is that when >> you enter "edit mode" you do so in a single layer, thus implicitly >> (rather than explicitly) also editing correlated but >> not-marked-as-being-edited layers. But this would already be the case >> by opening the same datasource twice...
Basically you are suggesting the same as Sandro, right? 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. > 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 Element layers would be added automatically when user starts editing of compound layer or user has to explicitly add element layers group before editing? > * Each vector layer would appear independently in the layer tree, but be a > part of the topology group > > * It would be impossible to turn editing on a single layer, editing state > would be controlled at the topology group level, so if one layer is edited, > all layers are. This would be explicitly shown. > > This allows to not touch anything for the visualization part, all the > symbology can be applied on a single vector layer as usual. 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? > 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? Radim > I never used GRASS topology, I still have to learn about it, but I think > this representation would be flexible enough to adapt to different > situations. It would also be possible to build "ad-hoc" topologies with > simple normal vector layers (shapefiles, etc.) and have editing operations > follow basic topology rules including several layers, which is something I > would like to see (I work with networks and casual users who can open > shapefiles, but not install PostGreSQL). This kind of topology would be like > an extension of the existing pseudo-topology editing, just extended to > several layers. > > Pierre _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
