coordinates vs projections

[Gerald I. Evenden]

>Date: Wed, 19 Jan 1994 15:53:47 -0500
>From: mike camann <camann at pick.uga.edu>
>To: grassu-list at max.cecer.army.mil
>Subject: Re:  coordinates vs projections
>
	...
>>Transverse Mercator is one of hundreds.
>
>Sorry for the confusion.  I capitalized LOCATION in an attempt to make
>clear that I meant location in a GRASS sense: the subdirectory
>$LOCATION.  When creating a new LOCATION, GRASS expects information
>about the projection that will apply to that LOCATION.  And yes, it
>requests that you select from one of the following *projections*:
>
>	x,y (for imagery and other unreferenced data)
>	UTM
>	State Plane
>	Latitude-Longitude
>	other projection         (emphasis is mine)
>	      ^^^^^^^^^^
>
>The menu header *does* refer to them-- properly-- as coodinate systems,
>but the final item lumps in a whole series of *projections* and
>whatever you choose from this list (including lat-lon) is stored in the
>DEFAULT_WIND file (under $LOCATION/PERMANENT) as the LOCATION's
>*projection*.  You can check this for yourself.  Yes, Jerry, I do find
>GRASS's behavior in this regard confusing.

I suspect that GRASS suffers from being sloppy in its nomenclature with
what many of us take for granted.  I *do not* like the use of the
equivalence of *projection* with *coordinate system*.  In my book,
a projection provides the transformation between coordinate systems.
For example, UTM is a coordinate system and a specialized use of
of Transverse Mercator that transforms data between geographic and
UTM coordinates.  It is unfortunate that we use UTM as an entry
in a list of "projections" when in fact, it is a specialized use
of a projection and *not* a projection per se.  But the world
abounds with contradictions.

>I'm sorry if I gave the impression that I don't know the difference
>between a coordinate system and a projection-- I do.

Good, but when I keep rereading your text, this distinction always
gets lost in my mind.

>>>1)  As near as I can tell, GRASS regards lat-lon as a *projection*.
>>>Furthermore, it seems to view lat-lon as a square projection, where
>all
>>>the grid lines intersect at 90 degrees.
>
>>Again, lat-lon is *not* a projection.  We are confusing a Plate Carree
>>projection with elemental definitions.
>
>I didn't say that *I* think lat-lon is a projection, I said that GRASS
>seems to think so, and I asked for clarification.  Again, look at the
>DEFAULT_WIND file in any $LOCATION/PERMANENT that was originally
>created with lat-lon coordinates.  Better yet, do g.region -p; it will
>tell you that the *projection* is lat-lon.  That is the term GRASS
>uses-- not a slip of the tongue on my part.  If you do g.region -p in a
>UTM LOCATION, it will say thet the projection is UTM.  Finally, try to
>run g.setproj.  It will confirm that the *projection* has already been
>set, when all that has actually been explicitly entered was the
>*coordinate system* at the time the LOCATION was created.  You can
>check this for yourself by creating a dummy LOCATION.

Again, it was difficult to separate what *you* thought and what
*GRASS* "thought".

It does appear, from what you say, that GRASS is obfuscating the
process.  But the general problem of projection selection and control
is a complex process when done properly.  In order to be "user
friendly," GRASS probably got terse and ended up frustrating your
attemps at creating something that did not fit in their pidgeon holes.

At the other end of the spectrum is proj, where complete control
is up to the user---including x-y units.  The down side is that the
user *has* to become more familiar with projection details.

>Michael Camann                          camann at dial.pick.uga.edu

We are probably not that far appart in concept, but the usual
problems of expression and semantics appear.

Gerald (Jerry) I. Evenden   Internet: gie at charon.er.usgs.gov
voice: (508)563-6766          Postal: P.O. Box 1027
  fax: (508)457-2310                  N.Falmouth, MA 02556-1027