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

[Greg Troxel]

Michael Dufty  writes:

> Since GPX (and KML) always use WGS84, I’ve been meaning to put in a
> feature request for QGIS to automatically select this when exporting
> to those formats.  Currently it’s quite an unfriendly experience to
> export to these formats from QGIS as there are lots of options, many
> of which (like choosing an unsuitable CRS) will give you a file that
> really doesn’t work.

That's a good point.   Sort of treating GPX as if it has an explicit CRS
which must only be set to WGS84.

I realize this is a kludge, but I would set it to WGS84(G1762).  The GPX
spec is not really clear, but it seems obvious that it's meant that new
files be created in the current realization.

Arguably older files should be read in the realization corresponding to
the datestamp of the points.  But I think it's better to treat any
change in frame from old realizations as a minor error, almost certainly
less than the actual error, than to label the data as being in a frame
ensemble with errors going back to the 80s -- that very likely do not
actually apply.


signature.asc
Description: PGP signature
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

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

[Greg Troxel]

Stewart Holt  writes:

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

That difference is not important.  The other question is epoch, and it
seems pretty clear that for a frame like ITRF2008, what you get out of
SBAS is "epoch of data", just like you do for non-differential GPS.
This is a bigger deal in terms of the difference to some reference epoch
than the frame shift.

> My hope is to have a good CRS defined for SBAS in QGIS and that

I think it's an incorrect leap to say "SBAS CRS".  There are different
systems and they probably have different frames.  If you mean a "a table
with a frame defined for each of the systems that are called SBAS as a
group", sounds good.

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

There may well be other issues in proj and the database.

The biggest thing going on here has nothing to do with obseessing over
<1cm shfits in ITRF2008-ish frames.  It's that proj 1) considers WGS84
to be an ensemble (fair) and 2) chooses a null transform if one member
of that ensemble has an error which is large (always true, not a useful
choice).

As a user, the only approach I know of is to label recent GPS
observations (>= 2013, in WGS84(G1762)) as in that frame, or in
ITRF2008/ITRF2014.  While not quite right, these labelings avoid the
problems from saying "WGS84".



signature.asc
Description: PGP signature
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

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

[Garth Fletcher]

Many many thanks to Nicolas Cadieux for that research!
--
Garth Fletcher
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

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

[Michael Dufty]

Since GPX (and KML) always use WGS84, I’ve been meaning to put in a feature 
request for QGIS to automatically select this when exporting to those formats.  
Currently it’s quite an unfriendly experience to export to these formats from 
QGIS as there are lots of options, many of which (like choosing an unsuitable 
CRS) will give you a file that really doesn’t work.

It does look like someone else already did this 7 years ago and it is on the 
“nice to have list”

https://github.com/qgis/QGIS/issues/17081

Michael Dufty

___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

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

[Stewart Holt]

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

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

[kirk]

Thanks for the research Nicolas. I think I will save this for a rainy day or 
when an issue comes up.Kirk SchmidtSent from my Galaxy
 Original message From: Nicolas Cadieux 
 Date: 2021-03-17  7:14 p.m.  (GMT-04:00) To: Greg 
Troxel , stewartbh...@gmail.com Cc: qgis-user 
 Subject: Re: [Qgis-user] Do GPX files contain CRS 
information? 
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 spe

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

[Nicolas Cadieux]

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#!
 o "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."
 o 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
 o "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
 o 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 

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

[Nicolas Cadieux]

> “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  a écrit :
> 
> 
> Nicolas Cadieux  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:
> 
>  
>
>   Elevation (in meters) of the point. 
> 
>
>  
> 
> 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@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

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

[Nicolas Cadieux]

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=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  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  wrote:
>> 
>> Nicolas Cadieux  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:
>> 
>>   
>> 
>>Elevation (in meters) of the point. 
>> 
>> 
>>   
>> 
>> 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 

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

[Greg Troxel]

Stewart Holt  writes:

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



  Each new WGS84 realization is very similar to some particular ITRF
  realization.  If I were charged with choosing a reference frame for an
  US-centric SBAS, I'd probably pick the ITRF that corresponds to the
  current WGS84 realization, recognizing that changing my reference
  station coordinates from ITRF2008 to ITRF2014 is unlikely to be
  measurable by anyeno looking at the corrections stream.   I would also
  update the reference station coordinates at the beginning of every
  year, tracking how the GPS control segment is updated.



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

See my hours-ago reply.  If you consider a 2m coordinate difference to
be "different" rather than "exactly matching", you need to be very
careful about NAD83 vs some realizaition of WGS84 and you need to be
careful that qgis is doing the transform that it should among those, and
not picking a null transform because of 1980s history.

Also, NAVD88 height and WGS84 orthometric height are not the same thing.


signature.asc
Description: PGP signature
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

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

[Stewart Holt]

"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  wrote:

>
> Nicolas Cadieux  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:
>
>   
> 
>Elevation (in meters) of the point.
> 
> 
>   
>
> 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 

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

[Garth Fletcher]

On 3/5/21 3:00 PM, qgis-user-requ...@lists.osgeo.org wrote:

On 05.03.21 06:02, jeremy benwell wrote:


I was wondering if GPX files contain CRS information? I saved some
waypoints in my garmin gps and then used GPSBabel to upload those waypoints
to my computer and create a GPX file. The map datum on my gps was set to
GDA 94. Does my GPX file contain the CRS that my GPS was set to when I
saved the waypoints (i.e. GDA 94) and if so do I need to make sure my QGIS
project CRS is set to GDA 94 also?

Any help would be much appreciated thank you!


The headers in .gpx files from my Garmin eTrex 20 reference
  

That file states:
 "GPX schema version 1.1 - For more information on GPX and this schema,
  visit http://www.topografix.com/gpx.asp GPX uses the following
  conventions: all coordinates are relative to the WGS84 datum. All
  measurements are in metric units."

Other than that reference, my .gpx files do not contain any CRS info.

I believe that the .gpx coordinates always use the WGS84 datum 
(EPSG:4326) and that there is no way to change that in the .gpx file.


See  for details.

Cordially,
--
Garth Fletcher
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

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

[Greg Troxel]

Nicolas Cadieux  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:

  

   Elevation (in meters) of the point. 


  

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.


signature.asc
Description: PGP signature
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

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

[Nicolas Cadieux]

Hi,
See comments below. Comments welcomed.

Nicolas Cadieux
https://gitlab.com/njacadieux

> Le 5 mars 2021 à 08:43, Greg Troxel  a écrit :
> 
> Nyall Dawson  writes:
> 
>> On Fri, 5 Mar 2021 at 14:59, jeremy benwell  wrote:
>>> I was wondering if GPX files contain CRS information? I saved some
>>> waypoints in my garmin gps and then used GPSBabel to upload those
>>> waypoints to my computer and create a GPX file. The map datum on my
>>> gps was set to GDA 94. Does my GPX file contain the CRS that my GPS
>>> was set to when I saved the waypoints (i.e. GDA 94) and if so do I
>>> need to make sure my QGIS project CRS is set to GDA 94 also?
> 
> The format spec is available:
>  https://www.topografix.com/gpx.asp
>  https://www.topografix.com/GPX/1/1/
> 
> The spec is clear that the datum is WGS84.
> 
> 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.  

> I
> have observe garmin units using the "orthometric height" notion; my
> geoid separation is around -30m and this can be checked.  I have an open
> question to the GPX spec group about this.
> 
This is a typical difference between a geiod height and the ellipsoid.  The 
early geiod model like EGM96 had a 15 sec grid so that explained why a GPS had 
typically more error horizontally (z) than vertically (x,y) when compared to a 
good topographic map, at least in earlier devices that had rough geiod models. 

>> No, they don't store CRS. Definitely make sure you set the crs to
>> GDA94 (but only when the gps was explicitly set to this datum!!). I'd
>> suggest re-saving the gpx to a format like gpkg which can store the
>> gda94 crs correctly, so that the dataset will open in future with the
>> correct CRS and you won't run into issues later.
>> (GPX files are just text files -- you can open to verify this!)
> 
> I am pretty sure that Garmin units use the configured datum only for
> display, and that storage (which is actually GPX, in non-ancient units))
> and GPX is still in WGS84.  If not, they are IMHO buggy.  But I haven't
> set a datum in mine since I used NAD27 when displaying in UTM to find
> points with a ruler on older topo maps!

I think that was the case with my old etrex. 
> 
> 
> 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).
> 
> 
> Also, Jeremy should be aware of the "null transform" issue with WGS84.
> WGS84 will be considered equivalent to a number of datums.  For me, it
> is mapped without a shift to NAD83 and also to ITRF2014.   So if I
> display data that's actually in ITRF2014 and also data labeled WGS84,
> and change my project CRS from ITRF2014 to NAD83(2011), the relative
> position of points change.
> 
> 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...  

> 
> The best approach is to stop using WGS84 as a CRS, and label the data
> with a more precise CRS.Even for L1-only GPS with no corrections,
> today you get WGS84(G1762), which should not be subject to the "null
> transform" problem.This is what Nyall suggested, far more concisely
> then I did :-)
> 
> Greg
> 
> 
> ___
> Qgis-user mailing list
> 

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

[Greg Troxel]

Nyall Dawson  writes:

> On Fri, 5 Mar 2021 at 14:59, jeremy benwell  wrote:
>>
>> I was wondering if GPX files contain CRS information? I saved some
>> waypoints in my garmin gps and then used GPSBabel to upload those
>> waypoints to my computer and create a GPX file. The map datum on my
>> gps was set to GDA 94. Does my GPX file contain the CRS that my GPS
>> was set to when I saved the waypoints (i.e. GDA 94) and if so do I
>> need to make sure my QGIS project CRS is set to GDA 94 also?

The format spec is available:
  https://www.topografix.com/gpx.asp
  https://www.topografix.com/GPX/1/1/

The spec is clear that the datum is WGS84.

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.  I
have observe garmin units using the "orthometric height" notion; my
geoid separation is around -30m and this can be checked.  I have an open
question to the GPX spec group about this.

> No, they don't store CRS. Definitely make sure you set the crs to
> GDA94 (but only when the gps was explicitly set to this datum!!). I'd
> suggest re-saving the gpx to a format like gpkg which can store the
> gda94 crs correctly, so that the dataset will open in future with the
> correct CRS and you won't run into issues later.
> (GPX files are just text files -- you can open to verify this!)

I am pretty sure that Garmin units use the configured datum only for
display, and that storage (which is actually GPX, in non-ancient units))
and GPX is still in WGS84.  If not, they are IMHO buggy.  But I haven't
set a datum in mine since I used NAD27 when displaying in UTM to find
points with a ruler on older topo maps!


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.


Also, Jeremy should be aware of the "null transform" issue with WGS84.
WGS84 will be considered equivalent to a number of datums.  For me, it
is mapped without a shift to NAD83 and also to ITRF2014.   So if I
display data that's actually in ITRF2014 and also data labeled WGS84,
and change my project CRS from ITRF2014 to NAD83(2011), the relative
position of points change.

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

The best approach is to stop using WGS84 as a CRS, and label the data
with a more precise CRS.Even for L1-only GPS with no corrections,
today you get WGS84(G1762), which should not be subject to the "null
transform" problem.This is what Nyall suggested, far more concisely
then I did :-)

Greg




signature.asc
Description: PGP signature
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

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

[Bernd Vogelgesang]

Hi Jeremy,

as far as I can remember, the CRS of waypoints is by default EPSG 4326,
no matter what you change in the settings of the device (changes just
alter display of coordinates on the device). But I haven't touched a
garmin for ages (yuk!) and do the stuff with my phone.

Your garmin seems to be a rather old model, cause with garmins from the
last 10 years or so, there was no need to use GPSbable to import the
data, but  they just create gpx themselves.

It is quite uncommon to produce gpx files with other CRS than EPSG:4326,
so better import it into QGIS and reproject it to a new non-gpx file
format with the CRS of choice.


Hope that helps

Bernd



On 05.03.21 06:02, jeremy benwell wrote:

Hi,

I was wondering if GPX files contain CRS information? I saved some
waypoints in my garmin gps and then used GPSBabel to upload those waypoints
to my computer and create a GPX file. The map datum on my gps was set to
GDA 94. Does my GPX file contain the CRS that my GPS was set to when I
saved the waypoints (i.e. GDA 94) and if so do I need to make sure my QGIS
project CRS is set to GDA 94 also?

Any help would be much appreciated thank you!

Cheers,

Jeremy


___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

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

[Nyall Dawson]

On Fri, 5 Mar 2021 at 14:59, jeremy benwell  wrote:
>
> Hi,
>
> I was wondering if GPX files contain CRS information? I saved some waypoints 
> in my garmin gps and then used GPSBabel to upload those waypoints to my 
> computer and create a GPX file. The map datum on my gps was set to GDA 94. 
> Does my GPX file contain the CRS that my GPS was set to when I saved the 
> waypoints (i.e. GDA 94) and if so do I need to make sure my QGIS project CRS 
> is set to GDA 94 also?

No, they don't store CRS. Definitely make sure you set the crs to
GDA94 (but only when the gps was explicitly set to this datum!!). I'd
suggest re-saving the gpx to a format like gpkg which can store the
gda94 crs correctly, so that the dataset will open in future with the
correct CRS and you won't run into issues later.
(GPX files are just text files -- you can open to verify this!)

Nyall
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

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

[jeremy benwell]

Hi,

I was wondering if GPX files contain CRS information? I saved some
waypoints in my garmin gps and then used GPSBabel to upload those waypoints
to my computer and create a GPX file. The map datum on my gps was set to
GDA 94. Does my GPX file contain the CRS that my GPS was set to when I
saved the waypoints (i.e. GDA 94) and if so do I need to make sure my QGIS
project CRS is set to GDA 94 also?

Any help would be much appreciated thank you!

Cheers,

Jeremy
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user