[GRASS-dev] [GRASS GIS] #3265: min and max value options for r.colors

#3265: min and max value options for r.colors
-------------------------+-------------------------
Reporter: veroandreo | Owner: grass-dev@…
     Type: enhancement | Status: new
Priority: normal | Milestone: 7.2.1
Component: Raster | Version: unspecified
Keywords: r.colors | CPU: Unspecified
Platform: Unspecified |
-------------------------+-------------------------
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.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3265&gt;
GRASS GIS <https://grass.osgeo.org>

#3265: min and max value options for r.colors
--------------------------+-------------------------
  Reporter: veroandreo | Owner: grass-dev@…
      Type: enhancement | Status: new
  Priority: normal | Milestone: 7.2.1
Component: Raster | Version: unspecified
Resolution: | Keywords: r.colors
       CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------

Comment (by annakrat):

I am not sure I understand, why don't you use color table with absolute
values in this case?

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3265#comment:1&gt;
GRASS GIS <https://grass.osgeo.org>

#3265: min and max value options for r.colors
--------------------------+-------------------------
  Reporter: veroandreo | Owner: grass-dev@…
      Type: enhancement | Status: new
  Priority: normal | Milestone: 7.2.1
Component: Raster | Version: unspecified
Resolution: | Keywords: r.colors
       CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------

Comment (by veroandreo):

Replying to [comment:1 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à :slight_smile:

Hope I explained myself better in this occasion. Thanks for your time :slight_smile:

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3265#comment:2&gt;
GRASS GIS <https://grass.osgeo.org>

#3265: min and max value options for r.colors
--------------------------+-------------------------
  Reporter: veroandreo | Owner: grass-dev@…
      Type: enhancement | Status: new
  Priority: normal | Milestone: 7.2.1
Component: Raster | Version: unspecified
Resolution: | Keywords: r.colors
       CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------

Comment (by mlennert):

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
}}}

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3265#comment:3&gt;
GRASS GIS <https://grass.osgeo.org>

#3265: min and max value options for r.colors
--------------------------+-------------------------
  Reporter: veroandreo | Owner: grass-dev@…
      Type: enhancement | Status: new
  Priority: normal | Milestone: 7.2.1
Component: Raster | Version: unspecified
Resolution: | Keywords: r.colors
       CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------

Comment (by veroandreo):

Thanks Moritz for the comment :slight_smile:

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.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3265#comment:4&gt;
GRASS GIS <https://grass.osgeo.org>