[GRASS5] Re: rules in r.colors

GRASS GRASS developer
1

Glynn,

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.

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. 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).

All in all, GRASS has some very nice and diverse ways of managing colors for raster files. Maybe it is already pretty much as good as it can get without a lot of trouble. But this discussion seems useful. Thanks for the work you've put into this.

Michael Barton
______________________________
Michael Barton, Professor & Curator
School of Human Origins, Cultures, & Societies
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
On May 14, 2004, at 4:02 PM, grass5-request@grass.itc.it wrote:

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.

2

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@virgin.net>

3

> 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=".

Another solution (which I'm not endorsing here, just pointing out) is to
use a flag to specify the rules file is local file.

eg non-functional pseudo-code:

if(flag_local->answer)
    strcpy(filename, opt_rules->answer);
else {
    strcpy(filename, "$GISBASE/etc/colors/");
    strcat(filename, opt_rules->answer);
}
fp1 = fopen(filename, "r");

I don't like -l flags as they can be confused with -1 in some fonts.

Hamish

4

On Mon, May 17, 2004 at 12:49:39PM +1200, Hamish wrote:

> > 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=".

Another solution (which I'm not endorsing here, just pointing out) is to
use a flag to specify the rules file is local file.

eg non-functional pseudo-code:

if(flag_local->answer)
    strcpy(filename, opt_rules->answer);
else {
    strcpy(filename, "$GISBASE/etc/colors/");
    strcat(filename, opt_rules->answer);
}
fp1 = fopen(filename, "r");

I don't like -l flags as they can be confused with -1 in some fonts.

What about making this a function? For integration into the
parser part (as done in 5.7 to find the installed DB drivers)
?

Markus