
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><blockquote type="cite"><div dir="ltr">â€œIf you can find a clear statement of what frame any SBAS uses, I'd love<br>to see a URL/pointer.â€</div></blockquote></div><div><br></div><a href="https://gssc.esa.int/navipedia/index.php/Reference_Frames_in_GNSS">https://gssc.esa.int/navipedia/index.php/Reference_Frames_in_GNSS</a><div><br></div><div>My guess is that each constellation will use there own reference frame for the WAAS system they choose to implement.  Each can be tied to a specific ITRF version using published transformation parameters.  My guess is that a gps unit will use these parameters and use a specific ITFR only when mixing satellites from various constellations as a way to bridge the information from one frame to another.  Error are under a few centimetres.  Most consumer GPS have a errors that are much larger related to stuff like clocks, broadcast Ã©phÃ©mÃ©rides and atmospheric  conditions. The specific ITFR  chosen is probably decided by each manufacturer depending on the published data.  Since WGS84 and PZ-90 (Russians CRS) can both be easily tied to ITRF2008, I would expect that RF would be the one used in current GPS units.  I will ask the sxblue guys to confirm this.  <br><br><div dir="ltr">Nicolas Cadieux<div><a href="https://gitlab.com/njacadieux">https://gitlab.com/njacadieux</a></div></div><div dir="ltr"><br><blockquote type="cite">Le 5 mars 2021 Ã  16:48, Greg Troxel <gdt@lexort.com> a Ã©crit :<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">ï»¿<span></span><br><span>Nicolas Cadieux <njacadieux.gitlab@gmail.com> writes:</span><br><span></span><br><blockquote type="cite"><blockquote type="cite"><span>For elevation, I read the spec as saying that the datum is "WGS84</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>orthometric height", meaning that one takes WGS84 ellipsoidal height and</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>uses EGM2008 to get a height that is sort of "above sea level".  The</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>notion that the height is ellipsoidal height is to me unreasonable.  </span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>If the standard says orthometric height, it means that it takes the</span><br></blockquote><blockquote type="cite"><span>ellipsoÃ¯dal height and then applies the geiod model (in this case</span><br></blockquote><blockquote type="cite"><span>EGM2008 or Earth gravitational model 2008).  This is the height where</span><br></blockquote><blockquote type="cite"><span>the average sea level would be given the local gravity on land.</span><br></blockquote><blockquote type="cite"><span>Orthometric height is the geiod height or the height above the average</span><br></blockquote><blockquote type="cite"><span>sea level.</span><br></blockquote><span></span><br><span>Agreed but what it says is:</span><br><span></span><br><span>  <xsd:element name="ele" type="xsd:decimal" minOccurs="0"></span><br><span>    <xsd:annotation></span><br><span>      <xsd:documentation> Elevation (in meters) of the point. </xsd:documentation></span><br><span>    </xsd:annotation></span><br><span>  </xsd:element></span><br><span></span><br><span>To me, "elevation" always means some kind of orthometric height.  I have</span><br><span>never heard anyone call an ellipsoidal height elevation.  Given the</span><br><span>notion of WGS84 in GPX, and that WGS84 defines orthometric height, I</span><br><span>find this unambiguous -- but not comfortably so.</span><br><span></span><br><blockquote type="cite"><blockquote type="cite"><span>I would suggest to the Jeremy to understand the delta from "WGS84" to</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>GDA94.  I'm not a geodesy.expert.au, but my impresssion is that it's</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>only a few meters and that it is therefore unlikely that points from a</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Garmin unit have errors that are small enough to notice that.  I have</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>not been able to notice the NAD83(2011)/WGS84(G1762) shift (about a</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>meter) with L1-only navigation solution GPS.  I can resolve it very</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>clearly with dual-frequency multi-constellation RTK.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>In North American, most devices do not make a difference between Nad83</span><br></blockquote><blockquote type="cite"><span>(revised models) and WGS84 (revised models).  I imagine this is</span><br></blockquote><blockquote type="cite"><span>probably the case with GDA94, specially if GDA94 was identical to</span><br></blockquote><blockquote type="cite"><span>WGS84 original in the beginning (iâ€™am not sure this is the case, I</span><br></blockquote><blockquote type="cite"><span>really donâ€™t know here).</span><br></blockquote><span></span><br><span>Agreed.  I think what you are saying is that when one asks a device to</span><br><span>datum transform from WGS84 to NAD83 it will use null transform.</span><br><span></span><br><blockquote type="cite"><blockquote type="cite"><span>Despite "GPX is WGS84", if the GPS receiver was receiving differential</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>corrections, either locally or via SBAS such as WAAS, then the output</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>coordinates are no longer in WGS84 and are instead in the differential</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>system's frame.  WAAS is I believe in something like ITRF2005, but it's</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>very hard to figure that out precisely.  (My understanding is that at</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>least most of Australia currently has no available SBAS, but almost all</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>measurements made in the US with navigation-grade equipment are with</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>WAAS.)</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Weird... I would expect the coordinates to be a simple corrections of</span><br></blockquote><blockquote type="cite"><span>whatever version of WGS84 is currently in use...</span><br></blockquote><span></span><br><span>I expected that too.  It seems not to be though.</span><br><span></span><br><span>The reference stations that generate the coordinates don't have a way to</span><br><span>get precise WGS84(G1762) coordinates.  And, GLONASS/Galileo/BeiDou don't</span><br><span>use WGS84.  It all amounts to a bunch of frames which are for practical</span><br><span>purposes equivalent (ITRF2008 is a good overall description today, I</span><br><span>think, but that and ITRF2014 are really close).</span><br><span></span><br><span>My theory is that until you get to RTK, you just aren't going to get</span><br><span>sub-meter.  So worrying about which modern (>= 2005) flavor of</span><br><span>WGSF84/ITRF/IGS is academic.</span><br><span></span><br><span>If you can find a clear statement of what frame any SBAS uses, I'd love</span><br><span>to see a URL/pointer.</span><br></div></blockquote></div></body></html>