[GRASS5] [bug #2333] (grass) r.colors: 0.0%, 100.0% doesn't match 'r.info -r'

[Glynn Clements]

Hamish wrote:

> > > Subject: r.colors: 0.0%, 100.0% doesn't match 'r.info -r'
> ...
> > > setting r.colors' by percentage value isn't correct, making boundary
> > > values show up on the map as patches of no colour.
> ...
> > src/raster/r.colors/cmd/rules.c, lines 190 and 247:
> > 
> > 	    *val = min + ((double)max-(double)min)*(n+0.5)/100.0;
> > 
> > It adds 0.5% to the specified value. In 4.3, the corresponding lines
> > look like this:
> > 
> > 	    *cat = min + ((double)max-(double)min)*n/100.0 + .5;
> > 
> > where *cat, min, max and n are all integers.
> > 
> > Simply removing the +0.5 would result in a significant improvement,
> > but there could still be residual problems with the actual min/max
> > values due to rounding errors.
> 
> 
> To solve that, could we add something along the lines of:
> 
> if(&val < (double)min)
>     *val = (double)min;
> if(&val > (double)max)
>     *val = (double)max;
> 
> as n>100% and n<0% are illegal, from the lines directly above:
>  if (!lookup_color (color, r,g,b) || n < 0 || n > 100)
> 	    {
> 		badrule(buf,line);
> 		continue;
> 	    }

Just remove the +0.5, which is a leftover from the integer-only days.

Any other issues have to be dealt with in the lookup code. Nothing
that's done in r.colors can eliminate the possibility that
G_lookup_raster_colors() etc might be asked to look up a value which,
because of conversion or rounding errors, lies slightly outside of the
range of the colour table.

> [is it bad to do (n < 0) when n is a double? cast of "0" is automatic?]

No; the literal 0 will automatically be promoted to a double. More
generally, the arguments to a binary operator will be promoted where
necessary.

-- 
Glynn Clements <glynn.clements at virgin.net>