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

[qgib]

Author Name: Paolo Cavallini (@pcav)
Original Redmine Issue: 11429
Affected QGIS version: 2.4.0
Redmine category:processing/gui
Assignee: Victor Olaya

---

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

[qgib]

Author Name: Paolo Cavallini (@pcav)

---

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

---

• priority_id was changed from Normal to High

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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 #19421-2 and #19370 (comment)

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.

---

• status_id was changed from Open to Feedback

[qgib]

Author Name: Paolo Cavallini (@pcav)

---

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.

---

• status_id was changed from Feedback to Open

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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.

[qgib]

Author Name: Paolo Cavallini (@pcav)

---

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

---

• status_id was changed from Open to Feedback

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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?

[qgib]

Author Name: Paolo Cavallini (@pcav)

---

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.

[qgib]

Author Name: Paolo Cavallini (@pcav)

---

• subject was 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)

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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.

[qgib]

Author Name: Paolo Cavallini (@pcav)

---

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

[qgib]

Author Name: Victor Olaya (@volaya)

---

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?

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

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!

[qgib]

Author Name: Victor Olaya (@volaya)

---

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.

[qgib]

Author Name: Alexander Bruy (@alexbruy)

---

Fixed in changeset "b1e7ede36baba2694ae9e9b065e45dc82d945eb0".

---

• status_id was changed from Feedback to Closed

[qgib]

Author Name: Alexander Bruy (@alexbruy)

---

• resolution was changed from to fixed/implemented