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?
Mike
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 that.)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 (MSL).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.sThe "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: https://agupubs.onlinelibrary.wiley.com/doi/full/10.1029/2011JB008916 "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 ofNot fuzzy when the hard scientists define it.height above WGS84 geoidHow 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 heights.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 level.Uh, certainly not my city and county. They converted to WGS84, as default, many years ago. https://www.bendoregon.gov/services/mapping-services/interactive-city-map And the FAA still uses MSL. https://en.wikipedia.org/wiki/Lowest_safe_altitudeAnd 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 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.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: https://navcen.uscg.gov/pdf/gps/IS_GPS_200K.pdfOn 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 misled.Which is why gpsd needs to give them all three: altHAE altMSL geoidSep 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: altHAE altMSL geoidSepWould you conside changing gpsd to altWGS84 and altMSL? Or?This prompted me to download the ICD from https://www.gps.gov/technical/icwg/ 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 https://earth-info.nga.mil/GandG/publications/tr8350.2/tr8350_2.html 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 that 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) altitude_WGS84 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 level.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 ITFR2014! http://itrf.ensg.ign.fr/trans_para.php 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 bostonThat 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.https://gis.stackexchange.com/questions/214786/how-does-a-spatial-reference-system-change-the-underlying-geoid-without-having-tObsolete when it was written two years ago. It says EGM96 is current.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 test_gpsclient.py. 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 test_lienthelprs.py. 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 work.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 good.So, how about: altHAE altMSL geoidSepFor display to users for actual use, I think they basically want orthometric height. For test clients, both is a good plan, clearly labeled.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. RGDS GARY --------------------------------------------------------------------------- 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.