Bug report #14702
GPX-Export: Wrong coordinates and altitude values (QGIS 2.14.1 Linux)
| 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.
Associated revisions
QgsCoordinateTransform::transformCoords(): do not convert elevations to radians
Fixes #14702
QgsCoordinateTransform::transformCoords(): do not convert elevations to radians
Fixes #14702
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 over 8 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 over 8 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 over 8 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 over 8 years ago
- Status changed from Reopened to Closed
Fixed in changeset af2993e97b5a4ab98107bdce86780d11dca91109.