[GRASS5] [bug #870] (grass) r.proj problem: boxes appearing
grass-bugs at intevation.de
Wed Dec 12 10:22:07 EST 2001
this bug's URL: http://intevation.de/rt/webrt?serial_num=870
(dear RT bugtracker)
I am sending this to the bug tracker as the information shall
To repeat the bug description: the maps generated by r.proj
- might be shifted by 0.5 to 1 pixel (not sure!)
- 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.
Now more discussion:
On Wed, Nov 28, 2001 at 02:40:32PM +0100, Morten Hulden wrote:
> On Wed, 28 Nov 2001, Markus Neteler wrote:
> > > Are you running r.proj on a _shaded_ map? I don't think any of the
> > > interpolation methods will give good results on anything else than a pure
> > > elevation map.
> > no - of course I used the elevation map. The aspect I only use to verify
> > the result as it is often quite useful to identify artefacts.
I should explain what I did:
- r.proj'ed the elevation map
- run r.slope.aspect on the result
- displayed it, finding the artefacts
- sending *this* snapshot to you. The color table of
the DEM doesn't show much, but d.what.rast seems to
confirm that boxes are there.
> > Sorry: I didn't want to blame you for anything! I was pretty sure that
> > I am dealing with a long-term problem introduced by the original
> > author. However, you are currently the only person knowing much
> > about this module :-)
> Not what i meant. No offence taken. I just wanted to make sure you are
> aware that the interpolation methods subroutines in r.proj are separate
> from the initial trimming and adjusting in the main routine, and in
Ah - o.k.
> 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?
> When I pointed out that 'nearest' is the only acceptable method to one
> person earlier, he replied that man pages say that bipolar and cubic
> should give better results. Indeed, they take into account more
> surrounding cells, so in _theory_ they should be better at interpolating.
> But in practice we don't want interpolation of coast lines and of the
> shape of lakes - we want familiar looking coasts and lakes. In general,
> interpolation around a natural flat surface (sea level, lakes) gives
> undesirable results.
> Maybe disabling the other methods is too drastic. After all they may have
> their uses. But people should be aware, and perhaps man page should be
> fixed not to mislead them. I can't argue against theory, what I say is
> based on what I leared from testing.
I suggest that I ask someone with a GRASS running and keep you posting.
Do you follow the "grass5" list? Otherwise I can cc to you.
> > Perhaps I try again with a synthetic map, a tilted plane and a
> > sine curve composition.
> I have never seen artifacts like the ones you show, but I'm very
> interested to hear you results.
> In plain language what r.proj does after all the initial trimming and
> adjusting is this
> for each cell in the output location:
> -projects the center of the cell into the input location
> -finds the value of the cell in the input map into which the
> projected point fell (if you use the default 'nearest neighbor' method)
> -sets the value of the cell in the output map to that value
> So what can go wrong?
> Great difference in resolution between input and output map may result in
> some more or less random cell values. But setting the current region to
> match the input map's resolution before projecting should fix that. And
> you say you did this already, so I just don't know.
> Another thing, similar in effect but different reason, is that because of
> the narrowing and divergence of meridians in some projections, we may hit
> cases where the center of many different cells in the output location
> projects into the same cell of the input map. The result is that many
> adjacent cells in the output map gets the same value.
> So these two cases, resolution difference and projection difference is
> what I come up with. Neiter one is really a bug, but rather a result of
> the way r.proj works, and restrictions that are inherent to the theory.
> Please let me know what your synthetic map tests say.
> best regards
We need more volunteers to test/identify the problem.
What to do: re-project an elevation map between two LOCATIONS in
different projections. Generate the aspect map with r.slop.aspect,
inspect it for any strange systematic error.
Thanks, Morten, for your comments!
--- Headers Follow ---
>From neteler at itc.it Wed Dec 12 16:22:06 2001
Return-Path: <neteler at itc.it>
Delivered-To: grass-bugs at lists.intevation.de
Received: from mail.intevation.de (aktaia [18.104.22.168])
by lists.intevation.de (Postfix) with ESMTP id 18A7613A02
for <grass-bugs at lists.intevation.de>; Wed, 12 Dec 2001 16:22:06 +0100 (CET)
Received: from camelot.itc.it (camelot.itc.it [22.214.171.124])
by mail.intevation.de (Postfix) with ESMTP id A599B1B77C
for <grass-bugs at intevation.de>; Wed, 12 Dec 2001 16:22:05 +0100 (CET)
Received: from artemide.itc.it (artemide [10.0.10.10])
by camelot.itc.it (8.11.3/8.11.3) with ESMTP id fBCFLwd23895;
Wed, 12 Dec 2001 16:21:58 +0100 (MET)
Received: from thuille.itc.it. (thuille [10.40.0.110])
by artemide.itc.it (8.11.3/8.11.3) with ESMTP id fBCFLs712189;
Wed, 12 Dec 2001 16:21:55 +0100 (MET)
Received: (from neteler at localhost)
by thuille.itc.it. (8.11.6/8.11.2) id fBCFLqx04301;
Wed, 12 Dec 2001 16:21:52 +0100
Date: Wed, 12 Dec 2001 16:21:52 +0100
From: Markus Neteler <neteler at itc.it>
To: Morten Hulden <morten at ngb.se>
Cc: grass-bugs at intevation.de
Subject: r.proj problem: boxes appearing
Message-ID: <20011212162152.A4293 at itc.it>
References: <20011128114509.A23640 at itc.it> <Pine.LNX.4.33.0111281350200.1197-100000 at tor.ngb.se>
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <Pine.LNX.4.33.0111281350200.1197-100000 at tor.ngb.se>; from morten at ngb.se on Wed, Nov 28, 2001 at 02:40:32PM +0100
X-Spam-Status: No, hits=0 required=5 tests=
-------------------------------------------- Managed by Request Tracker
More information about the grass-dev