[Proj] Re: ECEF

[Noel Zinn]

Thanks all for the clarifications and comments this thread has generated.  I
now understand that libproj is cartography only (lat/lon <=>
Northing/Easting), but that the version of proj.4 available at
remotesensing.com has extensions to libproj that include gridded datum
transformation, e.g., NADCON (lat27/lon27 <=> lat83/lon83), and "geocentric"
datum transformations (lat1/lon1/hgt1 <=> lat2/lon2/hgt2) via some
combination of 3 translations, 3 rotations and a scale change about ECEF
Cartesian coordinates (Z being positive north through the spin axis, X
positive in the Equatorial plane through the Greenwich Meridian and Y
positive in the Equatorial plane at 90E).  The cartography is mathematically
defined (in principle without error, though YMMV), but that any datum shift
parameters one might use are empirically derived and spatially variant on
distorted terrestrial datums, hence, lots of error.  That's life.

As an aside, to compute a 3- or 7-parameter datum shift one must compute to
or from the ECEF coordinates of both datums, satellite or terrestrial, via
the process: lat1/lon1/hgt1 => ECEF1 => (datum shift) => ECEF2 =>
lat2/lon2/hgt2, where lats and lons are geodetic lats and lons (not
geocentric) and hgt is normal to the ellipsoid.  So, the ECEF coordinates
are there in the code if datum shifting is being done in the extended proj.4
at remotesensing.com.  My original question was whether they were available
to the user as a deliverable without programming.  I'll have to figure out
whether proj=geocent delivers ECEF when I have an opportunity to use proj.4.
Why are ECEF coordinates useful?  For 3D visualization in appropriate
software (Matlab works for this, though industry has better) without the
distortions that all map projections (3D => 2D) inherently suffer.

Again, thanks for all the helpful comments,
Noel Zinn

----- Original Message ----- 
From: <Strebe at aol.com>
To: <proj at xserve.flids.com>
Sent: Monday, February 28, 2005 2:29 PM
Subject: [Proj] Re: ECEF


> In a message dated 2/28/2005 12:15:00 PM Eastern Standard Time, Frank
Warmerdam <fwarmerdam at gmail.com> writes:
>
> ...
> >It also has support for a geocentric coordinate system
> >(using proj=geocent). However, my understanding is
> >that there are two types of geocentric coordinates. One
> >from the center of the ellipsoid, and one from a height
> >perpendicular to the ellipsoid. I'm not sure, off hand,
> >which it is supported by PROJ.4 but can investigate if
> >needed.
> ...
>
> I can't speak for any software implementions, but as far as datums go,
'geocentric' should refer to those intended for world-wide coverage. That
includes any created for satellite measurements since, and including, WGS
72, and excluding any others I know about.
>
> As far as latitude measurement goes, first consider the ray from the
center of the ellipsoid through the equator at the meridian of the point in
question. Call that the "equatorial ray". Then 'geocentric latitude' refers
to measuring the angle subtended by the equatorial ray and the point in
question. 'Geodetic latitude', on the other hand, places the vertex at the
intersection of the equatorial ray and the ray normal to the ellipsoid at
the point in question.
>
> Hence there are at least two distinct usages for 'geocentric', one with
respect to measurement of latitude, and the other with respect to the
applicability of the ellipsoidal model.
>
> (Geocentric coordinates are used, I hear, for satellite tracking and data
gathering, but are always converted to geodetic before general release. )
>
> Regards,
>
> daan Strebe
> Geocart author
> http://www.mapthematics.com
>
> _______________________________________________
> Proj mailing list
> Proj at xserve.flids.com
> http://xserve.flids.com/mailman/listinfo/proj
>