[OSRS-PROJ] Datum Shifting
Gerald I. Evenden
gevenden at capecod.net
Tue Jul 4 20:41:41 EDT 2000
More detailed comments imbedded below.
Jerry Evenden and the Low Riders, Katie and Daisy May
gevenden at capecod.net http://www.capecod.net/~gevenden
----- Original Message -----
From: Frank Warmerdam <warmerda at home.com>
To: <osrs-proj at remotesensing.org>
Sent: Tuesday, July 04, 2000 10:33 AM
Subject: [OSRS-PROJ] Datum Shifting
> I am finally getting around to incorporating datum shifting support into
> PROJ.4, and I would be interested in some feedback on approaches.
A hypercritical note here. We are talking about the PROJ.4 library system.
> Currently the PROJ.4 access can be summarized in via the API:
> PJ *pj_init(int argc, char **argv)
> projUV pj_fwd(projUV val, PJ *proj)
> projUV pj_inv(projUV val, PJ *proj)
> void pj_free(PJ *proj)
> Note that it is only support translation back and forth between a
> and geodetic (lat/long) coordinates. There is no support for elevations,
> or for translating between different ellipsoids, or datums.
Correct! PROJ.x system is purely designed for cartographic projection
Same as NMD's GCTP.
> I propose the following changes to the coordinate system definitions:
> o Add a +towgs84=a,b,c[,d,e,f,g] option for providing the 3 or 7
> relationship between this coordinate systems datum, and WGS84.
> o Adding a +datum=<datumname> option which will basically lookup the
> in an internal table, substituting the +towgs84= and the ellipse
> that is contained in the table.
> o Adding a +ld[id] command option for listing the datum table with
> in a manner similar to the handling of ellipsoids and projections.
Other than supplying the ellipsoid parameters, datums have nothing to do
cartographic projections. I suggest adding the above to PROJ.4 is counter
the purpose of the package.
> o Adding +proj=latlong as a legal "projection" meaning that the
> are in geodetic coordinates rather than a projection system.
This one makes no sense to me. Dummy argument?
> We also need a way of driving coordinate system to coordinate system
> from the command line. I torn between extending the ``proj'' command with
> some methodology of defining a second coordinate system, or implement a
> command which operates coordinate system to coordinate system. Perhaps a
> proj2proj command or something like that. I am open to suggestions on
You already have it. It is called a "pipe." See other emails.
> I propose to implement several new API entry points, while leaving the
> current API essentially unchanged. The only changes to the current API
> would be that pj_init would understand the new options (+towgs84, +datum)
> and would store the additional information in the PJ structure.
Strongly disagree as the suggested data has nothing to so with the process
of cartographic projection.
> The new API entry point would likely be:
... deleted as nothing to do with cartographic projection
> function call overhead.
> Unrelated to the datum shifting changes, I also propose to add a variation
> pj_init() which takes a single string argument with the coordinate system
> arguments, and will take care of parsing it into internal tokens in the
> way. Perhaps this could be pj_init_1().
Not sure what you're talking about.
You have two basic problems: 1) cartographic projections and 2) datum
All the factors involved are very nicely separated and can be similarly
with separate pieces of software. Problem 1 seems to be niecely solved and
problem 2 seems easily solvable in a similar manner. Why throw everything
into one stew pot? It just makes the stirring more difficult.
OSRS PRoject PROJ Discussion List
To Subscribe: send a message to majordomo at remotesensing.org with 'subscribe osrs-proj' in the body
To Unsubscribe: send a message to majordomo at remotesensing.org with 'unsubscribe osrs-proj' in the body
To Report Problems: send a message to owner-osrs-proj at remotesensing.org
More information about the Proj