Tue, Feb 24 2004
00:43:07
|
|
Request created by guest
|
|
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
G > cat "$MAPSET"/colr/temperature_map
% 10.824197023703662878801878832746 13.263596965230153301718019065447
10.824197023703662878801878832746:0:0:255 11.6365172042:0:255:255
11.6365172042:0:255:255 12.4488373848:255:255:0
12.4488373848:255:255:0 13.263596965230153301718019065447:255:0:0
10.824197... colr > 10.812000 map.
here maximum fails cleanly..
?
Hamish
|
|
Tue, Feb 24 2004
03:14:14
|
|
Mail sent by glynn.clements@virgin.net
|
|
Return-Path |
<glynn.clements@virgin.net>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
From |
Glynn Clements <glynn.clements@virgin.net>
|
MIME-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Transfer-Encoding |
7bit
|
Message-ID |
<16442.45872.678064.793840@cerise.nosuchdomain.co.uk>
|
Date |
Tue, 24 Feb 2004 02:13:04 +0000
|
To |
Request Tracker <grass-bugs@intevation.de>
|
Cc |
grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #2333] (grass) r.colors: 0.0%, 100.0% doesn't match 'r.info -r'
|
In-Reply-To |
<20040223234308.60AD713BC4@lists.intevation.de>
|
References |
<20040223234308.60AD713BC4@lists.intevation.de>
|
X-Mailer |
VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
Request Tracker wrote:
> 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
>
> G > cat "$MAPSET"/colr/temperature_map
> % 10.824197023703662878801878832746 13.263596965230153301718019065447
> 10.824197023703662878801878832746:0:0:255 11.6365172042:0:255:255
> 11.6365172042:0:255:255 12.4488373848:255:255:0
> 12.4488373848:255:255:0 13.263596965230153301718019065447:255:0:0
>
>
>
> 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.
--
Glynn Clements <glynn.clements@virgin.net>
|
|
Tue, Feb 24 2004
06:56:31
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Tue, 24 Feb 2004 18:56:07 +1300
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Glynn Clements <glynn.clements@virgin.net>
|
Cc |
grass-bugs@intevation.de, grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #2333] (grass) r.colors: 0.0%, 100.0% doesn't match 'r.info -r'
|
Message-Id |
<20040224185607.77c4f9f2.hamish_nospam@yahoo.com>
|
In-Reply-To |
<16442.45872.678064.793840@cerise.nosuchdomain.co.uk>
|
References |
<20040223234308.60AD713BC4@lists.intevation.de> <16442.45872.678064.793840@cerise.nosuchdomain.co.uk>
|
X-Mailer |
Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-pc-linux-gnu)
|
X-Face |
M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=US-ASCII
|
Content-Transfer-Encoding |
7bit
|
X-scanner |
scanned by Inflex 1.0.12.7
|
X-Spam-Status |
No, hits=-4.0 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD
|
X-Spam-Level |
|
[bug #2333]
> > 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;
}
[is it bad to do (n < 0) when n is a double? cast of "0" is automatic?]
shrug
thanks,
Hamish
|
|
Tue, Feb 24 2004
07:08:30
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Tue, 24 Feb 2004 19:08:24 +1300
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
grass-bugs@intevation.de
|
Cc |
glynn.clements@virgin.net
|
Subject |
Re: [bug #2333] (grass) Transaction (hamish_nospam@yahoo.com)
|
Message-Id |
<20040224190824.11c5607f.hamish_nospam@yahoo.com>
|
In-Reply-To |
<20040224055631.A9D9613B9A@lists.intevation.de>
|
References |
<20040224055631.A9D9613B9A@lists.intevation.de>
|
X-Mailer |
Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-pc-linux-gnu)
|
X-Face |
M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=US-ASCII
|
Content-Transfer-Encoding |
7bit
|
X-scanner |
scanned by Inflex 1.0.12.7
|
X-Spam-Status |
No, hits=-4.0 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD
|
X-Spam-Level |
|
> 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;
make that
if(fabs(&val - (double)min) < 0.00001)
*val = (double)min;
of course...
that would make the exceedingly long %range line in the colr file a
bit better too..
H
|
|
Tue, Feb 24 2004
18:41:30
|
|
Mail sent by glynn.clements@virgin.net
|
|
Return-Path |
<glynn.clements@virgin.net>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
From |
Glynn Clements <glynn.clements@virgin.net>
|
MIME-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Transfer-Encoding |
7bit
|
Message-ID |
<16443.28109.72094.927026@cerise.nosuchdomain.co.uk>
|
Date |
Tue, 24 Feb 2004 15:29:17 +0000
|
To |
Hamish <hamish_nospam@yahoo.com>
|
Cc |
grass-bugs@intevation.de, grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #2333] (grass) r.colors: 0.0%, 100.0% doesn't match 'r.info -r'
|
In-Reply-To |
<20040224185607.77c4f9f2.hamish_nospam@yahoo.com>
|
References |
<20040223234308.60AD713BC4@lists.intevation.de> <16442.45872.678064.793840@cerise.nosuchdomain.co.uk> <20040224185607.77c4f9f2.hamish_nospam@yahoo.com>
|
X-Mailer |
VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
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@virgin.net>
|
|
Wed, Feb 25 2004
05:13:29
|
|
Status changed to resolved by hbowman
|
|
Wed, Feb 25 2004
05:13:29
|
|
Comments added by hbowman
|
|
|