[GRASS5] Re: rules in r.colors

[Glynn Clements]

Michael Barton wrote:

> I understand this and how it is supposed to work the way you have it 
> set up. Sorry if I was confusing in this regard. My suggestion was to 
> build on your work in a somewhat different direction. With the new 
> rules code you did, it is possible to read in text files of color 
> rules. I was suggesting to use this same code to access user-defined 
> files rather than a limited set of color table files located in the 
> $GISBASE/etc/colors folder. It is indeed a different objective than 
> yours was.

Right. So it should be a separate option, e.g. "file=".

Although, it's arguable that you should also be able to store colour
tables in the mapset (in a similar manner to icons).

> Perhaps it is problematic to do this. Having a set of predefined GRASS 
> color tables is certainly handy (realizing that grey.eq, grey.log, and 
> random are somewhat different beasts from the other color tables). For 
> different reasons, it also seems a useful thing to build into r.colors 
> the functionality of  'r.colors input=[map] <colortable.txt' so that a 
> user could more easily access (and even share) custom color tables. The 
> latter should not get mixed up with the standard predefined set.
> 
> I can't quite envision your suggestion for replacing the stdin option, 
> but it seems interesting.

The issue with using color=rules without redirection is that, under
tcltkgrass, it requires an xterm, while none of the other cases do.
The same issue applies whatever mechanism is used to select this
behaviour (e.g. color=rules, a dedicated flag, or whatever).

Until recently, tcltkgrass didn't handle this case at all; the module
file indicated that r.colors didn't need an xterm, so color=rules just
wouldn't work. So, someone (you?) added separate menu entry for that
case. However, AFIAK, this won't work with the auto-generated GUI in
5.7 (maybe there should be a "needs an xterm" checkbox added to each
dialog?)

> While it is very handy to be able to create a 
> color table on the fly as you can now, it would be even nicer to have 
> the option to save this to a file (as I think you are suggesting?) to 
> use again for various maps if you liked it (and not have to dig it out 
> of the $GISBASE/$LOCATION/$MAPSET/colr directory (the rast=[map] option 
> is a more efficient way of achieving the latter).

OK. That's something completely different altogether. However, that
would require additional code (my changes to r.colors were
essentially just leveraging the code which already existed for the
color=rules option). Currently, there isn't any code to "export" a
colour table in the format which r.colors accepts (the colr/colr2
files use a different format).

The "rast=" option has some limitations. In particular, the map has to
exist in the current location; you can't use a map from a different
location or database.

-- 
Glynn Clements <glynn.clements at virgin.net>