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

Stewart Holt stewartbholt at gmail.com
Fri Mar 5 19:12:55 PST 2021


"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/20210305/3c1c50da/attachment.html>


More information about the Qgis-user mailing list