Usecase:
- Convert a GPX, consisting of multiple sequences, to data layer.
- Edit it (for example, to remove a large blob while stationary).
- Convert back to GPX, save.
Now many data consumers break - including OSM traces.
Example:
![](/raw-attachment/ticket/21257/josm-gpx.png)
The straight line does not exist, but is drawn because the GPX is consumed sequentially.
In some cases it is much worse, with such straight lines cross-crossing the GPX display.
Other data consumers with this same problem include Strava.
Workaround - process the trace with gpsbabel like so:
gpsbabel -t -i gpx -f 2021-08-14\ 09.39.58\ Day.gpx -x track,merge -o gpx -F 021-08-14\ 09.39.58\ Day_2.gpx
This sorts the sequences (trkseg), and the trace looks good when uploaded to OSM:
![](/raw-attachment/ticket/21257/josm-gpx-gpsbabel.png)
This is also how the trace would look if uploaded before editing with JOSM.
Would be great, if JOSM would perform the same sorting when saving a GPX.
2021-08-14 09.39.58 Day.gpx - file, saved by JOSM
2021-08-14 09.39.58 Day_2.gpx - file, saved by JOSM, then processed with gpsbabel
In 18206/josm: