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