Bug report #11429

Raster calc in Processing: inconsistent order of layers (selecting a layer does not warrant it will be used in the analysis)

Added by Paolo Cavallini over 9 years ago. Updated over 9 years ago.

Status:Closed
Priority:High
Assignee:Victor Olaya
Category:Processing/GUI
Affected QGIS version:2.4.0 Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:fixed/implemented
Crashes QGIS or corrupts data:No Copied to github as #:19705

Description

the order of raster in the selector is not consistent: first time is the same as in the legend, afterwards is messed up; this is annoying because it makes more difficult to understand the formulas and how they change

Associated revisions

Revision b1e7ede3
Added by Alexander Bruy over 9 years ago

[processing] more robust layer sorting in multiple selection widget (fixes #11429)

History

#1 Updated by Paolo Cavallini over 9 years ago

  • Priority changed from Normal to High

I suspect it is more than annoying, as the order of layers used is not the same as the layers displayed.

#2 Updated by Giovanni Manghi over 9 years ago

  • Status changed from Open to Feedback

the order should be the same, also because there are modules where the order matter and in the selector is not possible to reorder them.

See #11088-2 and #11031-3

I had the idea Alex fixed this in Essen, after speaking with me. Now I'm not sure if the fix is not right or if I explained myself not clearly. I believe that the rationale was the following: in dropdowns show the layer in alphabetical order, in the multiple layers selector show the order of the TOC.

#3 Updated by Paolo Cavallini over 9 years ago

  • Status changed from Feedback to Open

I see your point; having two different orders side by side can be confusing IMHO.
However, the problem with this ticket seems more serious, as the variable names seem not be given in the order layers are presented, so results of calculations are essentially unpredictable.

#4 Updated by Giovanni Manghi over 9 years ago

Paolo Cavallini wrote:

I see your point; having two different orders side by side can be confusing IMHO.
However, the problem with this ticket seems more serious, as the variable names seem not be given in the order layers are presented, so results of calculations are essentially unpredictable.

the alphabetical order in dropdown is in my opinion the right way: if your project has (relatively) a lot of layers, maybe organized in groups, having the same order in a dropdown means losing a lot of time searching the input you need.

On the other hand the multiple layer selector must show the layers in the same order as the toc, because of the modules where the order count.

This could be different if the multiple layer selector would allow reordering layers and/or if dropdowns would show also group names.

#5 Updated by Paolo Cavallini over 9 years ago

  • Status changed from Open to Feedback

Anyway, the focus of this ticket is on the apparent misbehaviour of the selection, rather then on the ease of use.

#6 Updated by Giovanni Manghi over 9 years ago

Paolo Cavallini wrote:

Anyway, the focus of this ticket is on the apparent misbehaviour of the selection, rather then on the ease of use.

in your description what do you mean with "the order of raster in the selector"? the selector is not that dialog that allow you to select (by checkbox) one or more rasters as inputs for a module?

#7 Updated by Paolo Cavallini over 9 years ago

Yes: the central issue is that what you select from the dialog is not what is used in the analyses. Checked again also with GDAL modules.

#8 Updated by Paolo Cavallini over 9 years ago

  • Subject changed from Raster calc in Processing: inconsistent order of layers to Raster calc in Processing: inconsistent order of layers (selecting a layer does not warrant it will be used in the analysis)

#9 Updated by Giovanni Manghi over 9 years ago

Paolo Cavallini wrote:

Yes: the central issue is that what you select from the dialog is not what is used in the analyses. Checked again also with GDAL modules.

that's what I'm trying to explain: the order used in analysis is the order of layers in the TOC. The fix linked above is supposed to have forced the toc order in the layers selector of processing (that does not allow reordering of layers), at least on master. If it does not work please leave a comment in the commit.

#10 Updated by Paolo Cavallini over 9 years ago

The issue is: you select layer 1 and 2, and the analysis is run on layer, e.g. 3 and 4.

#11 Updated by Victor Olaya over 9 years ago

I cannot see why this is working like that, but i would suggest reverting alex's change (which probably will fix the issue) and having layers order by alphabetical order always. And in the next version, change the multiple selector and let users move layers in the selection, so they can select the order.

That makes sense to you?

#12 Updated by Giovanni Manghi over 9 years ago

Victor Olaya wrote:

I cannot see why this is working like that, but i would suggest reverting alex's change (which probably will fix the issue) and having layers order by alphabetical order always. And in the next version, change the multiple selector and let users move layers in the selection, so they can select the order.

That makes sense to you?

Hi Victor,
having the layers in alphabetical order in the layer selector means that a few modules will produce incorrect results, and sometimes this will not be immediately clear for the user.

In previous processing releases the selector worked as "expected", with the layers presented in the same order as in the TOC.

Having the layers in alphabetical order in dropdowns is something that is required by users feedback (and alternative would be show the layers as in TOC but with also the group name).

I would suggest to fix Alex commit, if this is not working as expected, but NOT to show layers in alphabetical in layer selector (unless an option to re-order the layers is added).

cheers!

#13 Updated by Victor Olaya over 9 years ago

yes, well, I meant "in the order that was used before that commit" :-) I don't remember which order was used, but I propose to revert to the situation where this was working fine.

#14 Updated by Alexander Bruy over 9 years ago

  • Status changed from Feedback to Closed

#15 Updated by Alexander Bruy over 9 years ago

  • Resolution set to fixed/implemented

Also available in: Atom PDF