[PROJ] Does WGS84 automatically use EGM96 in PROJ?

[Greg Troxel]

Clifford J Mugnier <cjmce at lsu.edu> writes:

>> From: PROJ <proj-bounces at lists.osgeo.org> on behalf of Andrew Kelley <akelley2500 at gmail.com>
>> Sent: Monday, January 10, 2022 3:54 PM
>> To: proj at lists.osgeo.org <proj at lists.osgeo.org>
>> Subject: [PROJ] Does WGS84 automatically use EssGM96 in PROJ?
>>
>> My team is using PROJ to convert ECEF coordinates to ENU coordinates
>> (relative to a fixed point on the surface of the Earth). When we use
>> WGS84 for this, does that automatically use EGM96? What makes me think
>> EGM96 is used is that one website I
>> found<http://wiki.gis.com/wiki/index.php/WGS84> says, "Presently WGS
>> 84 uses the 1996 Earth Gravitational Model (EGM96) geoid, revised in
>> 2004."  But I found out elsewhere
>> online<https://en.wikipedia.org/wiki/Earth_Gravitational_Model> that
>> there is an EGM84, EGM96, and an EGM2008.

> Apples and oranges.  ECEF to ENU is a purely geometric transformation.
> Earth Gravity Models have no relationship in such a transformation.

Some additional perspective that may help Andrew:

WGS84, both ECEF/XYZ and geodetic/LLH, is purely geometric, so your
local Up within ENU is something that's almost an ellipsoidal height
offset, relative to the lat/lon/HAE of the point you choose for ENU
conversion.  It's not quite because the up axis diverges from the
ellipsoidal normal away from (0,0).

When you are converting XYZ to ENU, presumably you are giving a
latitude, longitude, and ellipsoidal height for your ENU zero point.  If
you are using an orthometric height instead, you're blurring a
coordinate system change with a geoid model application, although I
suspect errors from that blurring are small for small areas.

Almost always, when surveying people give WGS84 coordinates in LLH, the
height should be interpreted as HAE.  However, normal people often
expect some kind of orthometric height, and navigation-type GNSS
receivers generally give an "altitude" by taking HAE and applying a
gravity model.  (From memory now) the WGS84 specifications define "WGS84
orthometric height", which is relative to the equipotential surface
defined by the datum's U_0 (or maybe they call it W_0 but it's the same
parameter).  This orthometric height is ~always accessed via an
ellipsoidal height and a gravity model, even though it is defined in
terms of gravity.  WGS84 orthometric height may be written "Alt MSL" or
something similar, as many people conflate the various orthometric
heights that aim to match the standard equipotential.

I am unaware of any GNSS other than GPS defining an orthometric height
for the system's native coordinate system, and I am unaware of any
built-in orthometric height notion in ITRF, other than having a W_0.
NGS does publish geoid models to be used with IGS08:
  https://geodesy.noaa.gov/GEOID/USGG2012/

In the northeast US, NAVD88 heights and WGS84 orthometric heights are
close, relative to the ability of almost all people to measure heights.

Consider whether you want WGS84 Orthometric Height or if you are trying
to align to the US NSRS, or some other national datums.  I don't tend to
see high-accuracy coordinates in WGS84 Orthometric Height.

WGS84 is not a datum but a family of datums.  My memory is that the
first realization used EGM84, and ~nobody pays any attention to that any
more.  Then, one or more used EGM96, and later realizations, including
the ones currently in use by GPS, use EGM2008.  EGM2008 has many more
terms available.  Typical GPS receivers even today use EGM96, and even
worse they use a coarse representation, to the point where the coarse
EGM96 differs from the full EGM2008 value by 4m around me
(Massachusetts).  This truncation of EGM96 is more significant than the
EGM96/EGM2008 differences.  See
  https://geographiclib.sourceforge.io/cgi-bin/GeoidEval

It could make sense to transform WGS84 XYZ to WGS84 latitude, longtitude
and WGS84 orthometric height, but I think this requires a compound CRS
or a pipeline.

EPSG defines datum codes which represent exactly the (presumably
non-truncated) zero-height surface of the published models.
  https://epsg.io/5773
  https://epsg.io/3855

There is a CRS which is "World Mercator + EGM2008 height", but I am not
sure that anyone pays attention to it:
  https://epsg.io/6893
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20220110/19343c84/attachment.sig>