[Qgis-developer] Topology editing in QGis

[Radim Blazek]

On Wed, Nov 6, 2013 at 10:42 PM, Sandro Santilli <strk at keybit.net> wrote:
> 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.

I'll do once I find time. Please look on GRASS editing.

>> 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.

Note, in GRASS, compounds (areas) are generated automatically, not
manually selected.

> 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.

This can be a higher level editing, but elements editing is necessary.

>> 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 ?

It depends on model, for GRASS:
- point
- line
- boundary (no area)
- boundary (1 area)
- boundary (2 areas)
- centroid (in area)
- centroid (outside area)
- centroid (duplicate in area)
- node (1 line/point)
-node (2 and more lines/points)

>> > 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 ?

How do you say to compound layer that element changed? Also in GRASS,
all elements are stored in single file, so element layer providers
have to work with the same datasource.

> In that case each provider should take care of the required book-keeping
> to maintain the link between layers related to the same topology.

Can you explain better what you mean?

Radim

> --strk;
>
>  ()  ASCII ribbon campaign        - against html e-mail
>  /\  http://www.asciiribbon.org   - against proprietary attachments