[GRASS-dev] RE: [GRASS-user] Errors applying color rules and -g flags in r.colors

[Michael Barton]

An interactive color picker is best implemented in an interactive GUI
environment. There are some already active in the current TclTk GUI, and we
are adding quite a few more for user convenience in the new wxPython GUI
that is now under develoment.

Michael


On 4/20/07 8:53 AM, "Patton, Eric" <epatton at nrcan.gc.ca> wrote:

> Thanks, that clears up all the outstanding issues.
> 
> A while back I think I recall someone saying that they had implemented a
> C structure that would allow a color-picker to be used in Grass
> programs. Would it be much difficulty adding this color-picker dialog to
> r.colors to assist in constructing custom color rules files? It seems to
> me that this module would be the ideal place to have such a feature.
> 
> --
> Eric Patton 
> email: epatton at nrcan.gc.ca
> 
>  
> 
>> -----Original Message-----
>> From: Glynn Clements [mailto:glynn at gclements.plus.com]
>> Sent: Thursday, April 19, 2007 4:40 PM
>> To: Patton, Eric
>> Cc: grassuser at grass.itc.it; grass-dev at grass.itc.it
>> Subject: RE: [GRASS-user] Errors applying color rules and -g
>> flags in r.colors
>> 
>> 
>> Patton, Eric wrote:
>> 
>>> I've updated my cvs to include your latest fix to
>> color_rules.c, and
>>> while I'm not receiving the error message I did before,
>> there is still 
>>> some puzzling behavior occurring.
>>> 
>>> The color tables aspectcolr, evi, ndvi, population, and slope still
>>> display an all-white raster when invoked with no flags. However,
>>> applying the -e flag to each of these color tables creates a
>>> full-color, histogram-equalized color table as requested. I'm using
>>> the same floating-point raster as I did previously. Is this
>> expected 
>>> given the types of color tables being used? I'm not
>> familiar with what
>>> 'evi' or 'ndvi' mean and for what types of data they are
>> best suited.
>> 
>> The aspectcolor, population and slope tables only cover
>> positive values, while the evi and ndvi tables cover the
>> range -1 to 1, so it's expected that those tables won't work
>> with the data in question.
>> 
>> OTOH, -e maps the range of the data to the range of the
>> tables; the absolute values used in the tables don't matter.
>> 
>> In general, tables which associate colors with percentages
>> (aspect, bcyr, byg, byr, elevation, grey, gyr, rainbow, ramp,
>> ryb, ryg and
>> wave) can be applied to any data, while those which use
>> absolute values (aspectcolr, curvature, etopo2, evi, ndvi,
>> population, slope, srtm, and terrain) only make sense for
>> data with certain ranges.
>> 
>> You can get a rough idea of the applicability of a colour
>> table by reading the corresponding rules file
>> ($GISBASE/etc/colors/<name>).
>> E.g. slope is defined as:
>> 
>> 0   255 255 255
>> 2   255 255   0
>> 5     0 255   0
>> 10    0 255 255
>> 15    0   0 255
>> 30  255   0 255
>> 50  255   0   0
>> 90    0   0   0
>> 
>> This is designed for the slope map generated by
>> r.slope.aspect, where the value is a slope angle between 0
>> and 90 degrees.
>> 
>> Similarly, the aspectcolr map:
>> 
>> 0 white
>> 1 yellow
>> 90 green
>> 180 cyan
>> 270 red
>> 360 yellow
>> 
>> is designed for the aspect maps produced by r.slope.aspect,
>> where the value is a heading between 0 and 360 degrees.
>> 
>> [The "aspect" map should probably also use 0-360 rather than
>> 0%-100%; I'm not sure why it doesn't.]
>> 
>> --
>> Glynn Clements <glynn at gclements.plus.com>
>> 
> 
> 

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton