[Qgis-developer] Topology editing in QGis

[Radim Blazek]

On Thu, Nov 7, 2013 at 6:33 PM, Sandro Santilli <strk at keybit.net> wrote:
>> > 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 was able to create topology in PostGIS, open it with TopoViewer and
digitize 2 nodes. But I gave up on edges because it asks me to fill in
values which are not known during digitizing ( e.g. next_left_edge
...). Anyway, the necessity to enter all topology info
(start_node,end_node, next_left_edge, next_right_edge...) makes it
unusable even for tests.

Do you have any demo data?

Why there are separate layers for next_right, next_left, face_right
etc? To display labels?

And what is this http://plugins.qgis.org/plugins/pgtopoeditor/ ?

>> Note, in GRASS, compounds (areas) are generated automatically, not
>> manually selected.
>
> Areas (faces) are generated automatically in PostGIS too, but those
> are not considered "compounds". Rather they are considered "primitive"
> (elements) at the same level of nodes and edges.

Then we have to extend/modify terminology. Definitely an area is not a
primitive, it must be distinguished from edges/nodes. Is it the ISO
standard calling areas primitives? What is the upper level above
areas, features?

> It is true that faces are defined by edges, but they are not intended
> to be attached user attributes. The rationale is that you must be able
> to cut any face by adding more edges w/out the user-feature changing
> its shape (the same as you can cut any edge by adding more nodes w/out
> the linear user-feature changing its shape).

OK, not really important for primitives editing, I think.

> I understand that in GRASS you attach attributes to faces (areas) instead.

Attributes are attached to centorids.

> Maybe GRASS could just not support this level of editing.

Yes, GRASS does not need that, centroids are auto attached to areas.

>> 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)
>
> Are those "topology states" ? I'm not sure I understand them.
>
> Can "point" and "node*" be states of a "node" layer ?
> Can "line" and "boundary" be states of an "edge" layer ?
> Can "centroid*" be states of a "face"/"area" layer ?

point/centroid/node could be states of punctual layer
line/boundary may be states of linear layer

>> 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?
>
> What I mean is that signalling of changes to related layers should
> not necessarely be provided by the generic API, but could be handled
> internally by each provider. As a provider of a topological layer
> you (the provider) must know how to dispatch information about changes
> happening. Supposedly all "related" layers will be provided by you
> (the provider) so you should have all it takes to take note about
> how many layers you created that are related to a given topology,
> and dispatch accordingly.

Layers are not provided by providers, providers know nothing about
existence of layers. But that is not that important, it can be done
somehow.

Until now, I was following your idea of multiple primitive layers
added on editing start. However it seems the easiest way to implement
it, I am not convinced that it is the right generic framework from
user point of view. Especially the manual switching between layers
during editing makes it inefficient for regular work. In general,
plenty of primitive layers is ugly.Could be the primitive layers
limited to maximum one per each geometry type?

BTW: http://hub.qgis.org/issues/3483

Radim