Wed, Dec 12 2001
16:22:06
|
|
Request created by neteler@itc.it
|
|
Return-Path |
<neteler@itc.it>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Wed, 12 Dec 2001 16:21:52 +0100
|
From |
Markus Neteler <neteler@itc.it>
|
To |
Morten Hulden <morten@ngb.se>
|
Cc |
grass-bugs@intevation.de
|
Subject |
r.proj problem: boxes appearing
|
Message-ID |
<20011212162152.A4293@itc.it>
|
References |
<20011128114509.A23640@itc.it> <Pine.LNX.4.33.0111281350200.1197-100000@tor.ngb.se>
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Disposition |
inline
|
User-Agent |
Mutt/1.2.5i
|
In-Reply-To |
<Pine.LNX.4.33.0111281350200.1197-100000@tor.ngb.se>; from morten@ngb.se on Wed, Nov 28, 2001 at 02:40:32PM +0100
|
X-Spam-Status |
No, hits=0 required=5 tests= |
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!)
- 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
> bordwalk.c.
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
> Morten
>
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!
Markus
|
|
Wed, Dec 12 2001
17:21:25
|
|
Mail sent by egm2@jps.net
|
|
Return-Path |
<egm2@jps.net>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Wed, 12 Dec 2001 08:21:29 -0800
|
From |
Eric G.Miller <egm2@jps.net>
|
To |
Request Tracker <grass-bugs@intevation.de>
|
Cc |
grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #870] (grass) r.proj problem: boxes appearing
|
Message-Id |
<20011212082129.7ce6b2f7.egm2@jps.net>
|
In-Reply-To |
<20011212152207.077E313A12@lists.intevation.de>
|
References |
<20011212152207.077E313A12@lists.intevation.de>
|
X-Mailer |
Sylpheed version 0.6.5 (GTK+ 1.2.10; i386-debian-linux-gnu)
|
X-Face |
$}3V+uswm7Z!;4n|~VUONRE7}?M:)9EanJ+VSIbuLet]@F^~Fm^4{#&Ll9c[VT^L%tpnKL( y>h}_QRih0|V9"B(!y0Y.2R{i'sBKFXW+bn8(pJ2x]Te{Zqd^[YTj#e99&^K(5Wkp7Ie<d-V)**5%% B$08X%]!>l@&:_W<-CPN*&>qczh^'o
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=US-ASCII
|
Content-Transfer-Encoding |
7bit
|
X-Spam-Status |
No, hits=1 required=5 tests=FROM_ENDS_IN_NUMS |
On Wed, 12 Dec 2001 16:22:07 +0100 (CET), Request Tracker <grass-bugs@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.
> - 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?
> > 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.
--
Eric G. Miller <egm2@jps.net>
|
|
Thu, Dec 13 2001
11:09:00
|
|
Mail sent by neteler@itc.it
|
|
Return-Path |
<neteler@itc.it>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Thu, 13 Dec 2001 11:08:56 +0100
|
From |
Markus Neteler <neteler@itc.it>
|
To |
grass5@grass.itc.it
|
Cc |
grass-bugs@intevation.de
|
Subject |
Re: [GRASS5] [bug #870] (grass) r.proj problem: boxes appearing
|
Message-ID |
<20011213110856.D5168@itc.it>
|
Mail-Followup-To |
grass5@grass.itc.it, grass-bugs@intevation.de
|
References |
<20011212152207.077E313A12@lists.intevation.de> <20011212082129.7ce6b2f7.egm2@jps.net>
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Disposition |
inline
|
User-Agent |
Mutt/1.2.5i
|
In-Reply-To |
<20011212082129.7ce6b2f7.egm2@jps.net>; from egm2@jps.net on Wed, Dec 12, 2001 at 08:21:29AM -0800
|
X-Spam-Status |
No, hits=0 required=5 tests= |
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@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
|
|
Thu, Dec 13 2001
15:14:33
|
|
Request created by neteler@itc.it (as #871)
|
|
Return-Path |
<neteler@itc.it>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Thu, 13 Dec 2001 15:14:22 +0100
|
From |
Markus Neteler <neteler@itc.it>
|
To |
Morten Hulden <morten@ngb.se>
|
Cc |
grass-bugs@intevation.de, grass5 developers list <grass5@grass.itc.it>
|
Subject |
Re: r.proj problem: boxes appearing
|
Message-ID |
<20011213151422.E5660@itc.it>
|
Mail-Followup-To |
Morten Hulden <morten@ngb.se>, grass-bugs@intevation.de, grass5 developers list <grass5@grass.itc.it>
|
References |
<20011212162152.A4293@itc.it> <Pine.LNX.4.33.0112131145080.15636-100000@tor.ngb.se>
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Disposition |
inline
|
User-Agent |
Mutt/1.2.5i
|
In-Reply-To |
<Pine.LNX.4.33.0112131145080.15636-100000@tor.ngb.se>; from morten@ngb.se on Thu, Dec 13, 2001 at 11:53:35AM +0100
|
X-Spam-Status |
No, hits=0 required=5 tests= |
On Thu, Dec 13, 2001 at 11:53:35AM +0100, Morten Hulden wrote:
>
> Hi Markus,
>
> this is not on the artifacts but on the 1-pixel shift:
>
>
> On Wed, 12 Dec 2001, Markus Neteler wrote:
>
> > - might be shifted by 0.5 to 1 pixel (not sure!)
>
> I suggested a fix for this, Markus. Did you try it?
Hi Morten,
sorry, I did not try (at time in Germany away from my data).
I have been looking at that code portion and was not sure
about it (the confusing index).
I will apply the bugfix now.
> > In r.proj/cmd subroutines nearest.c (and bipolar.c and cubic.c) change
> > the lines
>
> > row = (int) (*row_idx + 0.5);
> > col = (int) (*col_idx + 0.5);
>
> > to
>
> > row = (int) (*row_idx);
> > col = (int) (*col_idx);
>
>
> > If this helps, of course the correct fix would be to delete the lines
> > from the subroutines altogether, and make the type cast in main.c
> > instead, and declare row_idx and col_idx as integers. (row_idx and
> > col_idx are not used as floats anywhere, so why declare them as such.
> > but changing them requires changes in function declarations and
> > r.proj.h as well, so go for the easy test above first)
>
>
> I am very sorry but I cannot get my grass installation to work so right
> now I can't test it myself, though I would really like to get it going
> again.
>
> But I have very little time to play with the installation process. How do
> you get the socket-driver to work? Shouldn't there be a makesockets.sh
> script included somewhere?
The socket driver is default and plug-and-play nowadays. Do
you face problems to get it running?
Markus
|
|
Thu, Dec 13 2001
23:51:16
|
|
Comments added by alange
|
|
Hi 2 all,
i must admit that i did not follow this discussion very closely.
But i can report that i used r.proj several times to project DEMs from lat/lon
to Gauss Krueger (and other projections), but never noticed any artifacts.
I always used nearest neighbour interpolation.
And i used r.proj to inverse project from laea (lambert azimuthal equal area)
to lat/lon and gauss krueger. No artifacts too.
But it could be some bug that surfaces only with certain types of data.
Or it could be something that is somehow hidden inside the data.
Just to report, perhaps someone is able to investigate further.
Andreas |
|
Mon, Dec 17 2001
10:11:25
|
|
Request 871 merged into 870 by egmiller (as #871)
|
|
Wed, Feb 27 2002
05:01:09
|
|
Mail sent by egmiller
|
|
Are we satified that this isn't a bug? |
|
Fri, Mar 22 2002
09:52:39
|
|
Mail sent by mneteler
|
|
|
Fri, Mar 22 2002
09:52:44
|
|
Status changed to resolved by mneteler
|
|