[GRASS5] r.colors again

GRASS GRASS developer
1

Hamish,

I was messing around with r.colors for 5.7. As it is currently (or at least as of 4/24 - my current installation) it is pretty close to what I was suggesting. For what it is worth, the changes I'd recommend are:

1. change the rules=[file] so that it just looks for a color table file in any user-defined location, not $GISBASE/etc/colors. It should have a gisprompt: 'file,file,file' in the tcltk header for g.parser to read. This makes it a built-in version of the redirect command that Helena mentioned. I'd change the description from 'predefined rules file' to 'user-defined color table' or simply 'color table file'. There would be no need to find a way to read and parse a list for users to see. They could simple browse to a location where they wanted to store extra color tables and see what is there.

2. split out the color=rules from color=[type], and make it a flag. Currently, color=rules works from the command line but not from the autogenerated GUI. Unlike the other color=[type] options, it needs to exec an xterm. Making it a flag rather than a possible color type might make this easier to solve. The color=[type] option could then be described as 'predefined GRASS color tables' and the flag as 'create color table interactively'

Does this sound more easily doable?

Michael
____________________
C. Michael Barton, Professor
School of Human Origins, Cultures, & Societies
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

2

Michael Barton wrote:

I was messing around with r.colors for 5.7. As it is currently (or at
least as of 4/24 - my current installation) it is pretty close to what
I was suggesting. For what it is worth, the changes I'd recommend are:

1. change the rules=[file] so that it just looks for a color table file
in any user-defined location, not $GISBASE/etc/colors. It should have a
gisprompt: 'file,file,file' in the tcltk header for g.parser to read.

No. As I've said at least twice before, that is *not* the purpose of
the "rules=" option. The "rules=" option is intended solely as a
transitional measure.

The fact that the arguments to rules= happen to be files is an
implementation detail, which shouldn't be visible to the user.

The idea was that it would ultimately be merged with the "colors="
option. Instead of the argument to colors= referring to one of a
hardcoded list of coded colour tables, it would refer to an extensible
list of *predefined* rule files.

I had considered simply changing to the behaviour of the color=
option, but I decided against it because I didn't want to risk
breaking anything.

For the time being, you have a choice of two methods for using one of
(most of) the standard colour tables: color= or rules=. I.e. using
"r.colors ... color=rainbow" and "r.colors ... rules=rainbow" should
produce identical results, just by different mechanisms.

However, this doesn't work for the "grey.eq", "grey.log", "random" or
"rules" options, as they can't be described by a fixed rule file.

I have suggested dealing with the grey.eq and grey.log cases by adding
additional switches for histogram-equalised and logarithmic tables
(e.g. "r.colors -e ... rules=grey" would be equivalent to
"color=grey.eq").

The "color=random" case would have to be handled specially (or moved
to a seperate r.colors.random program).

The "color=rules" case has always been problematic with regard to the
tcltkgrass interface. It's only within the last month or so that this
was usable within (5.3) tcltkgrass. And it seems to demonstrate a
fundamental issue with the auto-generated GUI, i.e. the need to
hand-code special cases.

2. split out the color=rules from color=[type], and make it a flag.
Currently, color=rules works from the command line but not from the
autogenerated GUI. Unlike the other color=[type] options, it needs to
exec an xterm. Making it a flag rather than a possible color type might
make this easier to solve. The color=[type] option could then be
described as 'predefined GRASS color tables' and the flag as 'create
color table interactively'

Typing rules on stdin is less than ideal. It might be better to just
add a "file=" option (equivalent to color=rules plus stdin
redirection) and require that the user stores their rules in a file.

One possibility would be to extend the GUI for arguments of type
"file" to allow for temporary files (e.g. as an alternative to
choosing an existing file, you could press a button to create a
temporary file and open it in a text editor).

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

3

Typing rules on stdin is less than ideal. It might be better to just
add a "file=" option (equivalent to color=rules plus stdin
redirection) and require that the user stores their rules in a file.

Please lets not lose the ability to do, e.g.:

r.colors mapname col=rules << EOF
  0 red
  1 green
  2 blue
EOF

in scripts, as it's very useful.

H