[Qgis-user] Do GPX files contain CRS information?
Stewart Holt
stewartbholt at gmail.com
Wed Mar 17 18:10:25 PDT 2021
Thank you very much for this research. I am surprised that we have not met
in that rabbit hole. I first got interested in this when trying to see how
close I could match the coordinates obtained with an hour of data
collection using my SXblue II L1 GNSS WAAS unit to a USGS monument on a
nearby mountain top. With guidance from a USGS specialist on datum and
epoch conversion, the result was about 5.5 inches which I was very
happy with for my purposes. That was in 2017. In 2020, having plenty of
time to obsess over unimportant things, I fell back in that same rabbit
hole as I had more reason to correctly set the CRS on WAAS coordinates.
I will read your references to try to figure out whether WAAS is ITRF2008
or 2014. But since the difference is millimeters, it is not really
important. My hope is to have a good CRS defined for SBAS in QGIS and that
null transforms are not used between CRS which are "just" a meter
different. When I save WAAS data as ITRF2008 (I can't remember which EPSG),
QGIS 3.16 thinks the datum is invalid. 2014 seems to be OK.
Stewart
On Wed, Mar 17, 2021 at 6:14 PM Nicolas Cadieux <njacadieux.gitlab at gmail.com>
wrote:
> Hi,
>
> This last question brought me down a rabbit hole that took me a while to
> find (at least partially). Of course, this is far away from the original
> question of "Do GPX files contain CRS information?". The answer to that
> was no. The datum is WGS84 (in it's most current iteration, or
> WGS84(G1762). Transformation parameters to and from ITRF have been
> published and can be found
>
> -
> https://confluence.qps.nl/qinsy/latest/en/world-geodetic-system-1984-wgs84-182618391.html#id-.WorldGeodeticSystem1984(WGS84)v9.1-WGS84realizations
> - This file contain multiple transformations with sources
> https://confluence.qps.nl/qinsy/files/latest/en/182618383/182618384/1/1579182881000/ITRF_Transformation_Parameters.xlsx
> - This contains info on WGS84 and NAD83
> https://mcraymer.github.io/geodesy/pubs/nad83_agu2007spr.pdf
> - https://www.unoosa.org/documents/pdf/icg/2018/icg13/wgd/wgd_12.pdf
>
> Other question that were raised: What are the other reference frames used
> by the various GNSS services:
>
> - https://www.sciencedirect.com/science/article/pii/S0273117720308292#!
> - "The TRFs realized by the GPS, GLONASS, Galileo, and BeiDou-2 and
> BeiDou-3 broadcast ephemerides are the orbital realizations of WGS 84
> (G1762′), PZ90.11, GTRF19v01, and BDCS respectively."
> - More info here.
> https://gssc.esa.int/navipedia/index.php/Reference_Frames_in_GNSS
>
> This document made a comparison comparison between broadcast reference
> frames and ITRF:
>
> -
> http://www.epncb.eu/_newseventslinks/workshops/EPNLACWS_2017/pdf/06_Open_Session/04_Broadcast-Precise.pdf
> - "Reference frames:
> •GPS and Galileo broadcast reference frames are aligned with ITRF:
> translations are less than 0.10 m and rotations are less than 2
> milli-second of arc
> •GLONASS M broadcast reference frame is offset to ITRF by at most
> 0.27 ±0.04 m in Y and maximum rotation is 4 ±2 milli-second of arc about Y.
> •GLONASS K broadcast reference frame is offset to ITRF by at most
> 1.06 ±0.17 m in Y and maximum rotation is 19 ±2 milli-second of arc about
> X.
> •BeiDoubroadcast reference frame is offset to ITRF by at most 0.26
> ±0.18 in X and Y, and maximum rotation is 2 ±1 milli-second of arc about Z."
>
> Then there are questions pertaining to SBAS around the world:
>
> -
> https://www.faa.gov/about/office_org/headquarters_offices/ato/service_units/techops/navservices/gnss/library/factsheets/media/SBAS_Worldwide_QFact.pdf
> - It state the various services
> - Wide Area Augmentation System (WAAS)
> - European Geostationary Navigation Overlay Service (EGNOS)
> - Multi-functional Transport Satellite (MTSAT) Satellite Based
> Augmentation System (MSAS) (Japan)
> - GPS Aided Geostationary Earth Orbit (GEO) Augmented Navigation
> (GAGAN) (India)
> - System of Differential Correction and Monitoring (SDCM) Russia
> - Korean Augmentation Satellite System (KASS)
> - BeiDou Satellite Based Augmentation System (BDSBAS)
> - Also found this
> https://www.gps.gov/technical/ps/2008-WAAS-performance-standard.pdf
> - And this https://www.nstb.tc.faa.gov/
>
> Finally, there was the question of the introduction of new reference
> frames when a SBAS services was used. I was skeptical of this but you guys
> are right. Using a WAAS service does introduce a new reference frame as
> the "... GEO satellites do not belong to any satellite positioning service
> (e.g. GPS, GLONASS), ephemeris for those satellites are not externally
> available. Therefore, it is the SBAS that is in charge of providing the
> user with the GEO ephemeris. Keep in mind that all components are expressed
> in ECEF reference coordinates and the time offset is with respect to SBAS
> Network time (SNT)." (
> https://gssc.esa.int/navipedia/index.php/The_EGNOS_SBAS_Message_Format_Explained#SBAS_broadcast_data
> )
>
> Same information is stated here (
> https://www.sciencedirect.com/science/article/pii/S0273117720308292#!)
>
> - "Also, note that the methodology and results reported here are only
> valid for direct, real-time unaugmented GNSS applications. Any form of
> augmentation including all types of differential positioning, Assisted GPS,
> or specialized augmentation, such as the US Federal Aviation Administration
> (FAA’s) Wide Area Augmentation System, immediately introduce an alternate
> TRF with its own relationship to ITRF2014."
>
> And here (
> https://gssc.esa.int/navipedia/index.php/The_EGNOS_SBAS_Message_Format_Explained#SBAS_broadcast_data
> )
>
> - "Message type 9
>
> Message type 9 contains the information about the GEO navigation. As
> GEO satellites do not belong to any satellite positioning service (e.g.
> GPS, GLONASS), ephemeris for those satellites are not externally available.
> Therefore, it is the SBAS that is in charge of providing the user with the
> GEO ephemeris. Keep in mind that all components are expressed in ECEF
> reference coordinates and the time offset is with respect to SBAS Network
> time (SNT)."
>
> Finally, I tried to "“If you can find a clear statement of what frame any
> SBAS uses, I'd love to see a URL/pointer.” I found these documents.
>
> - https://www.gsa.europa.eu/sites/default/files/brochure_os_2017_v6.pdf
> - This one talks about the EGNOS reference frame
> - On page 20, "Strictly speaking, the time and position information
> that are derived by an SBAS receiver that applies the EGNOS corrections are
> not referenced to the GPS Time and the WGS84 reference systems as defined
> in the GPS Interface Specification. Specifically, the position coordinates
> and time information are referenced to separate reference systems
> established by the EGNOS system, namely the EGNOS Network Time (ENT)
> timescale and the EGNOS Terrestrial Reference Frame (ETRF). However, these
> specific EGNOS reference systems are maintained closely aligned to their
> GPS counterparts and, for the vast majority of users, the differences
> between these two time/terrestrial reference frames are negligible."
> - P 22 "
> The ETRF is periodically aligned to the ITRF2000 in order to
> maintain the difference between the positions respectively computed in both
> frames below a few centimetres. The same can be said about the WGS84 (WGS84
> (G1150) aligned to ITRF2000). Conversion of ETRF data into WGS84 (G1150) is
> obtained by applying the offset that exists at a certain epoch between the
> ETRF and the ITRF2000 to the ITRF2000 to WGS84 (G1150) frame. Note that
> currently these last two reference frames are almost equivalent (offsets
> minor than 2cm). This means that, for the vast majority of applications, it
> can be considered that the positions computed by an EGNOS receiver are
> referenced to WGS84 and can be used with maps or geographical databases in
> WGS84."
>
> For the other SBAS services, I found this documents
>
> - https://www.mdpi.com/2072-4292/11/4/411 : Evaluation of Orbit, Clock
> and Ionospheric Corrections from Five Currently Available SBAS L1Services:
> Methodology and Analysis
> - They state: "In addition, SBAS-derived and IGS precise orbits are
> formally referred to different reference frames. The current IGS precise
> orbits are referred to IGS14, which is aligned with the latest
> International Terrestrial Reference Frame (ITRF) called ITRF2014 [20]. *WAAS
> adopts WGS84 as the coordinate reference system to broadcast satellite
> orbit corrections *[21], and the most recent WGS84
> realization(G1762) agrees with ITRF2008 at the centimeter level [22]. As
> presented in the International Terrestrial Reference Service (ITRS) website
> (http://itrf.ensg.ign.fr/trans_para.php), the differences between ITRF2008
> and ITRF2014 are at the millimeter-level. *EGNOS reference frame,
> named EGNOS Terrestrial **Reference Frame (ETRF)*, is periodically
> aligned on ITRF within a consistency of a few centimeters [23]. We
> cannot find any official documentation or information about the reference
> frames adopted for the MSAS, GAGAN, and SDCM. However, an alignment
> to WGS84 can be expected since the requirements of international
> air navigation must be fulfilled [5]. Therefore, the differences
> between reference frames mentioned above would not exceed a few
> centimeters, which can be neglected in the accuracy assessment of
> SBAS-derived orbits."
>
> Hope this helps if you are crazy enough to read it!
>
> Cheers.
>
> Nicolas
>
>
> On 2021-03-06 10:19 p.m., Nicolas Cadieux wrote:
>
> “If you can find a clear statement of what frame any SBAS uses, I'd love
> to see a URL/pointer.”
>
>
> https://gssc.esa.int/navipedia/index.php/Reference_Frames_in_GNSS
>
> 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.
>
> Nicolas Cadieux
> https://gitlab.com/njacadieux
>
> Le 5 mars 2021 à 16:48, Greg Troxel <gdt at lexort.com> <gdt at lexort.com> a
> écrit :
>
>
> Nicolas Cadieux <njacadieux.gitlab at gmail.com>
> <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.
>
> --
> Nicolas Cadieuxhttps://gitlab.com/njacadieux
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20210317/de7bcb03/attachment.html>
More information about the Qgis-user
mailing list