[GRASS-dev] RE: [GRASS-user] Errors applying color rules and
-g flags in r.colors
michael.barton at asu.edu
Fri Apr 20 23:43:42 EDT 2007
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.
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
>>> 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
>> 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
More information about the grass-dev