Edition without plugin

[ponceta]

As discussed with @m-kuhn, it would be great to use QGIS native tools to add elements to QGEP.

Actually what misses is the automatic topology which is computed with the plugin.

The idea would be to have such functions on the database/client side.

Plugin would still be used for network specific tasks like profile and so on.

[ponceta]

Could be set as Project and QGIS 3 Milestone!

[haubourg]

From what I understood, @m-kuhn already had wired the necessary features in QGIS 3 to be able to get rid of the plugin for digitizing. So I think this should be possible when porting QGEP to QGIS3.
Has this been planned by QGEP's group?

The other part we really would like to have is an API dealing with the topology inside the database, so that we open a roadmap where not only QGIS can edit QGEP (my eyes on YOU qgis server ).
We have implemented that for Paris wastewater application, so this is definitly feasable. It is not a small task however.

[max-trolliet]

For connecting reaches while digitizing/add feature without the plugin, add the following expression to the default value for rp_from_fk_wastewater_networkelement:

with_variable(
   'snapped_result',
   array_first(@snapping_results),
   attribute(get_feature_by_id(map_get(@snapped_result, 'layer'), map_get(@snapped_result, 'feature_id')), 'obj_id')
) 

Based on the work sponsored by the qwat group / executed by @m-kuhn last year for QGIS 3.

[ponceta]

Nice!

[ponceta]

Great!
I tried it on QGIS 3 for reaches and it seems to be perfect:

rp_from_fk_wastewater_networkelement

with_variable(
   'snapped_result',
   array_first(@snapping_results),
   attribute(get_feature_by_id(map_get(@snapped_result, 'layer'), map_get(@snapped_result, 'feature_id')), 'obj_id')
) 

rp_to_fk_wastewater_networkelement

with_variable(
   'snapped_result',
   array_last(@snapping_results),
   attribute(get_feature_by_id(map_get(@snapped_result, 'layer'), map_get(@snapped_result, 'feature_id')), 'obj_id')
) 

[urskaufmann]

Look also my post at #443:

Better version of the expression:
add the following expression to the default value for rp_from_fk_wastewater_networkelement:

with_variable(
'snapped_result',
array_first(@snapping_results), if(map_get(@snapped_result,'valid')=true,
attribute(get_feature_by_id(map_get(@snapped_result, 'layer'), map_get(@snapped_result, 'feature_id')), 'obj_id'),'NULL'))
Change array_first to array_last for rp_to_fk_wastewater_networkelement

With this expression, there is no fk, if there is no snapping (also when the option reuse attribute values is on).
Requirement: Snapping options are set as shown in the post above.
If you digitize careful, you can set the fk automatically to the node you want (also if there are two nodes in the wastewater_structure) or to the reach.

[ponceta]

Is there a way to get snapped results only for reaches?

Because when snapping on a wastewater structure, an error will occur since it has no appearance in the wastewater_networkelement table.

[m-kuhn]

For editing without plugin, further implementations on QGIS side will need to take place.

We therefore fixed the wizard and postponed plugin-less editing. If someone wants to pick it up again, we should spend some time to define the functionality specifications.

[ponceta]

Editing with the plugin actually will collapse all QGIS default values setted for the reach layer AND does not snap to newly created values.

Editing without the plugin will require some small connectivity adjustments using the connect tool. (If it would work on newly created entities.)

In both cases this is not good enough.

I'll discuss this with @3nids next thursday. I'm open to discuss required developments QGIS side for this but actually this is not clear to me what is missing.

[urskaufmann]

AND does not snap to newly created values.

I agree for some cases: Reach to reach snapping works always. Also with new reaches.
If I create wastewater_structure (wws) first, then switch to create reach the first time after saving, then reach to wws snapping works also for new wws. If I switch again without saving, snaping reach to wws works not for the wws created with the last switch.
I have then to toggle editing (no editing), then start data entry and it starts again as described above.
I hope this helps to fix the behaviour of the wizard...

[urskaufmann]

[haubourg]

@m-kuhn can we explain exactly what the plugin does and why we try to have so much things done by the plugin?

From what I get, please complete or correct me :

• a native QGIS expression is able to fetch the snapped feature id to prefill the explicit topology fields ( from and to fields). The drawback of it is that is fetches all snapped features whatever the layer and this trigger errors

• Plugin's feature creation does not handle QGIS default values

• Plugin's feature can't snap to new features ( again a cache issue I suppose)

What about going this way:

• no plugin
• we don't prefill the from and to node using QGIS snapping expression magic
• QGIS snaps using classical snapping options
• DB does the snap using a global precision parameter set in the database (say 1 or 10 cm) in any case
• Transaction groups forward the commits to the database and as soon as we reopen the forms, from and to topology is filled.

This allow to work with other GIS clients, at the cost of not having some fields filled only we creating new features. To me and following what we have in Paris wastewater, this is not an issue.
I think this is also much more robust. However, this does not solve the real issue about #492 snapping issues.

[m-kuhn]

One of the bigger issues still remaining is that it's not possible to define the snapping priority, i.e. to prioritize wastewater nodes over reaches if both are in snapping range.

From QGEP side we decided to stick to the plugin since it gives us what we need with the least possible effort. If there is someone (qwat?) willing to invest into QGIS improvements required to drop the digitizing parts of the plugin, OPENGIS will be more than happy to investigate the complete requirements and work on it. Let us know!

#492 is an unrelated different issue

[haubourg]

@m-kuhn

One of the bigger issues still remaining is that it's not possible to define the snapping priority, i.e. to prioritize wastewater nodes over reaches if both are in snapping range.

Ok good to know.

If there is someone (qwat?) willing to invest into QGIS improvements required to drop the digitizing parts of the plugin,

I let this to @ponceta :)

[ponceta]

We found a workaround for this with @3nids yesterday : #508

The idea is to get the z of the snapped element except if it's a wastewater structure or a cover (in that case we get the z of the wastewater node through the wastewater foreign key)

This workaround is pretty likely what @m-kuhn and @urskaufmann made for connectivity issues using native edition.

Like we discussed, it won't be easy to go for snapping priority enhancement toward the community since this is pretty clear today : Snapping priority is on the layer on the top of the layer tree where snapping is enabled (and it's quite natural).

Snapping result on insertion is unique for each click the user makes. (this will be an array if the user draws a polyline or a polygon or a multipoint entity)

Snapping preferences could maybe change before the click on a hotkey (example with snapping preferences stored or default snapping preferences) but that's maybe not a good idea.

[m-kuhn]

Snapping priority is on the layer on the top of the layer tree where snapping is enabled

Has this been verified? In my experience it was quite unpredictable, which one is first is pure chance.

Snapping preferences could maybe change before the click on a hotkey (example with snapping preferences stored or default snapping preferences) but that's maybe not a good idea.

That would certainly be nice, but I think this can't fully replace the priority.

[ponceta]

Works pretty great since 2019 in Pully. Open new issue if any new bugs are found.