[GRASS5] [bug #870] (grass) r.proj problem: boxes appearing

[Markus Neteler]

On Wed, Dec 12, 2001 at 08:21:29AM -0800, Eric G. Miller wrote:
> On Wed, 12 Dec 2001 16:22:07 +0100 (CET), Request Tracker <grass-bugs at intevation.de> wrote:
> 
> > this bug's URL: http://intevation.de/rt/webrt?serial_num=870
> > -------------------------------------------------------------------------
> > 
> > Hi Morten
> > (dear RT bugtracker)
> > 
> > I am sending this to the bug tracker as the information shall
> > be recorded.
> > 
> > To repeat the bug description: the maps generated by r.proj
> >  - might be shifted by 0.5 to 1 pixel (not sure!)
> 
>    Projection introduces error.

yes, I know. But the map looks shifted which is too much error.
Again, perhaps someone can try as well.
I have to explain that I am working in two adjacent zones.
I have data for the same geographic location which are projected
to these two zones. My test was to re-project the elevation model
from the second zone to the first zone, then to overlay the
maps to see if any difference is present. For that I diff'ed with
r.mapcalc (showing expected projection errors appearing as distributed
numerical differences). Additionally I generated the aspect
maps which *seem* to show a sort of shift. 
 
To test r.proj, you need data for the same geographic location which are
projected into two different zones or projections.

> >  - the resulting maps contain a sort of "box structure" where 
> >    the information differs from the neighbors. This only applies to
> >    the border of the boxes, not the box contents. In a Gauss-Boaga
> >    (transverse mercator) projection the boxes are 500m x 500m
> >    everywhere like a chess-board.
> >    Note that this is only visible when generating an aspect map
> >    in case you re-project an elevation map.
> 
>    Are you certain the original data doesn't contain these artifacts?
>    Perhaps the projection exacerbated the effect?

I am very sure that the original data don't contain the artifacts.
If you try with a high-res DEM, you may get them as well.
 
> 
> > > And I have really never looked closely into what is happening 
> > > inside nearest.c, bipolar.c and cubic,c. Could be some obscure bug there, 
> > > but I will have to get my Grass burning again before I can do any further 
> > > programming. Right now not possible. Next year when I'm out of work 
> > > another story.
> > > 
> > > > > But I found out (by trial) that the only usable interpolation method is
> > > > > the 'nearest neighbor' (default). The two other methods (bipolar and
> > > > > cubic) tend to change ("interpolate") the coastlines and shape of lakes
> > > > > too much. 
> > > > 
> > > > Shall I disable them to prevent user confusion?
> 
> No.  Do not disable.  Bilinear/Cubic are appropriate for imagery.

O.k, we'll keep it.

Thanks for your comments,
Markus