[Qgis-user] Do GPX files contain CRS information?

Sat Mar 6 18:36:41 PST 2021

Hi,

https://sxbluegps.com/sbas-made-easy/

This could help understand WAAS.  To my knowledge, all GPS signal broadcast  with the latest WGS84 CRS.  WAAS should use this CRS (when using static point and shoot mode). I imagine that if you used gps satellites and Glonass, then the gps unit must probably use a specific ITFR reference frame to bridge the differences between the various CRS. 

When using long observations (for post processing) then, you basically ignore the information contain in the gps wave and just start counting the waves between multiple satellite and the receiver (over simplification here) but basically WAAS has developed to correct instant gps positions and to make gps usable with airplanes as it also provides a means to confirm if a giving position is valid.

https://www.faa.gov/search/?omni=MainSearch&q=Waas+

ITRF does change daily (epochs).  It’s basically designed to track continental drift and the chaining shape of the earth in real time.  ITRF does not change much as we are generally talking about sub-millimeters daily changes unless you have an earth quake Type event.  WGS84 can be tied to the ITRF for a while now using published transformations.  I can find the publications when I get back home if someone is interested.

The SXblue is a very good forestry type survey GPS but the  precision will not get better by changing the reference frame. The problems you have have (1.2 feet is the type of problem most gps would like to have) cannot be corrected by changing the  dataframe but by using longer observations in a clear sky, using a second unit (or correction tower) that gives you the capability to do post processing down the line using the rinex files. 

Nicolas Cadieux
https://gitlab.com/njacadieux

> Le 5 mars 2021 à 22:13, Stewart Holt <stewartbholt at gmail.com> a écrit :
> 
> "If you can find a clear statement of what frame any SBAS uses, I'd love to see a URL/pointer."
> 
> I have spent a few hours on many occasions in the last couple of years trying to find a definitive answer from an authoritative source. I have arrived at the same conclusion that ITRF2008 OR 2014 is likely very close. WAAS was not developed to help us with better accuracy. I can find tons of information about its application to aviation but only vague references to its reference frame. The earliest was ITRF 2000. Next it used 2008 and since 2014 exists, I wonder if it is using that. As stated, there is not much difference. I have read that the epoch is updated yearly. I would like to know the best EPSG to choose for this data. I have been using NAD83(2011) EPSG:4369 which is probably fine for most mapping purposes.
> 
> Why do I continue to wonder about this? As a matter of personal interest, I wanted to know how accurately I could measure the elevation of some of the mountains over 4000 feet in the state of GA, USA. Except for a few with survey markers, most have elevations estimated from contour lines (40' interval). A few years ago, using a SXBlue II GNSS L1 unit, I measured the position and elevation of an 1807' mountain with a survey marker near home. Converted its USGS NAD83(1994) coordinates to NAD83(HARN), used HTDP to adjust for plate drift and landed within one half foot of the measured coordinates. Elevation was to the nearest foot. Data was collected for one hour and averaged.  I recently repeated the experiment and only came within 1.2 feet position and about twice that on elevation. With the new North American datum which will replace NAD83 in 2022 or 3 or ? this kind of thing will get easier, I hope!
> 
> On Fri, Mar 5, 2021 at 4:49 PM Greg Troxel <gdt at lexort.com> wrote:
>> 
>> Nicolas Cadieux <njacadieux.gitlab at gmail.com> writes:
>> 
>> >> For elevation, I read the spec as saying that the datum is "WGS84
>> >> orthometric height", meaning that one takes WGS84 ellipsoidal height and
>> >> uses EGM2008 to get a height that is sort of "above sea level".  The
>> >> notion that the height is ellipsoidal height is to me unreasonable.  
>> >
>> > If the standard says orthometric height, it means that it takes the
>> > ellipsoïdal height and then applies the geiod model (in this case
>> > EGM2008 or Earth gravitational model 2008).  This is the height where
>> > the average sea level would be given the local gravity on land.
>> > Orthometric height is the geiod height or the height above the average
>> > sea level.
>> 
>> Agreed but what it says is:
>> 
>>   <xsd:element name="ele" type="xsd:decimal" minOccurs="0">
>>     <xsd:annotation>
>>       <xsd:documentation> Elevation (in meters) of the point. </xsd:documentation>
>>     </xsd:annotation>
>>   </xsd:element>
>> 
>> To me, "elevation" always means some kind of orthometric height.  I have
>> never heard anyone call an ellipsoidal height elevation.  Given the
>> notion of WGS84 in GPX, and that WGS84 defines orthometric height, I
>> find this unambiguous -- but not comfortably so.
>> 
>> >> I would suggest to the Jeremy to understand the delta from "WGS84" to
>> >> GDA94.  I'm not a geodesy.expert.au, but my impresssion is that it's
>> >> only a few meters and that it is therefore unlikely that points from a
>> >> Garmin unit have errors that are small enough to notice that.  I have
>> >> not been able to notice the NAD83(2011)/WGS84(G1762) shift (about a
>> >> meter) with L1-only navigation solution GPS.  I can resolve it very
>> >> clearly with dual-frequency multi-constellation RTK.
>> >
>> > In North American, most devices do not make a difference between Nad83
>> > (revised models) and WGS84 (revised models).  I imagine this is
>> > probably the case with GDA94, specially if GDA94 was identical to
>> > WGS84 original in the beginning (i’am not sure this is the case, I
>> > really don’t know here).
>> 
>> Agreed.  I think what you are saying is that when one asks a device to
>> datum transform from WGS84 to NAD83 it will use null transform.
>> 
>> >> Despite "GPX is WGS84", if the GPS receiver was receiving differential
>> >> corrections, either locally or via SBAS such as WAAS, then the output
>> >> coordinates are no longer in WGS84 and are instead in the differential
>> >> system's frame.  WAAS is I believe in something like ITRF2005, but it's
>> >> very hard to figure that out precisely.  (My understanding is that at
>> >> least most of Australia currently has no available SBAS, but almost all
>> >> measurements made in the US with navigation-grade equipment are with
>> >> WAAS.)
>> >
>> > Weird... I would expect the coordinates to be a simple corrections of
>> > whatever version of WGS84 is currently in use...
>> 
>> I expected that too.  It seems not to be though.
>> 
>> The reference stations that generate the coordinates don't have a way to
>> get precise WGS84(G1762) coordinates.  And, GLONASS/Galileo/BeiDou don't
>> use WGS84.  It all amounts to a bunch of frames which are for practical
>> purposes equivalent (ITRF2008 is a good overall description today, I
>> think, but that and ITRF2014 are really close).
>> 
>> My theory is that until you get to RTK, you just aren't going to get
>> sub-meter.  So worrying about which modern (>= 2005) flavor of
>> WGSF84/ITRF/IGS is academic.
>> 
>> If you can find a clear statement of what frame any SBAS uses, I'd love
>> to see a URL/pointer.
>> _______________________________________________
>> Qgis-user mailing list
>> Qgis-user at lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20210306/2cad37ed/attachment.html>