Opened 8 years ago
Last modified 6 years ago
#3265 new enhancement
min and max value options for r.colors
Reported by: | veroandreo | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | 7.6.2 |
Component: | Raster | Version: | unspecified |
Keywords: | r.colors | Cc: | |
CPU: | Unspecified | Platform: | Unspecified |
Description
In the present state, in order to make color scales equivalent among maps, as there are not min and max value options in r.colors, one should feed r.colors with the list of maps, so it takes min and max from there.
This leads to repetition because one cannot set r.colors iteratively for each map immediately after they are created, but it has to be done once all of them are created, and then iterate again to create displays (png outputs), for example.
With min and max value options (for those cases in which one knows before hand the range of valid values in maps) this could be attained in a single loop immediately after creating each map, with no need to loop all over again.
Change History (11)
follow-up: 2 comment:1 by , 8 years ago
comment:2 by , 8 years ago
Replying to annakrat:
I am not sure I understand, why don't you use color table with absolute values in this case?
Well, that would limit the options in the first place. Besides, the range and type of color tables is a pretty hidden information, i.e.: it is not in the manual (see ticket #3077 for a related issue, I found it while searching if there was already a request similar to mine, just to not duplicate).
IMHO, having min-max value option(s) would be a straightforward way to set min and max value for relative color tables and make all the maps comparable, without necessarily having to pass a list of maps. Just set min and max values of color table after creating each map, as in a loop, for example.
Here, one example:
LST=(Day Night) for j in ${LST[*]} ; do for i in `seq -w 1 12` ; do # monthly climatological counts of valid data t.rast.series input=LST_${j}_daily method=count where="strftime('%m', start_time)='${i}'" output=LST_${j}_month_count_${i} # number of maps per month n=`t.rast.list -u input=LST_${j}_daily columns=name where="strftime('%m', start_time)='"${i}"'" | wc -l` # counts to percentages r.mapcalc expression="LST_${j}_month_perc_${i} = LST_${j}_month_count_${i}*100.0)/${n}" # plots d.mon start=cairo output=$HOME/tmp/LST_${j}_month_perc_${i}.png d.rast map=LST_${j}_month_perc_${i} d.mon stop=cairo done
As it is, this gives me maps with different percentage ranges in the default color table. To make them comparable, I have to pass the list of maps to r.colors once the loop has finished (of course this case is not that complicated, or long), and then write a similar loop to make the plots. However, with a min-max value option that would be set with r.colors inside the loop before plotting and voilà :)
Hope I explained myself better in this occasion. Thanks for your time :)
comment:3 by , 8 years ago
Why not "just" use a custom color table that you define yourself. IIUC, you would define the min and max values a priori anyhow, so something like this (for a grey color table):
0 10:10:10 100 230:230:230
Or if you want the new default viridis table, you can just delete all the '%' in the color table as you work with percentage values anyhow. I.e.
0.000% 68:1:84 0.392% 68:2:86 0.784% 69:4:87 1.176% 69:5:89 [...]
becomes
0.000 68:1:84 0.392 68:2:86 0.784 69:4:87 1.176 69:5:89 [...]
Just put this in a file and add
r.colors map=LST_${j}_month_perc_${i} rules=YourColorFile
comment:4 by , 8 years ago
Thanks Moritz for the comment :)
Yes, I am aware that I can create my own color table or edit an existing one and that solves the issue. However, IMHO, that is not as straightforward and quick as min-max parameter(s) would be, with the possibility to easily set the extreme values to the color tables already available (in the command directly, no need to edit or create another file nor search for the corresponding RGB for a color) :-/
If the request is a wontfix or if it is invalid, please, feel free to close this ticket.
comment:5 by , 8 years ago
Milestone: | 7.2.1 → 7.2.2 |
---|
comment:6 by , 7 years ago
Milestone: | 7.2.2 → 7.4.0 |
---|
All enhancement tickets should be assigned to 7.4 milestone.
comment:8 by , 6 years ago
Milestone: | 7.4.1 → 7.4.2 |
---|
comment:9 by , 6 years ago
Milestone: | 7.4.2 → 7.6.0 |
---|
All enhancement tickets should be assigned to 7.6 milestone.
I am not sure I understand, why don't you use color table with absolute values in this case?