[GRASSLIST:5896] Re: Observations about r.proj

[Glynn Clements]

Victor Wren wrote:

> I've been playing around with r.proj for a couple of days, now.  I've noticed 
> some things that explain unusual behavior that I was seeing in projected DEM 
> maps.  I was noticing that they didn't meet up at the edges quite right after 
> projection.  I figured out what was going on when I decided to see if I could 
> find a simple way to shrink maps down if the -n flag is necessary.  Using 
> g.region rast={map} zoom={map} was not yielding a map with dimensions equal 
> to the source map (being that both maps were UTM, they should have been).  It 
> seemed to grow a cell or two in all directions.

r.proj explicitly grows the region by two cells in each direction, to
allow for interpolation.

> What I think is happening is that using any interpolation method will cause 
> boundary effects, where the edges are being interpolated with nulls 
> (interpreted as zero?).  This has the effect of creating cells where there 
> were none before (if the region is larger than the source map, and the -n 
> switch is used), but more importantly, it causes distortions at the edge of 
> any maps, even when the -n switch isn't used.  I've decided for my 
> application, bilinear interpolation was unnecessary, but in a general case it 
> might not be (such as projecting from geo coordinates to UTM)
> 
> Is there a way to overcome this?  I'm a mathematical idiot, but it seems to 
> me that if any of the cell values in the interpolation group is null (the 
> four cells of the bilinear group, or the 16 cells of the cubic group), the 
> interpolation should not be done, or perhaps should be "faked" by repeating 
> the edge cells out until a legitimate group can be created, which may be no 
> more valid, but at least will keep the edge from dropping away).  If the 
> center cell is a null, does it get filled in by interpolated data?  My 
> experience would suggest that it does (that would also distort data in 
> adjacent that is depending on that null cell as one of its bilinear or cubic 
> group).  Should "no-data" be treated as zero for the purpose of 
> interpolation?  I can think of arguments both ways.  Does this matter to 
> anybody?

AFAICT, the cubic interpolation code returns null if the centre cell
is null, and replaces null cells by the contents of the centre cell.

This looks like a fudge; personally, I think that the result should be
null if any of the cells used by the interpolation are null. (Either
that, or there should be separate interpolation algorithms for each
possible combination of null/non-null cells).

-- 
Glynn Clements <glynn.clements at virgin.net>