[GRASS-user] UTM concepts

[Matthew Perry]

Brent,

On 10/8/06, Brent Wood <b.wood at niwa.co.nz> wrote:
>
> 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.
>

If data is created in one projection, there is no guarantee that any
on-the-fly reprojection algorithm can accurately represent that data
in another projection.

Having struggled with this issue for some time, I believe the idea of
on-the-fly reprojection to be merely a nice idea; what Joel Spolsky
refers to as a "Leaky Abstraction"
(http://www.joelonsoftware.com/articles/LeakyAbstractions.html). The
abstraction of on-the-fly reprojection makes it easier to *think*
about the problem but sometimes you simply have no choice (the
abstraction "leaks") and you must deal with the fundamental errors of
reprojection.

Two good examples:

First, for raster data. Lets say you have a raster dataset where each
pixel represents a physical, measurable count; for example each pixel
contains the number of humans who live in the geographic space
represented by the pixel. If you reproject that data, the actual space
covered by a pixel changes! Any reprojection routine will simply
recalculate the value of each pixel based on the chosen resampling
algorithm. If you take a population raster and reproject it, there is
a very little chance that the sum of the overall raster cells will be
maintained... By reprojecting you have altered your dataset and
changed the overall population!

Second, for vector data. If, in the original projection of the
dataset, a line is perfectly straight,  that the line may be
represented by only two vertices (beginning and end). Now you want to
reproject that dataset. In the new projection, this line is no longer
straight but a curve. Since most reprojection alogrithms merely
reproject vertices, the begining and end points of the line will be
placed properly but the curve between them will not; it will continue
to be a straight line.

There are solutions to either problem. For the population raster one
might normalize the reprojected raster by the ratio of the difference
in overall population with the original dataset, preserving the
overall sum. For the vector dataset you can densify the line segment,
adding more vertices before you reproject in order to preserve the
shape of the line.

But each solution is dataset-specific and neither can be solved by a
generic projection algorithm. The abstraction is leaky; you must delve
into the lower-level details in order to obtain the correct result.

So for most datasets, a generic reprojection algorithm may work. I use
them all the time when displaying data through mapserver. But for
others, particularly in cases where analysis is more important than
rendered maps, on-the-fly reprojection may not be appropriate.
Abstracting that fact away from the user means that the user can make
mistakes without knowing it. I much prefer the GRASS framework which,
at the very least, forces you to think about these issues before you
commit to such a mistake!

Sorry for the long rant :-p
-- 
Matthew T. Perry
GIS Analyst / Software Engineer
National Center for Ecological Analysis and Synthesis (NCEAS)
work: perry at nceas.ucsb.edu
web: http://www.perrygeo.net