[GRASS-user] UTM concepts

[Dylan Beaudette]

On Monday 09 October 2006 02:56, Glynn Clements wrote:
> 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.

Seb and others:

This is a great example of one of the ways in which the GRASS approach really 
shines (so shiny in fact that it hurts when you first encounter it!). Knowing 
your data, the limitations of your data (format, projection, etc,), and the 
steps needed to move from start to finish all contribute to the overall 
quality of the analysis. Others have made excellent points on the issues 
associated with reprojection-on-the-fly , and I would only like to add that I 
have seen numerous cases where this _feature_ has contributed to an overall 
lack of understanding with respect to spatial operations. Furthermore, any 
subsequent analysis that these un-named people have attempted with their 
mishmash of projections failed without a clear error message suggesting why.

In summary, take the time to get familiar with projections and coordinate 
systems, along with the steps needed to convert between them. I guarantee 
that it will be time well spent.

Cheers,


-- 
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341