Bug report #14702

GPX-Export: Wrong coordinates and altitude values (QGIS 2.14.1 Linux)

Added by Flo Ju over 4 years ago. Updated about 4 years ago.

Status:Closed
Priority:Severe/Regression
Assignee:-
Category:Vectors
Affected QGIS version:2.14.1 Regression?:No
Operating System:Linux Kubuntu and Windows Easy fix?:No
Pull Request or Patch supplied:No Resolution:
Crashes QGIS or corrupts data:No Copied to github as #:22663

Description

QGIS 2.14 seems to have an error exporting Features (3D) to GPX. Doing the same with the same data in QGIS 2.8.x the GPX-Files are valid.
What happens: In QGIS 2.14 in the altitude values become centimeters instead of meters in the exported GPX. (Screenshot lower right window)
Workflow: Shapefile with line-features (3D with z values) in Austria GK West (epsg:31254) --> select a feature --> Save as... --> GPX without attributes with target CRS epsg:4326. Coordinates are OK, altutude-values become centimeters. Same workflow in QGIS 2.8.x --> everything OK (Screenshot left window).
Workflow 2: Transform the Shapefile to epsg:4326 before export --> same behaviour.
Workflow 3: Setting no target CRS at export to GPX (user defined -10000) --> altitude values in meters ! but coordinates not decimal degrees.

In QGIS 2.8 the normal workflow and also variant workflow 1 work well and generate valid GPX-files.

QGIS214_GPX.png (162 KB) Flo Ju, 2016-04-18 11:00 PM

Associated revisions

Revision af2993e9
Added by Even Rouault about 4 years ago

QgsCoordinateTransform::transformCoords(): do not convert elevations to radians

Fixes #14702

Revision 0de1bfaf
Added by Even Rouault about 4 years ago

QgsCoordinateTransform::transformCoords(): do not convert elevations to radians

Fixes #14702

Revision 17295317
Added by Nyall Dawson about 4 years ago

Don't transform z coordinates by default

Since z coordinates can represent potentially any height
unit and reference point, it's not safe to assume that they
always represent height in metres relative to the ellipsoid.

Instead, leave z values untouched by default with geometry
transforms, and make transforming z an optional parameter

Refs #14702

History

#1 Updated by Nyall Dawson about 4 years ago

  • Resolution set to up/downstream
  • Status changed from Open to Closed

I believe this is a change/bug in GDAL itself - trying to convert a shapefile with Z to GPX using ogr2ogr also results in the incorrectly converted altitude values.

#2 Updated by Even Rouault about 4 years ago

  • Resolution deleted (up/downstream)
  • Status changed from Closed to Reopened

I'm not sure this is a bug in the OGR GPX driver. I couldn't reproduce on ogr2ogr command line any issue, but with QGIS yes. So I suspect there's an issue with how QGIS reprojects coordinates.

$ cat linestring25d.csv 
id,WKT
1,"LINESTRING(2 49 100,3 50 200)" 

$ ogr2ogr linestring25d_4326.shp linestring25d.csv -a_srs EPSG:4326 -select id

$ ogr2ogr linestring25d_32631.shp linestring25d.csv -s_srs EPSG:4326 -t_srs EPSG:32631 -select id

$ ogr2ogr -f GPX linestring25d_from_4326.gpx linestring25d_4326.shp 

$ cat linestring25d_from_4326.gpx
<?xml version="1.0"?>
<gpx version="1.1" creator="GDAL 2.2.0dev" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.topografix.com/GPX/1/1" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd">
<metadata><bounds minlat="49.000000000000000" minlon="2.000000000000000" maxlat="50.000000000000000" maxlon="3.000000000000000"/></metadata>                    
<rte>
  <rtept lat="49.0" lon="2.0">
    <ele>100.0</ele>
  </rtept>
  <rtept lat="50.0" lon="3.0">
    <ele>200.0</ele>
  </rtept>
</rte>
</gpx>

$ ogr2ogr -f GPX linestring25d_from_32631.gpx linestring25d_32631.shp -t_srs EPSG:4326

$ cat linestring25d_from_32631.gpx
<?xml version="1.0"?>
<gpx version="1.1" creator="GDAL 2.2.0dev" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.topografix.com/GPX/1/1" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd">
<metadata><bounds minlat="48.999999999999893" minlon="1.999999999999914" maxlat="49.999999999999993" maxlon="3.000000000000000"/></metadata>                    
<rte>
  <rtept lat="48.999999999999893" lon="2.0">
    <ele>100.0</ele>
  </rtept>
  <rtept lat="50.0" lon="3.0">
    <ele>200.0</ele>
  </rtept>
</rte>
</gpx>

If I open linestring25d_4326.shp with QGIS (master) and save it as GPX, the GPX is fine. If I open linestring25d_32631.shp with QGIS and save it as GPX, making sure to force the target SRS to EPSG:4326, then the elevations are corrupted :

$ cat test.gpx
<?xml version="1.0"?>
<gpx version="1.1" creator="GDAL 2.2.0dev" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ogr="http://osgeo.org/gdal" xmlns="http://www.topografix.com/GPX/1/1" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd">
<metadata><bounds minlat="48.999999999999901" minlon="1.999999999999915" maxlat="50.000000000000007" maxlon="3.000000000000000"/></metadata>                    
<rte>
  <extensions>
    <ogr:id>1</ogr:id>
  </extensions>
  <rtept lat="49.0" lon="2.0">
    <ele>5729.577951308232514</ele>
  </rtept>
  <rtept lat="50.0" lon="3.0">
    <ele>11459.155902616465028</ele>
  </rtept>
</rte>
</gpx>

#3 Updated by Even Rouault about 4 years ago

I've submitted https://github.com/qgis/QGIS/pull/3244 which fixes my above case for linestring25d_32631.shp export from QGIS. Looks to me like the issue would have always existed ! (since the commit that introduces it is from 2006!)

#4 Updated by Even Rouault about 4 years ago

  • Status changed from Reopened to Closed

Also available in: Atom PDF