Bug report #14950
raster rendering values saved with too limited precision in project file
|Affected QGIS version:||master||Regression?:||No|
|Operating System:||arch linux 64bit||Easy fix?:||No|
|Pull Request or Patch supplied:||No||Resolution:|
|Crashes QGIS or corrupts data:||No||Copied to github as #:||22899|
Qgis saves the raster rendering values (e.g. for different rendering colors in the pseudocolor rendering, but I suppose also the other values, like min/max, etc.) in scientific notation with a very limited precision in the project file. Closing and reopening the project then results in different values from those entered.
It is important to me because I frequently use int32 rasters for date values, where the date is coded as yyyyddd, which fits nicely in the int32 space, and matches the landsat scene date coding.
For example, when I want all pixels 2016001 -> 2016143 rendered with a colorscale, and only pixels with the exact 2016144 value with a certain color, after saving and reopening, both the 2016143 and the 2016144 values are rounded to 2016140, which means I won't see the 2016144 pixels in a different color (or even won't see them at all).
When looking in the project file, these values are saved as "<item alpha="255" value="2.01614e+06" label="2016/05/16" color="#fd6823"/>". Note the "2.01614e+06", which is effectively rounding both 2016143 and 2016144 to 2016140.
Attached are two screenshots of part of the raster pseudocolor dialog rendering, one with the values as entered ('before'), and the other one with the values that show up when re-opening the project ('after').
Using qgis master compiled from git, about a week ago.