Bug report #4472
Single-band Colormap color wrong on one end of color scale.
|Affected QGIS version:||master||Regression?:||No|
|Operating System:||Easy fix?:||No|
|Pull Request or Patch supplied:||No||Resolution:||end of life|
|Crashes QGIS or corrupts data:||No||Copied to github as #:||14399|
On the raster layer, the value of 10 should have no color, just like the way it is handled on the other end -- 70 values -- because the color map entered by the user ends on 20 and 70.
This wrong coloring is telling the user that purple color represent values of 20's, such as 20.1, 20.5, 20.999, etc., which is wrong because there are values of 10 too.
#2 Updated by Thaddeus - about 9 years ago
- File D_sample.png added
Well, IMHO, this behavior of the color is very confusing and misleading, enough to be called a bug instead of a new feature.
Unless the user is very familiar with the data and calculating the statistics of the band every time he/she loads/test new values/data, big mistakes can be made.
Moreover, some effects can not be realized, such as a mask -- semi-transparent overlay region, say to show tsunami safe areas -- by coloring just the values in the range of 20's (20.1, 20.5, etc, 20.999); for this, one would need to enter two discrete color entries, 20 and 30, resulting in a second unwanted color if a mask is desired (in some cases, when dealing with integer, a work around could be using 100% transparency).
Here are some screenshot:
#11 Updated by Giovanni Manghi over 1 year ago
- Status changed from Open to Closed
- Resolution set to end of life
End of life notice: QGIS 2.18 LTR