[Qgis-developer] Topology editing in QGis

[Sandro Santilli]

On Wed, Nov 06, 2013 at 10:50:32AM +0100, Radim Blazek wrote:
> On Tue, Nov 5, 2013 at 5:21 PM, Ouyang Leyan
> <ouyang.leyan.ml at hotmail.com> 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