[Proj] The world of ECEF aka geocentric coordinates

[Clifford J Mugnier]

I personally find the Wiki stuff useless and misleading.  The proper reference is Bomford's Geodesy (Editions 1 thru 4), and not the other trivia listed at the end.  The term ECEF is new-age baloney.  The Geocentric Coordinate System is the original and decades-old terminology recognized in the classical literature.  The notation used in the Wiki equations is just more gobbledygook, as Bomford established the proper (and world-wide recognized) notation about 50 years ago.  As if Wiki is entitled to ignore (?) the ellipsoid normal terminated by the semi-minor axis?  The term "spheroid" is further glaring evidence of classical geodetic ignorance.  That noun is only used with an ellipsoid that has a specific datum with an associated geoid.  Applicable to OSGB36 and WGS84, but certainly not to most classical datums found throughout the world.
 
C. Mugnier
LSU

________________________________

From: proj-bounces at lists.maptools.org on behalf of Karney, Charles
Sent: Fri 30-Jan-09 15:10
To: geraldi.evenden at gmail.com; PROJ.4 andgeneral Projections Discussions
Subject: Re: [Proj] The world of ECEF aka geocentric coordinates



> From: Gerald I. Evenden [geraldi.evenden at gmail.com]
> Sent: Friday, January 30, 2009 14:30
>
> Karney's routine is limited to WGS84 as is all the software in his
> library.  10 lashes with a wet noodle, Karney.

"Up to a point, Lord Copper."  The simple ECEFConvert utility I provide
(merely to illustrate the code) is limited to WGS84.  The constructor
for ECEF class allows you to specify the ellipsoid.

> Some of these methods may be equivalent but I have not dug that far
> into the details of the morass.  I am also sure that there must be
> more versions out there.

There do seem to be an embarrassing number of published papers on a
mathematically trivial topic.  Of course, provided that the methods are
correct, they must me equivalent (in a mathematical sense).

The biggest differentiator, in my book, is the domain of applicability.
Many of the methods (direct or iterative) exclude the center of the
earth (and I think some also exclude very distant points).  This is
entirely appropriate for GPS units, but seems to be an unnecessary
restriction for a general-purpose library.

Incidentally, many simple iteration schemes (such as the NGS method, I
believe) just have linear convergence.  Some iterative schemes are
amenable to Newton's method with much faster (quadratic) convergence.
Presented with such a choice, I would normally go for a slightly more
complicated iteration which converges faster.

Vermeille's method is a relatively simple direct method.  It breaks down
near the center of the earth.  But fixing this was straightforward.
Finally, I had to make several fixes to avoid loss of accuracy due to
round-off.  The errors I am getting (7 nm) are within spitting distance
of the round-off limit (10^7 / 2^53 m = 1.1 nm).

Incidentally benchmarking ECEF methods for accuracy is easy because the
geodetic to ECEF transformation is stable and, if carried out with long
doubles, accurate.  This can be used to generate test data for the
reverse transformation.  When probing points near the center of the
earth you need to ensure that

    h >= - a (1 - e^2) / sqrt(1 - e^2 sin(phi)^2)

so that the ECEF point is in the same hemisphere as phi.

> Lastly, the use of the term ECEF suggested by Wikipedia for geocentric
> seems appropriate.  Also, where are our ENU procedures?  Tsk, tsk.

ENU is what I call "local Cartesian" (implemented by the LocalCartesian
class -- and this, I confess, does have WGS84 wired in).

--
Charles Karney <ckarney at sarnoff.com>
Sarnoff Corporation, Princeton, NJ 08543-5300

URL: http://charles.karney.info <http://charles.karney.info/> 
Tel: +1 609 734 2312
Fax: +1 609 734 2662
_______________________________________________
Proj mailing list
Proj at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20090130/196e8c40/attachment.html>