gpsd-dev
[Top][All Lists]

## Re: [gpsd-dev] ✘wgs84_separation()

 From: Greg Troxel Subject: Re: [gpsd-dev] ✘wgs84_separation() Date: Wed, 17 Jul 2019 19:04:44 -0400 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (berkeley-unix)

"Gary E. Miller" <address@hidden> writes:

> I have been looking at the Altitude calculations in gpsd and
> they have been sort of random.  I've tried to get all the altitudes
> to be WGS84 altitudes.

(Note that I'm stepping back from being totally pedantic.)

The words involved in height can be confusing.  I listened to hours of
NGS webinars....  "Altitude" generally refers to an orthometric height,
meaning distance from the geoid.

I think the word should be "ellipsoidal height".  That's the raw
measurement GPS makes (well, XYZ and \delta t, but it's straight math
from that to lat/lon/ellipsoidal_height, with no gravity models).

People get confused between ellipsoidal and orthometric heights a lot,
so I think it's important to avoid using the word altitude to refer to
an ellipsoidal height.  That at least is what NGS practice seems to be.

WGS84 specifies a geoid model.  I am pretty sure it's now EGM2008 (but
there are quite a number of WGS84 revisions).  This is used as you say
to convert an ellipsoidal height to geoidal height, that people expect
from "altitude", where water always flows toward decreasing altitude.

sensible) comment about using EGM96 to convert back if you are given an
altitude from a GPSr that used EGM96.  But most NMEA speakers seem to
output the geoid height and that seems best to use.  9I would expect
ublox to output all of ellipsoidal heigth, geoid height, and modeled
geoid separation.)

https://gis.stackexchange.com/questions/214786/how-does-a-spatial-reference-system-change-the-underlying-geoid-without-having-t

EGM2008 is described and available (fortran!) at
https://earth-info.nga.mil/GandG/wgs84/gravitymod/egm2008/egm08_wgs84.html
https://earth-info.nga.mil/GandG/wgs84/gravitymod/egm2008/

As I understand it those coefficients and formulas are the definition of
the transformation from WGS84 ellipsoidal heights to altitudes.

> Comparing those results to those from here:
> https://geographiclib.sourceforge.io/cgi-bin/GeoidEval

I have been following the proj list and it's quite clear that the
geographiclib author is knowledgable, careful, and compulsive about
accuracy.

> It appears that wbs84_separation() can be up to 15 meters off!
>
> Looks like we been a new geoid calculator.

Indeed.  My impression is that any differences between EGM96 and EGM2008
are maybe 20 cm.  Nowhere near 15m.

Not that you suggested going there, but (for the US/Canada) there are
another set of geoid models that convert between NAD83 ellipsoidal
heights and NAVD88 orthometric heights, which are not equal to WGS84
ellipsoidal heights or WGS84 geoid heights.  This is strictly about the
US National Spatial Reference System and conceptually distinct from
WGS84.  I'd say surveyors and geodesists care and gpsd users do not.

I know you know this, but for others:
It seems often GPS receivers have a geoid model and report altitude, and
some report ellipsoidal height, and some report geoid heights.  So
presumably gpsd already can cope with getting some subset and
calculating the rest.