Subject: r.colors: 0.0%, 100.0% doesn't match 'r.info -r'
Platform: GNU/Linux/i386
grass obtained from: Mirror of Trento site
grass binary for platform: Compiled from Sources
GRASS Version: 5.3-cvs feb 2004
setting r.colors' by percentage value isn't correct, making boundary
values show up on the map as patches of no colour.
e.g.,
G > r.info -r temperature_map
min=10.812000
max=13.251400
G > r.colors temperature_map col=rules << EOF
> 0.0% blue
> 33.333% cyan
> 66.666% yellow
> 100.0% red
> EOF
WARNING: Your color rules do not cover the whole range of data!
Color table for [temperature_map] set to rules
10.824197... colr > 10.812000 map.
here maximum fails cleanly..
?
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.
> 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:
> > 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:
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.