Details Ticket 3100


Comment | Reply | Take | Open


Serial Number 3100
Subject r.proj is making the asymmetric integer truncation error
Area grass6
Queue grass
Requestors werchowyna@epf.pl
Owner none
Status resolved
Last User Contact Wed Apr 6 18:19:47 2005 (3 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Wed May 11 15:20:04 2005 (3 yr ago)
Created Sat Mar 19 21:08:37 2005 (3 yr ago)

Transaction History Ticket 3100


Sat, Mar 19 2005 21:08:37    Request created by guest  
Subject: r.proj is making the asymmetric integer truncation error

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

This report is based on (edited) Frank Warmerdam comments on my observations
when comparing the output of gdalwarp and r.proj.

According to Frank:

In comparing the gdalwarp and the rproj results, it seems that r.proj is making
the classic asymmetric integer truncation error.

If you look at the zoom in the top left corner of the gdalwarp
and r.proj results you will see that all the top and left edges of the
r.proj output is "doubled".  This typically occurs in warpers that use
simple integer casting from floating point. If you do:

  int xi;
  double x;

  x = <some calculation>
  xi = (int)x;

You get the problem that all values of x between -1.0 and 1.0 end up
being converted to 0.  That is, values between 0 and -1.0 are treated as
having come from pixel 0 in the source image.  This generally results in
the class doubling of the top and left most edge of the raster. 

The normal fix is to use floor() as in:

  int xi;
  double x;

  x = <some calculation>
  xi = (int)floor(x);

though other solutions may get the same result more efficiently.

Maciek

P.S.
There is some more detailed information related in gdal and grass mailing lists
archives; look for topic "r.proj and gdawarp give differernt results".
Wed, Apr 6 2005 18:19:47    Mail sent by mneteler  
This was fixed by Morten Hulden in CVS.

Please try again and report.

Markus
Wed, Apr 6 2005 22:43:43    Mail sent by werchowyna@epf.pl  
Return-Path <werchowyna@epf.pl>
Delivered-To grass-bugs@lists.intevation.de
Message-ID <010201c53ae9$6e8ca830$1fd21d3e@eustahiush>
From "Maciek Sieczka" <werchowyna@epf.pl>
To "Markus Neteler via RT" <grass-bugs@intevation.de>
References <20050406161947.3781A100167@lists.intevation.de>
Subject Re: [bug #3100] (grass) r.proj is making the asymmetric integer truncation error
Date Wed, 6 Apr 2005 22:40:07 +0200
MIME-Version 1.0
Content-Type text/plain; format=flowed; charset="iso-8859-2"; reply-type=original
Content-Transfer-Encoding 7bit
X-Priority 3
X-MSMail-Priority Normal
X-Mailer Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE Produced By Microsoft MimeOLE V6.00.2900.2180
X-Antivirus avast! (VPS 0513-1, 2005-03-30), Outbound message
X-Antivirus-Status Clean
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Markus

Sure I have tried it. Actually I also reported about the second bug in 
r.proj (the systematic erroreous shift) to Morten and helped him with 
testing and comparing to reference gdalwarp results. Now r.proj gives 
exactly the same output as the gdalwarp whith appropriate -te switch used. 
There is still some difference if we don't give the apriori -te for 
gdalwarp. However it seems unavoidable due these two methods simply somewhat
differ.

Best
Maciek

----- Original Message ----- 
From: "Markus Neteler via RT" <grass-bugs@intevation.de>
To: <werchowyna@epf.pl>
Sent: Wednesday, April 06, 2005 6:19 PM
Subject: [bug #3100] (grass) r.proj is making the asymmetric integer 
truncation error


> This was fixed by Morten Hulden in CVS.
>
> Please try again and report.
>
> Markus
>
> -------------------------------------------- Managed by Request Tracker
> 


Wed, May 11 2005 15:20:04    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