[GRASS-dev] r.colors "-e" not going to full range

[Hamish]

Hi,

I just created a v.surf.rst elevation surface from some point data which
has a few negative values in it. After creating the surface I set the
colors with 'r.colors -e color=bcyr'. It looks really nice but there are
white holes in the d.rast display.

r.info -r shows:
min=-1.510814
max=146.157700

The colr/ file doesn't go to one integer beyond the full range:
----------------------------------
% -1 145
nv:255
*:255
-1:0:0:255 0:0:94:255
...
144:255:1:0 145:255:1:0
----------------------------------

??


I also noticed for another map 'r.colors -e' made a massive and slow
colr/ file (1 for each cat) when the raster values were +-250000. That
was a diff map centered on zero and I was using r.colors.stddev (wiki
addons) to set the colors. While it had those huge outliers 95% of the
points were +-5 (hence using the -e flag to get useful colors). It took
impossibly long to render of course, so I looked in the colr/ file and
discovered it was huge.

Ok, maybe that's a feature of the -e method. But what I saw that was
interesting was that between -265000 and -120 all the R:G:B values were
identical, ie all those thousands and thousands of rules could have been
condensed into a single "-265000:R:G:B -120:R:G:B". And that a little
program to do that would probably be trivial.  I am a bit unsure if that
condensing should happen as a addon script which reprocesses the file,
when the colr/ file is created by 'r.colors -e', or when the color rules
are read in upon d.rast. (or some combination of the above) It would seem like a nice enhancement to have that happen though.

I notice that even in my current -1.5 thru 146m map '-e' produces some redundant entries.


Hamish