[OSRS-PROJ] PROJ tasks and routines

[Duncan Agnew]

Prompted by some recent comments, especially those by Gerald Evenden,
I'd like to offer one view of what PROJ does, and how those functions
might be embodied in software--recognizing that what may be easiest to use,
is not always easiest to learn. I hope this will provoke reactions, and
perhaps some ideas that can be used in any future documentation (the ones
here are available for use, if anyone likes them).

	First, definitions: PROJ is the package, proj and cs2cs are
the routines in it.

I would say that there are three different, though related, activities
covered by PROJ:

A. Projections

	This looks like:

                      ______________________
	             |                      |
	lat/long <===|  projection routine  |====> x/y
	             |______________________|

where the box can go either way. What is inside the box is software 
implementing a set of equations: the important point is that these are
nothing but mathematics, 99% devoid of empirical content about the Earth
(the 1% is that the 1/flattening is << 1).

B. Grids

	This looks like:

                      ______________________
	             |                      |
	lat/long <===|  projection routine  |====> x/y
	             |______________________|

where what is inside the box is software implementing a set of equations. If
this sounds a lot like (A), that is because it is, and with the same
equations (almost always). But there is a crucial difference, which Cliff
Mugnier has pointed out on a number of occasions: the parameters in
these equations (and sometimes the equations themselves) are set "by
definition" either by a government or a commercial firm. There is a
bit more empirical information here (specifically, ellipsoid parameters),
but mostly a lot of semi-arbitrary constants.

(And, there is also the difference that in (A) the x/y are usually in units
to be plotted (eventually), in (B) the x/y is, by design, close to actual
distance on the ellipsoid).

What is also set by legal definition is the *kind* of lat/long that
is legitimate to feed into the box: that is, the datum. This leads to
confusion with the next item:


C. Datums

	This looks like:

                      ________________________________
	             |                                |
	lat/long <===|  datum-transformation routine  |====> lat/long
	             |________________________________|

where now the software implements a quite different set of equations--in most
cases pretty simple ones (a rotation and translation, aka "7-parameter
Helmert") but occasionally more complicated (NAD27 <=> NAD83).  But the
parameters used are *very* empirical: somebody had to go out and make
measurements for each datum transformation, though once these measurements
are made it may also be the case that certain datum transformations are
taken as being defined. In thinking about the amount of empirical information
involved, it might help to realize that the parameters for
a datum transformation can be wrong, while a grid or projection can't
be: they are what they are. I happen to live in a place where the
datum transformations become wrong over time, because of plate tectonics.
(Of course the implementation of a grid can be wrong, but not the definition).

	Because grid definitions include a statement that the lat/long
should be "XXX Datum" I think there is a tendency to mix up (B) and (C),
and hence (A) (B) and (C), even though (C) is quite different from (A) and
(B). I think this tendency has influenced the evolution of the package--and
it has to be said that being able to do (B) and (C) fills a real need not
covered by other free projection software (eg, the Generic Mapping Tools).

	It would keep these distinctions cleaner if proj (the routine)
did (A) [and hence (B), depending on the parameters set] while there
was a program called (say) datumtr for doing (C): then one could use
pipes to get any transformations needed: eg, SPCS on NAD27 to SPCS on NAD83
would be (schematically)

    cat SPCS27 | proj -inverse | datumtr -NAD27to83 | proj -forward > SPCS83

What has happened instead is the cs2cs has combined both (B) and (C); certainly
having both is valuable, and I appreciate that what has been done is done,
but I would urge that whatever is done to cs2cs to allow it specifically
to perform the combined (B) and (C), not be added to proj, which is thus
left simpler for the people who just want to do (A). Mission creep can be
insidious.

	I would also argue that proj should continue to implement only
lat/long <==> x/y, leaving the various 3-d transformations out.
Since cs2cs handles triples, this could go there--but really, it might
be better to make this a separate routine, since it is a function of 3
variables rather than 2. Again, it's a choice between ease of use and
separate routines for separate activities. (I'd also note that the
XYZ-to-ellipsoid transform, done accurately over a wide range of ellipsoid
heights, is something that has attracted a lot of attention in the geodetic
literature recently, so some thought would be needed about the appropriate
algorithm).

	Hope this seems right, or at least worth discussing, to others.

Duncan Agnew
dagnew at ucsd.edu

----------------------------------------
PROJ.4 Discussion List
See http://www.remotesensing.org/proj for subscription, unsubscription
and other information.