[Qgis-developer] Topology editing in QGis

[Radim Blazek]

On Tue, Nov 5, 2013 at 5:21 PM, Ouyang Leyan
<ouyang.leyan.ml at hotmail.com> 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