[GRASS-user] UTM concepts

[Glynn Clements]

Brent Wood wrote:

> The issues you describe apply to any reprojection, both on the fly or 
> static. If there is no advantage (a better result) to using the static 
> conversion to a common projection, then why not support an on the fly 
> facility which does exactly the same thing & gives the same result, but 
> makes things easier for the user?

Where does the on-the-fly reprojection get the interpolation method
from?

This becomes more of an issue if we extend r.proj to support more
complex resampling algorithms, e.g. the use of aggregates like with
r.resamp.stats.

Right now, the issues aren't particularly noticable, mostly because
the explicit reprojection facilities are so primitive. The more that
GRASS improves in this area, the more significant the issues become.

Also, it still doesn't address the implementation aspects, i.e. that
you either need to read the entire source map into memory (which isn't
practical for large maps) or make an intermediate copy in a format
which is more appropriate (GRASS' native format isn't suited to
anything other than row-by-row access).

> By your argument, if on the fly reprojection via (say) proj4 is a bad 
> idea & should not be supported, then the same concerns are valid for 
> static reprojections using proj4, being identical "leaky abstractions" 
> (nice phrase :-), and therefore GRASS should not facilitate any such 
> reprojection?

It's much easier to control the reprojection process if it's performed
as an explicit step. With on-the-fly reprojection, every command which
reads a map would need to accept any parameters required for
reprojection (currently this amounts to method=nearest/bilinear/cubic,
but it would be nice to improve upon that).

-- 
Glynn Clements <glynn at gclements.plus.com>