Details Ticket 2790


Comment | Reply | Take | Open


Serial Number 2790
Subject r.bilinear result is rounded to .5
Area grass6
Queue grass
Requestors gruber@slf.ch,tutey@o2.pl
Owner none
Status resolved
Last User Contact Thu Aug 24 19:16:06 2006 (2 yr ago)
Current Priority 20
Final Priority 70
Due No date assigned
Last Action Thu Aug 24 21:33:46 2006 (2 yr ago)
Created Mon Dec 6 11:39:07 2004 (4 yr ago)

Transaction History Ticket 2790


Mon, Dec 6 2004 11:39:07    Request created by guest  
Subject: r.bilinear result is rounded to .5, GUI and --help issues

Platform: GNU/Linux/i386
grass obtained from: Mirror of Trento site
grass binary for platform: Compiled from Sources
GRASS Version: grass57_exp_2004_11_13

1. Why does r.bilinear output rasters "rounded" to .5 instead of full floating
point?

2. r.bilinear GUI - parameters names 'north' and 'east' missing.

3. Strange is how 'r.bilinear --help' explains what they are:

Parameters:
(...)
   north   (null)
    east   (null)
Mon, Dec 6 2004 13:31:06    Mail sent by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Date Mon, 6 Dec 2004 13:32:42 +0100
From Markus Neteler <neteler@itc.it>
To Request Tracker <grass-bugs@intevation.de>
Cc grass5@grass.itc.it
Subject Re: [GRASS5] [bug #2790] (grass) r.bilinear result is rounded to .5, GUI and --help issues
Message-ID <20041206123242.GA19291@thuille.itc.it>
Mail-Followup-To Request Tracker <grass-bugs@intevation.de>, grass5@grass.itc.it
References <20041206103907.A87F1100167@lists.intevation.de>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
In-Reply-To <20041206103907.A87F1100167@lists.intevation.de>
User-Agent Mutt/1.4.1i
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
On Mon, Dec 06, 2004 at 11:39:07AM +0100, Request Tracker wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=2790
> -------------------------------------------------------------------------
> 
> Subject: r.bilinear result is rounded to .5, GUI and --help issues
> 
> Platform: GNU/Linux/i386
> grass obtained from: Mirror of Trento site
> grass binary for platform: Compiled from Sources
> GRASS Version: grass57_exp_2004_11_13
> 
> 1. Why does r.bilinear output rasters "rounded" to .5 instead of full floating
point?

[ I don't know ]
 
> 2. r.bilinear GUI - parameters names 'north' and 'east' missing.

Fixed in 5.7-CVS

> 3. Strange is how 'r.bilinear --help' explains what they are:
> 
> Parameters:
> (...)
>    north   (null)
>     east   (null)

Got also fixed by above fix.

Markus


Thu, Jul 21 2005 13:47:09    Mail sent by mneteler  
Remains:

> 1. Why does r.bilinear output rasters "rounded" to .5 instead of full
floating point?

What to do? Bug confirmed?

Markus
Fri, Sep 2 2005 17:48:55    User changed to werchowyna@epf.pl by msieczka  
Fri, Sep 2 2005 17:53:36    Mail sent by msieczka  
Markus via RT wrote:

> Remains:
>> 1. Why does r.bilinear output rasters "rounded" to .5 instead of full
>> floating point?
> What to do? Bug confirmed?

Sorry Markus, your question didn't reach me as my email has slightly changed
to werchowyna@epf.pl. I will chnge all my ancient reports accordingly so
communication about them will be possible.

Regarding the bug - yes, it remains. r.blinear outputs "halfs" intead of
either floating or integer.

Maciek
Fri, Sep 2 2005 17:54:16    Area changed to grass6 by msieczka  
Fri, Sep 2 2005 17:54:27    Subject changed to r.bilinear result is rounded to .5 by msieczka  
Fri, Feb 10 2006 16:07:11    Request created by guest (as #4076)  
Subject: r.bilinear: does it work correctly ?

Platform: WindowsNT/2000/XP
grass obtained from: Mirror of Trento site
grass binary for platform: Downloaded precompiled Binaries
GRASS Version: GRASS 6.0.0 (2005)

I did a comparison between latticeresample of arcinfo, that is supposed to work
also with a bilinear algorithm and r.bilinear on the same area. The boundaries
of both files are identical, i.e. the pixels should be comparable.

I made a resampling of a DEM from 25 to 10 m. Then I compared the results of
the two bilinear approaches. They are not identical. To illustrate the difference
I give you the following example. Imagine four 25m input pixels. After the resampling
you get 25 10m output pixels, where the central pixel (position 3,3 in the 5x5
field) is intersecting with all four original input pixels. Let's concentrate
on this central output pixel. The distance from the center of this central output
pixel to the centers of the four input pixels is equal to all four input pixels.
So what I would expect is that the bilinear interpolation would give the average
of all four input pixels. The altitudes of the four input cells are UL: 1912.09,
UR: 1917.2, LL: 1925.8, LR: 1931.6. --> The average thus is 1921.68, which was
also the result that was provided by latticeresample. The result of r.bilinear
was 1922.25, which is a difference of more than half a meter. Since in the command
reference of r.bilinear is written that only the 4 input cells are considered,
I can not find an explanation why the result should be 1922.25 instead of 1921.68.
I checked also the open bugs. I found the one with 0.5 rounding. Maybe my problem
is linked to the previous one, but since I got a value of 1922.25 (not rounded
to 0.5), I'm a little bit at a loss. 

Best regards

Urs Gruber
Fri, Feb 10 2006 17:06:28    Mail sent by werchowyna@epf.pl (as #4076)  
Return-Path <werchowyna@epf.pl>
Delivered-To grass-bugs@lists.intevation.de
Date Fri, 10 Feb 2006 17:06:24 +0100
From Maciek Sieczka <werchowyna@epf.pl>
To Request Tracker <grass-bugs@intevation.de>
Cc grass5@grass.itc.it
Subject Re: [GRASS5] [bug #4076] (grass) r.bilinear: does it work correctly ?
Message-Id <20060210170624.ef19f189.werchowyna@epf.pl>
In-Reply-To <20060210150711.673FD100161@lists.intevation.de>
References <20060210150711.673FD100161@lists.intevation.de>
X-Mailer Sylpheed version 2.1.1 (GTK+ 2.8.6; i486-pc-linux-gnu)
Mime-Version 1.0
Content-Type text/plain; charset=US-ASCII
Content-Transfer-Encoding 7bit
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Urs,

Can you also compare to output of gdalwarp for a cross test? Since you
have Grass installed you propably have gdalwarp, which is a component
of GDAL.

The command would be like:
gdalwarp -rb -tr 10 10 your_input your_output

Maciek

--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze
z nich!
http://katalog.panoramainternetu.pl/


Mon, Feb 13 2006 15:44:38    Mail sent by gruber@slf.ch (as #4076)  
Return-Path <gruber@slf.ch>
Delivered-To grass-bugs@lists.intevation.de
Message-ID <43F09B28.3030905@slf.ch>
Date Mon, 13 Feb 2006 15:43:52 +0100
From Urs Gruber <gruber@slf.ch>
User-Agent Thunderbird 1.5 (Windows/20051201)
MIME-Version 1.0
To Maciek Sieczka via RT <grass-bugs@intevation.de>
Subject Re: [bug #4076] (grass) r.bilinear: does it work correctly
References <20060210160628.37968100161@lists.intevation.de>
In-Reply-To <20060210160628.37968100161@lists.intevation.de>
Content-Type text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding 8bit
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Dear Maciek

Thanks for the quick response to my problem.

I managed to use gdalwarp. The result of this procedure reveals the 
correct result for the particular pixel, i.e. 1921.68.

Best regards

Urs

Maciek Sieczka via RT schrieb:
> Urs,
>
> Can you also compare to output of gdalwarp for a cross test? Since you
> have Grass installed you propably have gdalwarp, which is a component
> of GDAL.
>
> The command would be like:
> gdalwarp -rb -tr 10 10 your_input your_output
>
> Maciek
>
> --------------------
> W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze
z nich!
> http://katalog.panoramainternetu.pl/
>
>
> --- Headers Follow ---
>
> >From werchowyna@epf.pl  Fri Feb 10 17:06:28 2006
> Return-Path: <werchowyna@epf.pl>
> Delivered-To: grass-bugs@lists.intevation.de
> Received: from mail.intevation.de (aktaia [212.95.126.10])
> 	by lists.intevation.de (Postfix) with ESMTP id 04497100159
> 	for <grass-bugs@lists.intevation.de>; Fri, 10 Feb 2006 17:06:28 +0100 (CET)
> Received: from localhost (localhost [127.0.0.1])
> 	by mail.intevation.de (Postfix) with ESMTP id B714836D7F
> 	for <grass-bugs@lists.intevation.de>; Fri, 10 Feb 2006 17:06:27 +0100 (CET)
> Received: from mail133.pi.net.pl (gips.pi.net.pl [195.116.221.99])
> 	by mail.intevation.de (Postfix) with SMTP id 3E6A636CE4
> 	for <grass-bugs@intevation.de>; Fri, 10 Feb 2006 17:06:26 +0100 (CET)
> Received: (qmail 32437 invoked from network); 10 Feb 2006 16:06:25 -0000
> Received: from unknown (HELO sorbus) (werchowyna@83.27.32.1)
>   by 195.205.153.133 with SMTP; 10 Feb 2006 16:06:25 -0000
> Date: Fri, 10 Feb 2006 17:06:24 +0100
> From: Maciek Sieczka <werchowyna@epf.pl>
> To: Request Tracker <grass-bugs@intevation.de>
> Cc: grass5@grass.itc.it
> Subject: Re: [GRASS5] [bug #4076] (grass) r.bilinear: does it work correctly
>  ?
> Message-Id: <20060210170624.ef19f189.werchowyna@epf.pl>
> In-Reply-To: <20060210150711.673FD100161@lists.intevation.de>
> References: <20060210150711.673FD100161@lists.intevation.de>
> X-Mailer: Sylpheed version 2.1.1 (GTK+ 2.8.6; i486-pc-linux-gnu)
> Mime-Version: 1.0
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 7bit
> X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
> X-Spam-Level: 
>
> -------------------------------------------- Managed by Request Tracker
>
>   


-- 
Urs Gruber, PhD
Swiss Federal Institute for Snow and Avalanche Research, SLF
Section Snow and Avalanche
Flüelastr. 11
CH-7260 Davos Dorf
Switzerland

phone +41-81-417 02 62
fax +41-81-417 01 10
gruber@slf.ch
http//www.slf.ch/welcome-en.html
http//www.slf.ch/institut/schnee-lawinen-en.html


Tue, Feb 14 2006 17:16:21    Mail sent by gruber@slf.ch (as #4076)  
Return-Path <gruber@slf.ch>
Delivered-To grass-bugs@lists.intevation.de
Message-ID <43F20224.5040702@slf.ch>
Date Tue, 14 Feb 2006 17:15:32 +0100
From Urs Gruber <gruber@slf.ch>
User-Agent Thunderbird 1.5 (Windows/20051201)
MIME-Version 1.0
To Maciek Sieczka via RT <grass-bugs@intevation.de>
Subject Re: [bug #4076] (grass) r.bilinear: does it work correctly
References <20060210160628.37968100161@lists.intevation.de>
In-Reply-To <20060210160628.37968100161@lists.intevation.de>
Content-Type text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding 8bit
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Maciek

Just to illustrate my problem in more detail: I made a simple test with 
a 4x4 cell 25m raster grid.

Below the original grid in the ESRI ASCII format:

ncols 4
nrows 4
xllcorner 87.5
yllcorner 12.5
cellsize 25.000000
NODATA_value -9999
10.1 15.2 20.3 25.4
30.5 35.6 40.7 45.8
50.9 55.1 60.2 65.3
70.4 75.5 80.6 85.7

Here's the result of the bilinear interpolation to 10m by 
latticeresample (ArcInfo)

ncols 10
nrows 10
xllcorner 87.5
yllcorner 12.5
cellsize 10
NODATA_value -9999
-9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999
-9999 12.65 14.69 16.73 18.77 20.81 22.85 24.89 26.93 -9999
-9999 20.81 22.85 24.89 26.93 28.97 31.01 33.05 35.09 -9999
-9999 28.97 31.01 33.05 35.09 37.13 39.17 41.21 43.25 -9999
-9999 37.103 39.035 40.967 42.98 45.02 47.06 49.1 51.14 -9999
-9999 45.227 47.015 48.803 50.78 52.82 54.86 56.9 58.94 -9999
-9999 53.279 54.995 56.711 58.67 60.71 62.75 64.79 66.83 -9999
-9999 61.115 62.975 64.83501 66.83 68.87 70.91 72.95 74.99 -9999
-9999 68.951 70.955 72.959 74.99 77.03 79.07 81.11 83.14999 -9999
-9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999

And here's the result of r.bilinear to 10m:

ncols 10
nrows 10
xllcorner 87.5
yllcorner 12.5
cellsize 10.000000
NODATA_value -9999
10.5 11 13 15 17 19 21 23 25 25.5
12.6 13.1 15.1 17.1 19.1 21.1 23.1 25.1 27.1 27.6
21 21.5 23.5 25.5 27.5 29.5 31.5 33.5 35.5 36
29.4 29.9 31.9 33.900002 35.900002 37.900002 39.900002 41.900002 
43.900002 44.400002
37.5 37.970001 39.849998 41.73 43.700001 45.700001 47.700001 49.700001 
51.700001 52.200001
45.5 45.93 47.650002 49.369999 51.299999 53.299999 55.299999 57.299999 
59.299999 59.799999
53.400002 53.82 55.5 57.18 59.099998 61.099998 63.099998 65.099998 
67.099998 67.599998
61 61.5 63.5 65.5 67.5 69.5 71.5 73.5 75.5 76
68.599998 69.18 71.5 73.82 75.900002 77.900002 79.900002 81.900002 
83.900002 84.400002
70.5 71.099998 73.5 75.900002 78 80 82 84 86 86.5

My basic question is, why the cell (3¦3) is with r.bilinear equal to 
23.5 and not as with latticeresample
22.85 (i.e. (10.5 + 15.2 + 30.5 + 35.6) / 4).

Best regards

Urs


Maciek Sieczka via RT schrieb:
> Urs,
>
> Can you also compare to output of gdalwarp for a cross test? Since you
> have Grass installed you propably have gdalwarp, which is a component
> of GDAL.
>
> The command would be like:
> gdalwarp -rb -tr 10 10 your_input your_output
>
> Maciek
>
> --------------------
> W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze
z nich!
> http://katalog.panoramainternetu.pl/
>
>
>   


Thu, Feb 16 2006 14:03:17    Mail sent by msieczka (as #4076)  
Urs,

Sorry I haven't replied earlier but you didn't forward to grass dev list -
currently bugtracker won't do it for you automatically.

Moreover, I can't be of any help more. You found a bug and we'll need to wait
for a developer wishing to fix it. Below I'm forwarding your messages so grass
dev subscribers can a have a look.

Urs wrote:

> I managed to use gdalwarp. The result of this procedure reveals the 
> correct result for the particular pixel, i.e. 1921.68.

Urs wrote, next:

> Just to illustrate my problem in more detail: I made a simple test with 
> a 4x4 cell 25m raster grid.

> Below the original grid in the ESRI ASCII format:

ncols 4
nrows 4
xllcorner 87.5
yllcorner 12.5
cellsize 25.000000
NODATA_value -9999
10.1 15.2 20.3 25.4
30.5 35.6 40.7 45.8
50.9 55.1 60.2 65.3
70.4 75.5 80.6 85.7

Here's the result of the bilinear interpolation to 10m by 
latticeresample (ArcInfo)

ncols 10
nrows 10
xllcorner 87.5
yllcorner 12.5
cellsize 10
NODATA_value -9999
-9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999
-9999 12.65 14.69 16.73 18.77 20.81 22.85 24.89 26.93 -9999
-9999 20.81 22.85 24.89 26.93 28.97 31.01 33.05 35.09 -9999
-9999 28.97 31.01 33.05 35.09 37.13 39.17 41.21 43.25 -9999
-9999 37.103 39.035 40.967 42.98 45.02 47.06 49.1 51.14 -9999
-9999 45.227 47.015 48.803 50.78 52.82 54.86 56.9 58.94 -9999
-9999 53.279 54.995 56.711 58.67 60.71 62.75 64.79 66.83 -9999
-9999 61.115 62.975 64.83501 66.83 68.87 70.91 72.95 74.99 -9999
-9999 68.951 70.955 72.959 74.99 77.03 79.07 81.11 83.14999 -9999
-9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999 -9999

> And here's the result of r.bilinear to 10m:

ncols 10
nrows 10
xllcorner 87.5
yllcorner 12.5
cellsize 10.000000
NODATA_value -9999
10.5 11 13 15 17 19 21 23 25 25.5
12.6 13.1 15.1 17.1 19.1 21.1 23.1 25.1 27.1 27.6
21 21.5 23.5 25.5 27.5 29.5 31.5 33.5 35.5 36
29.4 29.9 31.9 33.900002 35.900002 37.900002 39.900002 41.900002 
43.900002 44.400002
37.5 37.970001 39.849998 41.73 43.700001 45.700001 47.700001 49.700001 
51.700001 52.200001
45.5 45.93 47.650002 49.369999 51.299999 53.299999 55.299999 57.299999 
59.299999 59.799999
53.400002 53.82 55.5 57.18 59.099998 61.099998 63.099998 65.099998 
67.099998 67.599998
61 61.5 63.5 65.5 67.5 69.5 71.5 73.5 75.5 76
68.599998 69.18 71.5 73.82 75.900002 77.900002 79.900002 81.900002 
83.900002 84.400002
70.5 71.099998 73.5 75.900002 78 80 82 84 86 86.5

> My basic question is, why the cell (3¦3) is with r.bilinear equal to 
> 23.5 and not as with latticeresample
> 22.85 (i.e. (10.5 + 15.2 + 30.5 + 35.6) / 4).
Sat, Jul 22 2006 15:28:04    Request 4076 merged into 2790 by mneteler (as #4076)  
Wed, Jul 26 2006 14:20:41    User changed to gruber@slf.ch,tutey@o2.pl by msieczka  
Thu, Aug 3 2006 18:18:13    Mail sent by guest  
I can't reproduce this bug using the elevation.dem and elevation.10m raster in
spearfish with 2006-07-31 cvs:

r.bilinear input=elevation_dem output=elevation_dem.bilinear 

Querying randon cells in the output raster shows they have floating point
resolution. r.describe confirms:

r.describe map=elevation_dem.bilinear
READING [elevation_dem.bilinear in PERMANENT] ... 100%
* 1066.973389-1839.488281

~ Eric.
<epatton at nrcan dot gc dot ca>


Thu, Aug 3 2006 18:33:38    Mail sent by guest  
Followup:

I can confirm that the .5 output from r.bilinear only happens when the input
raster is type CELL. I can't reproduce this bug when using FCELL maps (from
spearfish: aspect, elevation.10m, slope, erosion1, uparea).

~ Eric.
<epatton at nrcan dot gc dot ca>
Thu, Aug 3 2006 19:03:53    Mail sent by msieczka  
Eric wrote:

> Followup:
> 
> I can confirm that the .5 output from r.bilinear only happens when the input
> raster is type CELL. I can't reproduce this bug when using FCELL maps (from
> spearfish: aspect, elevation.10m, slope, erosion1, uparea).

For me the r.bilinear output is rounded to .5 no matter what the input is. 
See:

The INTEGER input case:

	$ r.info -t elevation.dem
	datatype=CELL

	$ g.region rast=elevation.dem -a

	$ r.bilinear input=elevation.dem output=elevation.dem.bil

 The total number of all non-null cells is:

	$ r.stats elevation.dem.bil -1n | wc -l
	r.stats:  100%
	291909

 And all them end with .5:

	$ r.stats elevation.dem.bil -1n | grep -c "\.5"
	r.stats:  100%
	291909

FP case: it's all the same, the output is still all rounded to .5:

	$ r.info -t slope
	datatype=FCELL

	$ g.region rast=slope -a

	$ r.bilinear input=slope@PERMANENT output=slope.bil

 The total number of all non-null cells is:

	$ r.stats slope.bil -1n | wc -l
	r.stats:  100%
	289029

 And all them end with .5, as you can see:

	$ r.stats slope.bil -1n | grep -c "\.5"
	r.stats:  100%
	289029
	$ r.stats slope.bil -1n | grep -vc "\.5"
	r.stats:  100%
	0

Can you provide a reproducible test proving the opposite?

Maciek
Thu, Aug 3 2006 19:21:12    Mail sent by guest  
You're right, I double-checked and every raster I try gets ".5" in the output.
So the bug still stands.

~ Eric.
Thu, Aug 3 2006 19:28:08    Mail sent by msieczka  
msieczka wrote (Thu, Aug 3 2006 19:03:53):
> For me the r.bilinear output is rounded to .5 no matter what the input is.
Wait, not really (but something's stinky here, anyway). *If* I zoom in

$ g.region -p
projection: 1 (UTM)
zone:       13
datum:      nad27
ellipsoid:  clark66
north:      4920270
south:      4917870
west:       603330
east:       606570
nsres:      30
ewres:      30
rows:       80
cols:       108

and repeat the operation, the outcome is that not all r.bilinear output cells
are rounded to .5, but still 1/3 is (too much to be right):

 FCELL case:

        r.bilinear input=slope output=slope.frag.bil

	r.stats slope.frag.bil -1n | wc -l
        r.stats:  100%
        8640

	r.stats slope.frag.bil -1n | grep -c "\.5"
	r.stats:  100%
	2903

	r.stats slope.frag.bil -1n | grep -vc "\.5"
	r.stats:  100%
	5737

 CELL input case is pretty much the same:

        r.bilinear input=elevation.dem output=elevation.dem.frag.bil

	r.stats elevation.dem.frag.bil -1n | wc -l
	r.stats:  100%
	8640

	r.stats elevation.dem.frag.bil -1n | grep -c "\.5"
	r.stats:  100%
	2792

	r.stats elevation.dem.frag.bil -1n | grep -vc "\.5"
	r.stats:  100%
	5848

I hope this info will be enough for devs to fix the bug.

Maciek
Thu, Aug 3 2006 19:29:03    Mail sent by guest  
You're right, I double-checked and every raster I try gets ".5" in the output.
So the bug still stands.

~ Eric.
Thu, Aug 3 2006 19:31:05    Mail sent by msieczka  
Summarising:

1. If the region covers the whole input raster, the whole r.bilinear input is
rounded to .5.

2. If the region covers only a subset of the input raster, the r.bilinear
input is rounded to .5 in about 33%.

For details please see above.

Maciek
Sat, Aug 12 2006 17:38:40    Mail sent by guest  
Probably fixed?

http://grass.itc.it/pipermail/grass-commit/2006-August/023057.html

Markus

PS: I backported that to 6.2 and 6.2
Wed, Aug 23 2006 17:46:14    Mail sent by guest  
I can confirm that this bug is now fixed in Grass 6.3 (cvs 2006-08-22):

For datatype DCELL:
========================================================
r.info -t elevation.10m
datatype=DCELL

r.bilinear input=elevation.10m output=elevation.10m.bil

r.stats -1n elevation.10m.bil | wc -l
r.stats:  100%
2654802

r.stats -1n elevation.10m.bil | grep -c "\.5"
r.stats:  100%
266062
========================================================

For datatype FCELL:

r.info -t slope
datatype=FCELL

r.bilinear input=slope output=slope.bil

r.stats -1n slope.bil | wc -l
r.stats:  100%
2601261

r.stats -1n slope.bil | grep -c "\.5"
r.stats:  100%
256207
========================================================

For datatype CELL:

r.info soils
datatype=CELL

r.bilinear input=soils output=soils.bil

r.stats -1n soils.bil | wc -l
r.stats:  100%
2629418

r.stats -1n soils.bil | grep -c "\.5"
r.stats:  100%
39147
========================================================

Thanks Glynn!

~ Eric.
<epatton at nrcan dot gc dot ca>



Thu, Aug 24 2006 12:45:27    Mail sent by msieczka  
Indeed r.bilinear doesn't produce atrifact .5 and stuff anymore, but it's
output is slightly different than the output of the new r.resamp.interp
method=bilinear. 

See spearfish60 example:

$ g.region rast=slope -a
$ g.region res=10.95 -a
$ r.bilinear input=slope output=slope_rbil
$ r.resamp.interp input=slope output=slope_rinterp method=bilinear

$ r.mapcalc 'diff=slope_rbil-slope_rinterp'

There is a minimal difference...

$ r.info -r diff
min=-0.000000
max=0.000000

... which can be seen on display as a kind off a regular pattern, and if
exagerated x10^15 it is noticable as:

$ r.mapcalc 'diff_exag=diff*10.0^15.0'
$ r.info diff_exag -r
min=-7.105427
max=7.105427

?

Maciek
Thu, Aug 24 2006 19:16:06    Mail sent by glynn@gclements.plus.com  
Return-Path <glynn@gclements.plus.com>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn@gclements.plus.com>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <17645.57038.924727.520584@cerise.gclements.plus.com>
Date Thu, 24 Aug 2006 18:15:58 +0100
To Maciek Sieczka via RT <grass-bugs@intevation.de>
Cc grass-dev@grass.itc.it
Subject Re: [GRASS-dev] [bug #2790] (grass) r.bilinear result is rounded to .5
In-Reply-To <20060824104527.B059A1006B5@lists.intevation.de>
References <20060824104527.B059A1006B5@lists.intevation.de>
X-Mailer VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-4.019 tagged_above=-999 required=3 tests=[AWL=0.981, BAYES_00=-5]
X-Spam-Level
Maciek Sieczka via RT wrote:

> Indeed r.bilinear doesn't produce atrifact .5 and stuff anymore, but it's
> output is slightly different than the output of the new r.resamp.interp
> method=bilinear. 
> 
> See spearfish60 example:
> 
> $ g.region rast=slope -a
> $ g.region res=10.95 -a
> $ r.bilinear input=slope output=slope_rbil
> $ r.resamp.interp input=slope output=slope_rinterp method=bilinear
> 
> $ r.mapcalc 'diff=slope_rbil-slope_rinterp'
> 
> There is a minimal difference...
> 
> $ r.info -r diff
> min=-0.000000
> max=0.000000
> 
> ... which can be seen on display as a kind off a regular pattern, and if
> exagerated x10^15 it is noticable as:
> 
> $ r.mapcalc 'diff_exag=diff*10.0^15.0'
> $ r.info diff_exag -r
> min=-7.105427
> max=7.105427
> 
> ?

That level of error can easily be attributed to differences in
rounding. It's by no means clear which of the two (if either) is more
accurate.

For IEEE FP, DBL_EPSILON is ~2.2e-16, so a value of ~7.1e-15 is
roughly 32 * DBL_EPSILON. "r.info slope" gives the range as roughly
0-52.5, so I'd expect to see errors of +/- 1.2e-14 (i.e. around 63%
more than you're actually getting).

Differences at that scale are irrelevant; there's no way that your
source data is going to be accurate to 16 digits (2.2e-16 is
equivalent to measuring the equatorial circumference to an accuracy of
10 nanometres).

-- 
Glynn Clements <glynn@gclements.plus.com>


Thu, Aug 24 2006 21:33:30    Mail sent by tutey@o2.pl  
Return-Path <tutey@o2.pl>
Delivered-To grass-bugs@lists.intevation.de
Message-ID <44EDFF00.8070305@o2.pl>
Date Thu, 24 Aug 2006 21:33:20 +0200
From Maciej Sieczka <tutey@o2.pl>
User-Agent Thunderbird 1.5.0.5 (X11/20060728)
MIME-Version 1.0
To grass-bugs@intevation.de
Cc gruber@slf.ch, Glynn Clements <glynn@gclements.plus.com>, grass-dev <grass-dev@grass.itc.it>
Subject Re: [bug #2790] (grass) r.bilinear result is rounded to .5
References <20060824171606.538201006CB@lists.intevation.de>
In-Reply-To <20060824171606.538201006CB@lists.intevation.de>
Content-Type text/plain; charset=ISO-8859-2
Content-Transfer-Encoding 8bit
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-4.907 tagged_above=-999 required=3 tests=[AWL=0.093, BAYES_00=-5]
X-Spam-Level
Glynn Clements via RT napisa³(a):

> That level of error can easily be attributed to differences in
> rounding. It's by no means clear which of the two (if either) is more
> accurate.

OK, just double-checkicking. Closing bug. Thanks!

Maciek


Thu, Aug 24 2006 21:33:46    Status changed to resolved by msieczka  
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