[GRASS-user] UTM concepts

[Brent Wood]

Hi Matt,

Apologies for the top post, but I figure I won't trim Matt's (well 
thought out) comments, nor require others to scroll through the "long 
rant"  :-)

The points raised are perfectly valid in theory, but I believe fall 
short in practice.

I have data from NATICE in a custom polar projection, ditto ADD data, 
then GEBCO lat/long, GPS data, add in NIWA custom mercator data & LINZ 
NZTM/NZMG data.

The result (in GRASS, at least as I understand it) of applying datum 
shifts & reprojecting these into some different projection to use with 
GRASS in a single map set is identical to the result of the proj4 based 
on-the-fly reprojection.

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?

Reprojecting  data using GRASS (or most other GIS systems I've looked 
at) does not require users to consider any of the issues you've raised, 
thus there is no real difference to an on the fly reprojection, so while 
your comments on reprojection issues are valid, I don't see their 
relevance to a discussion comparing static & on the fly capabilities 
when both are using the same libraries & give the same result.

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?

cheers,

  Brent




Matthew Perry wrote:
> 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