[GRASS-user] UTM concepts

[Matthew Perry]

Brent,

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

For most cases (like 95%) a simple reprojection is all thats needed.
Somehow or other, I always seem to run into that 5%. So for me it's
not just theory :-)

> 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?

Good point. GRASS still allows you to perform a faulty projection
(just like any application using proj4), It just won't do it on the
fly.

While in some cases this can be considered a major pain, I actually
appreciate jumping through those hoops because it forces me to think
about the process, perform the reprojection and (hopefully) validate
the results. That, I suppose, was my main point.

If the program handles it on the fly, the whole process becomes a
black box and lazy users (like myself!) would just assume everything
went perfectly without realizing some of the assumptions that had been
made on their behalf.

I taught GIS labs for a few semesters as a grad student and witnessed
the transition from ArcInfo command line-based courses to ArcGIS
GUI-based courses. The students taught in the GUI environment were
more productive and worked faster. But they tended to make some pretty
major fundamental errors because they just assumed the output was
correct. The command line was much less forgiving and forced students
to do their research. Accuracy at the expense of productivity, i
guess!
-- 
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