[GRASS5] [bug #3100] (grass) r.proj is making the asymmetric integer truncation error

[Request Tracker]

this bug's URL: http://intevation.de/rt/webrt?serial_num=3100
-------------------------------------------------------------------------

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

-------------------------------------------- Managed by Request Tracker