[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] ✘wgs84_separation()

From: Gary E. Miller
Subject: Re: [gpsd-dev] ✘wgs84_separation()
Date: Wed, 17 Jul 2019 17:55:52 -0700

Yo Greg!

On Wed, 17 Jul 2019 19:04:44 -0400
Greg Troxel <address@hidden> wrote:

> "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.)

Don't step back too far!

> 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.

"orthometric beight", or height above the geoid, or Mean Sea Level (MSL).

> I think the word should be "ellipsoidal height".

"ellipsoidal height" is WGS84 altitude or WGS84 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).

Yes. ECEF X, Y and Z.  The height computed over the WGS84 ellipsoid.

> People get confused between ellipsoidal and orthometric heights a lot,

Yes, and the gpsd code was also confused.  Randomly mixing the two.
Looking at the older GPS doc, the type of height/altitude is not even
specified by some GPS.

> 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.

Except people expect to find "altitude" and when the do not see it they
get angry.

Would you conside changing gpsd to altWGS84 and altMSL?  Or?

> WGS84 specifies a geoid model.

Not to be confused with the WHGS84 ellipsoid.

> I am pretty sure it's now EGM2008 (but
> there are quite a number of WGS84 revisions).

Yes, different versions of WGS84 specify different geoids.  EGM84, EGM96
and EGM2008.  I used to think WGS84 was a constant...

I too believe EGM2008 is current.

Except in the high precision (PPP) GIS world.  They are using ITFR2014!

I'm not ready to go there...

> 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.


> This article says the current model is EGM2008.  Interesting (and
> sensible) comment about using EGM96 to convert back if you are given
> an altitude from a GPSr that used EGM96.

Good luck finding a GPS that documents their EGM version.

> But most NMEA speakers seem
> to output the geoid height and that seems best to use.

My testing shows them not to match anything I expect.  The NMEA is
knida sorta MSL, and maybe some sort of geoid separation.

> I would
> expect ublox to output all of ellipsoidal heigth, geoid height, and
> modeled geoid separation.)

But since we have many GPS samples older than 2008 they can't possibly
match today's understanding of MSL.


Obsolete when it was written two years ago.  It says EGM96 is current.

> EGM2008 is described and available (fortran!) at

I've been looking at that.  The 1 degree interpolations are maybe more than
we need.  Maybe not.  I'm still hoping to not have to translate FORTRAN.

> 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:
> >  
> I have been following the proj list and it's quite clear that the
> geographiclib author is knowledgable, careful, and compulsive about
> accuracy.

Good to know.  That was also my understanding.

> > 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.

I ran EGM84, EGM96 and EGM2008 for all the tests in
The new data is in the comments.  They varied by up to 9m!

I can't say if that is real, or an artifact if the GeoidEval code.

> 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.

Eventually NAD83 that would be nice, but that would be even more work.

> 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.

In the Western USA a lot of maps are still NAD83.  So a lot of people
do care.  The advantage to NAD83 is it does not change as much as
WGS84 as the tectonic plates move.

> 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.

Like gpsd does with all the data it gets from a GPS: grab the data, try
to calculate the rest.

> This page seems really useful, but it's not about heights

Nice, five different WGS84 versions!  Then the even nerdier ITRF ones.

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin

Attachment: pgp9c3_EWzP0M.pgp
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]