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.
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.
If these sound interesting to people, but will take some time to implement, I'll put them in the svn tracker as enhancements.
Michael
______________________________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ 85287-2402
USA
voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
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.
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.
--
Glynn Clements <glynn@gclements.plus.com>
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
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?
Trunk.
It may need a G_find_cell2() call to work in 6.4. In 7.x, any libgis
functions which deal with existing maps should accept "" for the
mapset argument, eliminating the need for explicit G_find_* calls in
most cases.
On that front, r32633 should probably be back-ported. It fixes the
case of passing qualified names to G__open[_misc] and G_read_colors().
[Colour tables need special treatment because of the colr2 feature.
The g3d library has a similar feature which is both more general and,
AFAICT, seriously borked.]
--
Glynn Clements <glynn@gclements.plus.com>
On Tue, Aug 12, 2008 at 7:34 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:
Michael Barton wrote:
Glynn:
Added as r.colors.out.
In trunk? Backported to develbranch_6?
Trunk.
It may need a G_find_cell2() call to work in 6.4. In 7.x, any libgis
functions which deal with existing maps should accept "" for the
mapset argument, eliminating the need for explicit G_find_* calls in
most cases.
On that front, r32633 should probably be back-ported. It fixes the
case of passing qualified names to G__open[_misc] and G_read_colors().
[Colour tables need special treatment because of the colr2 feature.
The g3d library has a similar feature which is both more general and,
AFAICT, seriously borked.]
So,
http://trac.osgeo.org/grass/changeset/32633
should we do this? Any side effects?
Markus (on the road till Tuesday)
Markus Neteler wrote:
>>> Added as r.colors.out.
>>
>> In trunk? Backported to develbranch_6?
>
> Trunk.
>
> It may need a G_find_cell2() call to work in 6.4. In 7.x, any libgis
> functions which deal with existing maps should accept "" for the
> mapset argument, eliminating the need for explicit G_find_* calls in
> most cases.
>
> On that front, r32633 should probably be back-ported. It fixes the
> case of passing qualified names to G__open[_misc] and G_read_colors().
>
> [Colour tables need special treatment because of the colr2 feature.
> The g3d library has a similar feature which is both more general and,
> AFAICT, seriously borked.]
So,
http://trac.osgeo.org/grass/changeset/32633
should we do this? Any side effects?
That should be safe.
There's also r32717 (which requires r32715) and r32735. Both of those
should be safe (r32715 definitely is, and can be committed
independently of the other two).
I'm now reasonably sure that all library functions which accept a name
and mapset will accept an empty mapset ("") with either a qualified or
unqualified name.
The only exceptions are G__file_name() and G__file_name_misc(), which
need to be able to construct filenames for maps which are in the
process of being created, so they can't use G_find_file() etc.
--
Glynn Clements <glynn@gclements.plus.com>
On Wed, Aug 13, 2008 at 10:23 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:
Markus Neteler wrote:
>>> Added as r.colors.out.
>>
>> In trunk? Backported to develbranch_6?
>
> Trunk.
>
> It may need a G_find_cell2() call to work in 6.4. In 7.x, any libgis
> functions which deal with existing maps should accept "" for the
> mapset argument, eliminating the need for explicit G_find_* calls in
> most cases.
>
> On that front, r32633 should probably be back-ported. It fixes the
> case of passing qualified names to G__open[_misc] and G_read_colors().
>
> [Colour tables need special treatment because of the colr2 feature.
> The g3d library has a similar feature which is both more general and,
> AFAICT, seriously borked.]
So,
http://trac.osgeo.org/grass/changeset/32633
should we do this? Any side effects?
That should be safe.
There's also r32717 (which requires r32715) and r32735. Both of those
should be safe (r32715 definitely is, and can be committed
independently of the other two).
All r32715, r32717 and r32735 are backported now.
I'm now reasonably sure that all library functions which accept a name
and mapset will accept an empty mapset ("") with either a qualified or
unqualified name.
The only exceptions are G__file_name() and G__file_name_misc(), which
need to be able to construct filenames for maps which are in the
process of being created, so they can't use G_find_file() etc.
Markus