[GRASS5] [bug #870] (grass) r.proj problem: boxes appearing
neteler at itc.it
Thu Dec 13 05:08:56 EST 2001
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,
More information about the grass-dev