[FEATURE] Processing in-place editing of features

[elpaso]

Sorry: I forgot to add the tag,

The feature is https://github.com/qgis/QGIS/pull/7876, it's well described in

https://github.com/qgis/QGIS/pull/7876

and

https://north-road.com/edit-features-in-place-using-qgis-spatial-operations-campaign/

[DelazJ]

Thansk @elpaso

[DelazJ]

@elpaso @nyalldawson what are the rules that filter the algorithms list when the button is pressed? I can see that for a polygon layer:

• multi-ring alg is kept (while it adds new features to the layer, potentially breaking any PK) and buffer alg (which performs a 1<->1 replacement) is not kept;
• array of translated features is kept while it creates new features and duplicates the existing feature;
• the boundary alg is listed though it's supposed to change the geometry type. Point layer also has "boundary" alg though not compatible in normal mode (a bug I think).

[elpaso]

Ther filtering for algs is multistep:

• default is false
• for algs that inherit from QgsProcessingFeatureBasedAlgorithm default is true
• individual algorithms can override the class default
• in-place support is also re-evaluated whenever the input layer (current canvas layer) changes, basic checks are in place for returned geometries type and for input layer geometry compatibility with the alg

We discussed about the multi -> single geometry conversion and we decided to keep some algs that perform this conversion (split), there is a fixing routine which converts single back to multi before re-injecting them into the input layer.

The PK constraints are not taken into account, the user is responsible for any further step in the processing chain that might be necessary in order to produce data compatible with the backend constraints, rollback is just a click away after all.

We (me and @nyalldawson ) went through all qgis and native algorithms one by one and checked them individually, of course there might have been mistakes during the process, if you feel this is the case, please file a ticket.

[DelazJ]

Sorry but I'm pretty sure I do not understand the steps (developer language, I guess 😄 ):

• or algs that inherit from QgsProcessingFeatureBasedAlgorithm default is true
• individual algorithms can override the class default

But, does:

in-place support is also re-evaluated whenever the input layer (current canvas layer) changes, basic checks are in place for returned geometries type and for input layer geometry compatibility with the alg

mean that opened dialogs are not bound to layers they were opened with as I thought, ie:

1. I toggle editing polygon layer A and select features; the button becomes actionable on the toolbox
2. I press the button, filtering algs and select an alg (that allows parameters)
3. Instead of running the alg right after, I switch to polygon layer B which has selected features and is also in edit mode
4. and I press "Modify selected features", it will process on layer B features and not layer A's? Shouldn't that be prone of errors?

By geometry type, I didn't mean single --> multi but polygon vs linestring vs point. From what I understood in the QEP (but I may be wrong), the limitations of the modify tool are: do not change the type of the layer nor its attribute table structure. Am I right? In which case, a modify in place should not change a polygon layer into line or point, right? But this is what the boundary alg does:

Returns the closure of the combinatorial boundary of the input geometries (ie the topological boundary of the geometry). For instance, a polygon geometry will have a boundary consisting of the linestrings for each ring in the polygon. Only valid for polygon or line layers.

[elpaso]

Sorry but I'm pretty sure I do not understand the steps (developer language, I guess smile ):

• or algs that inherit from QgsProcessingFeatureBasedAlgorithm default is true
• individual algorithms can override the class default

But, does:

in-place support is also re-evaluated whenever the input layer (current canvas layer) changes, basic checks are in place for returned geometries type and for input layer geometry compatibility with the alg

mean that opened dialogs are not bound to layers they were opened with as I thought, ie:

1. I toggle editing polygon layer A and select features; the button becomes actionable on the toolbox

2. I press the button, filtering algs and select an alg (that allows parameters)

3. Instead of running the alg right after, I switch to polygon layer B which has selected features and is also in edit mode

4. and I press "Modify selected features", it will process on layer B features and not layer A's? Shouldn't that be prone of errors?

Yes: I don't think this is allowed, is it?

with "re-evaluated", I meant that any time we need to update the list of available in-place algs the current active layer is passed to the function that tell us if that alg can run on that layer in in-place mode, I just wanted to stress out that the evaluation is per-input-layer. So, if you change active layer the list is rebuilt.

By geometry type, I didn't mean single --> multi but polygon vs linestring vs point. From what I understood in the QEP (but I may be wrong), the limitations of the modify tool are: do not change the type of the layer nor its attribute table structure. Am I right? In which case, a modify in place should not change a polygon layer into line or point, right? But this is what the boundary alg does:

I guess that's an error: it should not be enabled.

[elpaso]

@DelazJ Nyall fixed the "boundary" issue, I cheked the other one, and I agree it can be confusing, the dialog should probably be a modal one when running in-place.

[elpaso]

Ok, modal is not possible, looking for another way to tell the user what the target layer is.

[DelazJ]

Append the dialog title with layer name, as done for attribute table?

[elpaso]

yes, that's one of the possibilities, the other one is store the activeLayer when the dialog is created

[elpaso]

(of course the two are not mutually exclusive)