[Top][All Lists]

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

Re: [gpsd-dev] ✘wgs84_separation()

From: Michael J. Tubby B.Sc. MIET
Subject: Re: [gpsd-dev] ✘wgs84_separation()
Date: Fri, 19 Jul 2019 02:38:39 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0


This is really interesting.... *but* can we not just settle on WGS84 'altitude', i.e. above [or perhaps below] the WGS84 geoid datum, and allow users to transform this to their datum (eg. Newlyn Height, in the UK) or NAD83 or any of the hundreds of other datum?


On 18/07/2019 20:11, Gary E. Miller wrote:
Yo Greg!

On Thu, 18 Jul 2019 09:23:23 -0400
Greg Troxel <address@hidden> wrote:

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

"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!  
Sort of a joke.
What?  No smiley?  :-)

(Also, this post is US centric, because that's what I know best.  More
or less, all other countries have similar vertical datums that serve
the same purpose, with the exact same issues, and I won't keep saying
NAD83 would be USA centric.  WGS*$ is the "World Geodetic System".

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
Right.  Except that:

  height above geoid is ambiguous about orthometric vs dynamic or
  normal, and this is beyond almost everyone, so I'm fine with "height
  above geoid".
I'm sure we could get really picky, but after re-reading all the docs
on the various GPS models, those that specify say "height above geoid".

  MSL is a term no longer used.
Really?  I suggest you re-read the NMEA and u-blox ZED doec.s

 The "Mean Sea Level Datum of 1929"
was renamed the "National Geodetic Vertical Datm of 1929" for multiple
  reasons including that mean sea level at various places is
different. NGVD29 is no longer used.   The current US vertical datum
is NAVD88, and that used one tide gage for the zero.
Now you really are getting US centric.  I'm referring to the
world standard EGM2008.  That is then converted to local datum, like
NAD83, as required.

Even the paper annoucing EGM2008 calls it MSL:

"elevation‐related quantity, such as heights above and depths below
Mean Sea Level (MSL), "

So I interpret "height above MSL" as a fuzzy statement and that when
someone says that these days they probbably mean one of
Not fuzzy when the hard scientists define it.

  height above WGS84 geoid
How about gpsd calls is "altHAE" ?

  height in NAVD88 (or whatever the official national vertical datum
is in the country they are in)
gps officiall discorages setting your GPS to anything but WGS84.  Maybe
that should be louder in the doc.

and I think we  should entirely avoid MSL in code and docs to align
with current geodetic pracice.
Except we can't as that is what NMEA, u-blox, etc. tell us that is
what they are giving u.

I think the word should be "ellipsoidal height".  
"ellipsoidal height" is WGS84 altitude or WGS84 height.  
not really altitude.  It's height above the eillipsoid, and is the
right term.  WGS84 defines a geoid model and thus also provides geoid
So, how about gpsd calls it "altHAE"?

Aside from the tiny fraction of people that can follow this
conversation, everyone treats "height" as something like orthometric
height, height in their national vertical datum, height above sea
Uh, certainly not my city and county.  They converted to WGS84, as default,
many years ago.

And the FAA still uses MSL.

And everybody who really understand will immediately know from
"ellipsoidal height" what it means.
Which is not the gpsd audience.  Our audience is people flying airplanes
and using city maps.

If I were to see "WGS84 altitude", I would be suspicious, but judge it
more likely that it meant height above the geoid, using the WGS84
geoid model.
Which would be totally wrong.  So how about "altHAE"?

People get confused between ellipsoidal and orthometric heights a
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.  
I assume you mean "older GPSr doc" and receivers.  The actual GPS ICD
I suspect has always been clear.
red herring.  The GPS ICD says zero about datums:

On Android, the system API specifies ellipsoidal height.   However,
some phones return height above geoid.   osmand, satstat, gpstest
have been dealing with this.
And since they depend, sometimes, on gpsd (see the new gpsd Android
port), we gotta be clear what we give them.

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.  
If what they have is ellipsoidal height, I think it's far better for
them to be upset that they do not have altitude than for them to be
Which is why gpsd needs to give them all three:

Until recently gpsd gave them only "altitude" which was just random.

My point is that from my viewpoint, more or less nobody who understand
height would choose to use the word altitude to describe an
ellipsoidal height.
Still not addressed my suggestion from last email.  How about:

Would you conside changing gpsd to altWGS84 and altMSL?  Or?  
This prompted me to download the ICD from
but it doesn't talk about height.
And yet, earlier in thei email you said it did...

If you read the WGS84 specification (albeit an old one), linked from

on page 7-4 the terms are

  h = N + H

  h = geodetic height (height relative to the ellipsoid)

  N = geoid height

  H = orthometric height (height relative to the geoid)

Now, those are pedantic geodesy terms, and our goal is to pick words

  people that understand geodesy will find 1) not confusing and 2) not
  at all wrong

  people that don't understand will not get the wrong idea

I would call them

  ellipsoidal_height_WGS84 (or ellipseh_WGS84 if that's too long)


  geoid_height_WGS48 (or geoidh_WGS84 if too long)
Too long, too confusing.  It does not match what most maps and charts
use.  They use MSL or WGS altitude.

People that don't understand will look at alitude which is what they
want, and they will end up with a value that means what they think it
means, even if they have no idea there is an ellipsoid.
So we give them two, and make them ponder a moment.

Geodesy people will say "but altitude should be labeled orthometric
height", but when they see those three will immeidately understand
that the altitude term is an accomodation for normals.
And yet the EGM2008 authors used MSL.

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...  
Big discussion on proj list now.  WGS84 sort of refers to the set in
aggregate.  But I think gpsd doesn't need to worry about this.  Also,
the differences between successive revisions of WGS84 are now cm
cm in the latest revisions.  The first revisions were closer to meter
level.  I agree that gpsd need not rais that distinction since NONE
of the GPS documents which they use.

I too believe EGM2008 is current.

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

I'm not ready to go there...  
Agreed we should not.  However, that is a computation from raw
observables, and not something you get out of a receiver.
Uh, no.  To be accurate you need raw observables, but it is a
good and valid datum in its own right.

Also, the difference between WGS84(g1762) and ITRF2008 is basically
zero, and ITRF2008 to ITRF2014 are very close.  I think they are now
changing by a few mm.
Which is beyond gpsd dynamic capability, for now.

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 am remembering the old garmin GPS II+, which I realize is ancient
history.   I remember that the "altitude" that came out was plausibly 
orthometric height and I remember a number around -29m for geoid
height, which checks reasonably with geographiclib for boston
That process is what I have been doing for a few weeks.  Trying to figure
out what each altitude in gpsd means.  If you  look you will find more
confusion in gpsd, please report it if you find it so it can get tweaked.

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.  
Today's geoid model.  Today we understand there is no MSL.
Except the EGM2008 authors disagree with you.  I'll side with those
smart guys.

Obsolete when it was written two years ago.  It says EGM96 is
That's the question.  The answer explains that it's EGM2008.
I still say useless.

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.  
interesting, I'll take a look.   This does not make sense to me.
Look in  There I documented my tests and results.

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
I think a very reasonable position is that gpsd does WGS84 period,
matching the realization used by GPS, and that if you want something
else you can run proj.
Then every pilot that uses gpsd directly, or indirectly hates us.  Not
gonna do it.

Plus in 20022 the US (and jointly with Canada I think) are getting new
horizonal and vertical datums.
Which will differ by much less than a consumer GPS can measure.  The
20 m MSL differences you want to throw away mean life or death to a pilot.

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.  
Sure, for horizontal it matters, at the 2m level.  I meant that for
people using gpsd witha navigation solution, the vertical accuracy you
get is much worse than the difference between NAVD88 and WGS84
orthometric heights.
Only worse because gpsd calculates it wrong.  Not beccause a GPS
can not measure it well.

So I think if there are the three fields above, and they are taken
from the GPSr if reported and calculated otherwise, things will be
So, how about:

For display to users for actual use, I think they basically want
orthometric height.  For test clients, both is a good plan, clearly
Maybe what they want, but when they look at their maps and charts that
term is not there.  orthometic height is for the doc, not the display.

Also, once theere is both "ellipsoidal height" and "altitude"
displayed, it's obvious to those who get it.
It needs to be obvious to those that do NOT get it.

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


Michael J Tubby B.Sc. (Hons) MIET / Technical Director
Email: address@hidden
Direct: +44 (0)1905 752892
Mobile: +44 (0)7973 225144

Thorcom Systems Limited
Phone: +44 (0)1905 756 700
Address: Unit 4, 96B Blackpole Trading Estate West, Worcester, WR3 8TJ, England, UK
Company registered in England & Wales No. 02704696 / VAT Number GB487925681 / EORI GB487925681000

This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed.
Any views or opinions expressed are solely those of the author and do not necessarily represent those of Thorcom Systems Limited.
If you are not the intended recipient of this email, you must not take any action based upon its contents or disclose it to any third-party.
Please contact the sender if you believe you have received this email in error.

reply via email to

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