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