Date: Wed, 19 Jan 1994 15:53:47 -0500
From: mike camann <camann@pick.uga.edu>
To: grassu-list@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, whereall
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@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@charon.er.usgs.gov
voice: (508)563-6766 Postal: P.O. Box 1027
fax: (508)457-2310 N.Falmouth, MA 02556-1027