Pseudocolor renderer - discrete color ramp interpolation ignores specified Min/Max

[qgib]

Author Name: Alister Hood (@AlisterH) Original Redmine Issue: 21541 Affected QGIS version: 3.6.0 Redmine category:symbology

---

Using the singleband pseudocolor raster renderer, classification using equal interval mode respects user specified Min and Max values when using "Linear" or "Exact" interpolation, but ignores them when using "Discrete" interpolation.

Changing the interpolation setting doesn't trigger a reclassification, which leads to a bizarre inconsistency:

• style a raster using "Linear" interpolation, manually specifying Min/Max values.
• switch to "Discrete" interpolation, and the classes are unchanged.
• click on the Classes up arrow and then the down arrow, and the classes will be different because they ignore your specified Min & Max vales.
• switch back to "Linear"; the classes will be unchanged, i.e. still ignoring the specified Min & Max.

Of course, this does mean that a workaround is to classify with "Linear" or "Exact" interpolation and then switch to "Discrete" once you have the right classes.

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

• category_id was changed from Rasters to Symbology

[alexbruy]

Seems already fixed in master. Please re-test.

[AlisterH]

Not fixed in 3.12.2

[AlisterH]

Sorry, I think I have misinterpreted the current behaviour; probably it can be considered fixed.

This part is definitely fixed:

Changing the interpolation setting doesn't trigger a reclassification, which leads to a bizarre inconsistency:

style a raster using "Linear" interpolation, manually specifying Min/Max values. switch to "Discrete" interpolation, and the classes are unchanged. click on the Classes up arrow and then the down arrow, and the classes will be different because they ignore your specified Min & Max vales. switch back to "Linear"; the classes will be unchanged, i.e. still ignoring the specified Min & Max.

And re the main issue:

Using the singleband pseudocolor raster renderer, classification using equal interval mode respects user specified Min and Max values when using "Linear" or "Exact" interpolation, but ignores them when using "Discrete" interpolation.

I'm not 100% sure what the behaviour was when I originally filed the ticket, but I'm guessing the user inputs were completely ignored. If so, this is fixed - change the minimum and maximum and it is reclassified, with the divisions calculated correctly based on the inputs. I just get confused, because the discrete interpolation does not work they way I expect it to. Compare these two screenshots: With linear or exact interpolation, the minimum and maximum values you input actually end up as the top and bottom values in the list. With discrete interpolation they do not, which seems inconsistent and counterintuitive to me. To get something close to what I expect I need to fiddle with the numbers: [edit - wrong screenshot - see below] I have a feeling I might have had another ticket about this.

FWIW this difference in behaviour is actually the same (although the numbers are different) using Continuous mode instead of equal interval.

[AlisterH]

I have a feeling I might have had another ticket about this.

Can't find one, the closest was an issue with labels for discrete interpolation.

[alexbruy]

Discrete mode assigns the color of the higher class for every pixel between two class breaks (from docs) so to me current behaviour looks correct. But maybe I'm wrong.

[AlisterH]

Sorry, it seems I took two sets of screenshots and then mixed them up, so it wasn't clear what I meant to say.
The third screenshot should have been something like this: i.e. when entering 38 and 43 as the minimum and maximum I would have expected something like this:

[AlisterH]

Or, more likely, that "clip out of range values" would be enabled, and this would be the result:

[AlisterH]

That first one probably doesn't make sense because it means if you use the actual minimum and maximum values you would get two unused classes, so you'd actually want to increase your number of classes by two.

But enabling "clip out of range values" could be good - I know I have worked around it by adding a couple of classes and making the top and bottom class transparent.

[Pedro-Murteira]

This is still an issue on QGIS 3.22.3.