Details Ticket 2333


Comment | Reply | Take | Open


Serial Number 2333
Subject r.colors: 0.0%, 100.0% doesn't match 'r.info -r'
Area bug
Queue grass
Requestors hamish_nospam@yahoo.com
Owner none
Status resolved
Last User Contact Tue Feb 24 18:41:30 2004 (5 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Wed Feb 25 05:13:29 2004 (5 yr ago)
Created Tue Feb 24 00:43:07 2004 (5 yr ago)

Transaction History Ticket 2333


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  
done.


Hamish
Comment | Reply | Take | Open

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request