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 _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
