[GRASS-dev] A couple of r.colors ideas

[Michael Barton]

On Aug 11, 2008, at 6:04 PM, Glynn Clements wrote:

>
> Michael Barton wrote:
>
>> I'm in the process of creating a new GUI for creating raster color
>> tables, and ran into a couple of function ideas that would be helpful
>> in the context of a GUI wrapper and (I think) for other users.
>>
>> 1) I realized that there is no simple way to 'export' an existing
>> color table to a standard color table rules file, although r.info can
>> take a rules file and turn it into a color table. You can copy a  
>> color
>> table between raster files, but it also would be handy to be able to
>> export one.
>
> Added as r.colors.out.

Thanks much.

In trunk? Backported to develbranch_6?

>
>
>> 2) Since the various d.* modules are in redevelopment, one idea that
>> seems handy would be to be able to explicitly apply a color table
>> during display
>>
>> e.g.: d.rast map=nice_raster colortable=nice_colors.txt
>>
>> This way, a map could be displayed with multiple color tables without
>> overwriting a default color table. The same concept might also be
>> applied to vectors.
>
> This could be useful, but it essentially means adding a copy of
> r.colors to each of d.rast and d.vect.
>
> Essentially, the only part of r.colors which wouldn't be used in such
> a situation is the final call to G_write_colors(). Oh; you probably
> wouldn't want the code to deal with interactive prompting, but that
> should arguably be removed from r.colors for 7.x.
>
> Of course, you could further reduce the amount of code by eliminating
> various features (e.g. using the colour table from another map, log
> and hist-eq scaling, etc), but that just create more cases where you
> would still need to use e.g. r.colors + d.rast separately.

Good points. I didn't know how much code from r.colors would or would  
not be necessary to include.

Michael