[OSRS-PROJ] PROJ tasks and routines

[Paul Selormey]

Hello Duncan,
Thanks for the summary. It is very informative, just took a print and
will add it to my Proj4 file :-)

Best regards,
Paul.

----- Original Message -----
From: "Duncan Agnew" <agnew at bilby.ucsd.edu>
To: <osrs-proj at remotesensing.org>
Cc: <agnew at bilby.ucsd.edu>
Sent: Saturday, March 08, 2003 12:08 AM
Subject: [OSRS-PROJ] PROJ tasks and routines


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

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