[GRASS-user] UTM concepts

[Glynn Clements]

Brent Wood wrote:

> >> I'm trying to learn GRASS a second time and find myself struggling again
> >> with the basic issue of defining a region.
> >>
> >> I have a series of data sources with varying projections and extents
> >> covering the region I'm interested in.  I would like to work on a UTM
> >> projection with WGS84 datum for all analyses of this region, so would have
> >> to reproject and clip the original data sources to this standard.
> >>
> >> Since the region of interest covers several UTM zones, I don't understand
> >> how I should define the region for this project.  For instance, If I
> >> choose the UTM zone corresponding to the center of the region I'm
> >> interested in, how does one specify the limits of the region, considering
> >> that the data will span several (4) UTM zones?
> 
> This addresses my main (pretty much only!) gripe about GRASS. I suggest 
> that projections, etc are simply metadata describing a dataset. As such, 
> being forced to change all my data to one predefined projection/datum is 
> a significant inconvenience, which has largely precluded my making any 
> real use of GRASS.
> 
> I get data & updates from various institutes/repositories around the 
> world, in a variety of projections. I want to use these data as they 
> are, without requiring two complete sets (the GRASS reprojected copy & 
> the original) which requires on the fly reprojection.
> 
> GMT, QGIS, PostGIS and increasingly, UMN mapserver (the FOSS GIS tools I 
> use most) all support on the fly reprojection, so my workspace can 
> pretty much seamlessly overlay data stored in NZTM, NZMG, mercator, UTM, 
> lat/long and polar coordinate systems & projections.
> 
> Is there any plan to make GRASS less restrictive in the way it deals 
> with data covering the same region but in different projections? (Or 
> have I missed something & it has already been done?)
> 
> I assume the entire GRASS codebase is oriented around the 
> mapset/predefined region/datum/projection and that any shift from this 
> model would be a huge undertaking, but am wondering if supporting on the 
> fly reprojection has been considered at all?

I think that it's fair to say that it has been "considered", in the
sense that other people have previously expressed the same wish, and
the various obstacles to such a mechanism have been discussed.

Apart from Matthew Perry's comments about the problems with automatic
reprojection automatically turning meaningful data into garbage, there
are a couple of other major issues:

1. Selecting the resampling method. r.proj offers a choice of
nearest-neighbour, bilinear or bicubic interpolation. That isn't a
particularly wide choice, although it's better than nothing. Automatic
resampling would probably have to be limited to nearest-neighbour, as
the other algorithms are meaningless when the values are discrete
categories (rather than scalar values, e.g. elevation).

2. Complexity and efficiency. The automatic resampling which libgis
performs is limited to translation and scaling, with no rotation or
shear. This has the advantage that each output row corresponds to a
single input row. If you support arbitrary reprojection, an output row
corresponds to an arbitrary curve in the source coordinate system. 
Extracting the output row may require reading data from any number of
input rows; in the worst case, all of them, meaning that you need to
store the entire map in memory.

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