#16550 closed defect (fixed)
Conversion OSM -> GPX without timestamps since 14055
Reported by: | Bjoeni | Owned by: | Don-vip |
---|---|---|---|
Priority: | normal | Milestone: | 18.08 |
Component: | Core | Version: | tested |
Keywords: | regression gpx | Cc: |
Description (last modified by )
TL;DR: GPX->OSM conversion creates nodes with "time"-Tags. OSM->GPX conversion only creates timestamps when the nodes have no tags.
Hi,
since Version 14055, tags such as ele and time are converted from GPX to OSM.
First of all, this makes sense in some situations, but sometimes it doesn't (e.g. when I'm planning on uploading a part of a track to OSM, I definitely don't need timestamps and most of the time no elevation either). So I would really like an option to activate/deactivate this, or even better, a conversion dialog that allows me to convert some, but not all tags.
Secondly, the tags are not converted back. This is the reason why I classified it as defect, because it results in the layer loosing all timestamps when being converted to OSM and back to GPX.
I use JOSM from time to time to edit and merge GPS tracks (and geotagging photos afterwards), and even if that's not the main purpose of JOSM, it should keep the timestamps.
The problem is that the nodes will be converted to waypoints in the GPX file, if they have any tags in the OSM layer. This means that a node (in a line) without a "time"-Tag, but with a timestamp will keep the time, but the same node with a "time"-Tag will be separated from the line into a waypoint (which is useless) and the resulting point in the line doesn't have a timestamp (point/gpx != node/osm).
A workaround for this is to manually remove all tags in the layer - and it will work as before. So one option is to allow the user to disable the conversion of the tags (makes anyways sense imo, see above), but the conversion OSM -> GPX should also consider the tags created during the conversion from GPX -> OSM (and preferably use the "time"-tag instead of the timestamp of the node, if edited by the user).
Example:
(1) Original GPX:
<?xml version='1.0' encoding='UTF-8'?> <gpx version="1.1" xmlns="http://www.topografix.com/GPX/1/1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd"> <trk> <trkseg> <trkpt lat="47" lon="9"> <ele>123</ele> <time>2018-08-01T10:00:00Z</time> </trkpt> <trkpt lat="47.1" lon="9.1"> <ele>456</ele> <time>2018-08-01T10:01:00Z</time> </trkpt> </trkseg> </trk> </gpx>
(2) This GPX converted to OSM:
<?xml version='1.0' encoding='UTF-8'?> <osm version='0.6' upload='false' generator='JOSM'> <node id='-546306' timestamp='2018-08-01T10:00:00Z' lat='47.0' lon='9.0'> <tag k='ele' v='123' /> <tag k='time' v='2018-08-01T10:00:00Z' /> </node> <node id='-546307' timestamp='2018-08-01T10:01:00Z' lat='47.1' lon='9.1'> <tag k='ele' v='456' /> <tag k='time' v='2018-08-01T10:01:00Z' /> </node> <way id='-546308'> <nd ref='-546306' /> <nd ref='-546307' /> </way> </osm>
(3) Converted back to GPX, we see wpts that shouldn't be there and no timestamps on the track:
<?xml version='1.0' encoding='UTF-8'?> <gpx version="1.1" creator="JOSM GPX export" xmlns="http://www.topografix.com/GPX/1/1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd"> <metadata> <bounds minlat="47.0" minlon="9.0" maxlat="47.1" maxlon="9.1"/> </metadata> <wpt lat="47.1" lon="9.1"> <ele>456</ele> </wpt> <wpt lat="47.0" lon="9.0"> <ele>123</ele> </wpt> <trk> <trkseg> <trkpt lat="47.0" lon="9.0"> <ele>123</ele> </trkpt> <trkpt lat="47.1" lon="9.1"> <ele>456</ele> </trkpt> </trkseg> </trk> </gpx>
(4) Now, I removed the tags from the OSM file (2), that's how it used to be before changeset 14055:
<?xml version='1.0' encoding='UTF-8'?> <osm version='0.6' upload='false' generator='JOSM'> <node id='-546306' action='modify' timestamp='2018-08-01T10:00:00Z' lat='47.0' lon='9.0' /> <node id='-546307' action='modify' timestamp='2018-08-01T10:01:00Z' lat='47.1' lon='9.1' /> <way id='-546308'> <nd ref='-546306' /> <nd ref='-546307' /> </way> </osm>
(5) And that can easily be exported to GPX with timestamps and without unnecessary waypoints:
<?xml version='1.0' encoding='UTF-8'?> <gpx version="1.1" creator="JOSM GPX export" xmlns="http://www.topografix.com/GPX/1/1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd"> <metadata> <bounds minlat="47.0" minlon="9.0" maxlat="47.1" maxlon="9.1"/> </metadata> <trk> <trkseg> <trkpt lat="47.0" lon="9.0"> <time>2018-08-01T10:00:00Z</time> </trkpt> <trkpt lat="47.1" lon="9.1"> <time>2018-08-01T10:01:00Z</time> </trkpt> </trkseg> </trk> </gpx>
Attachments (0)
Change History (12)
comment:1 by , 7 years ago
Description: | modified (diff) |
---|---|
Keywords: | regression gpx added |
Milestone: | → 18.08 |
Owner: | changed from | to
Status: | new → assigned |
comment:2 by , 7 years ago
comment:3 by , 7 years ago
Description: | modified (diff) |
---|
comment:10 by , 7 years ago
Thanks for the fix! Seems to work very well.
Part 1 of my ticket however is still "open", I would really like an option or dialog to disable the conversion of the tags in the first place. This is simply because I can upload quite a lot of my tracks with nearly no changes to OSM (e.g. some paths or tracks in the middle of nowhere), and while it isn't a big deal to remove the tags, it is unnecessary and I think that some people might miss this new feature and upload their timestamps and eles to OSM.
Should I open a new ticket for that, reopen this one (as enhancement) or am I the only one who wants that anyways? Depending on how much time I have I could also implement a patch for that (if desired).
comment:11 by , 7 years ago
It's a good idea. Please create a new enhancement ticket. I'd love to see a patch for this :)
comment:12 by , 7 years ago
Just for cross-reference (and because this ticket is also linked to from ticket:14103)
The patch is at ticket:16572
Ticket #16555 has been marked as a duplicate of this ticket.