Track file conversion

[DaveP]

I need to modify an existing track - a matter of inserting detours to B&B locations.
In the UK I have done this in Basecamp, pinpointing addresses with my City Navigator map. Double check with Streetview. The results have worked fine with either Garmin or OSM maps loaded on the day.
This time the track is in France and I'm hoping to get away without buying another Garmin Map. I do have an Open Source map, but I'm planning to work in Google Earth then convert klm to gpx, which will ultimately be used with the OSM.

The thing is, the track was originally downloaded as a gpx, then converted to klm, now I'm planning to convert it back, then use it with an unrelated map...
Am I heading for problems with cumulative errors? I haven't a clue whether this type of conversion is an approximate process or an accurate one
Naturally, if you think I'm going about things in a silly fashion, please feel free to say so!

[frankly frankie]

There shouldn't be any errors at all, but even if there are (by for instance converting between different ways of expressing Lat and Long) they should be down at the 5th and 6th decimal place sort of level - which is inches, ie much smaller than the stated 'accuracy' of the GPS system as used by Joe Public.

As someone who has done a lot of this sort of thing (Track splitting and joining and inserting detours and making new Tracks from fragments from different sources) I can say that it does pay to 'tidy' the end product somehow.  Specifically, if some or all of the fragments have timestamped Trackpoints (eg from a recorded tracklog, or many planners also output timestamed Tracks) then it pays to avoid any backward jumps in the timestamps (or, even worse, any reversal). 
I usually run the whole thing through BikeHike or similar, as that will output a continuous timestamped Track regardless of what hotch-potch went in. 
Without doing that, some Garmin models will read a compiled Track as corrupt, and probably not even bother to throw you an error message.

[neilrj]

I find gpsies file convertor will clean up any file so it will read fine, so an invalid gpx even saved again as a gpx will then work

[DaveP]

Thank you very much!
I suspect you have almost certainly saved me from a problem I wasn't even aware of. I've modified, even inverted tracks of my own devising before now. I had no idea things could be so different with third party  data!
When I open up my source track every waypoint has a time associated with it. The times are in sequence, a few years old - and we will actually be travelling in the other direction. The locations are in France, so I'll do my editing in Google Earth, translate in gspies, and cross my fingers 

I will be using the results as a track and not as a route, so presumably the only test I need is that the gps can display a coloured line on the map when the file has been converted: Ready for the big day.

[frankly frankie]

The times are in sequence, a few years old - and we will actually be travelling in the other direction.
I will be using the results as a track and not as a route, so presumably the only test I need is that the gps can display a coloured line on the map when the file has been converted:

That's OK, if that's how you're going to use it.  However in general terms - for example if you wanted to give the Track to someone else who was going to do the same trip - then having timestamps running backwards (or worse, having a mix of forwards/backwards created by joining two segments) is going to cause trouble - because the timestamps give the Track a 'direction', and a start and finish, which most GPSs in some modes are sensitive to.
But yes, if you're just going to display it as a coloured overlay on your map, then the timestamps don't matter, though bad edits may still be problematic - my Etrex Legend for example, will throw a 'data error' at time of uploading if a Track contains any timestamp that is not either a) later than any and every preceding timestamp in the list, even if years apart, or b) blank.

[DaveP]

I was thinking about this issue again last night, and realised just how incredibly lucky I have been. I do use Basecamp - for minor jobs, but thinkling aboput it, all of the longer tracks I have prepared were actually produced on Bikehike, largely because I find it easier to work with and it allows me to keep an eye out for excessive hills very conveniently. The main exception, an earlier trip through France was prepared on Google Earth, working from our start point and following out intended track in exact order - and then it was never tested thoroughly because the chap with the Edge forgot his charger...
So I have quite fortuitously evaded an unsuspected problem. My GPSMap62 says it can invert a track, but I have never really tried because of obvious issues with roundabouts and one way systems. I have never tried it with tracks compiled from multiple sources, but I do take your point about  possible problems caused by non sequential time stamps. It makes sense, and once aware of the possibility, it is easy enough to avoid it.
The thing that really surprises me is that I have managed not to come across any mention of the issue in the past. I always try to read around things I do / kit I use - and yet I've missed it. I'm just glad I was planning to take a few pages from a road atlas along... 
Thanks again!

[wajcgac]

GPS track editor allows you to state when you want the first timestamp to be or even reset every timestamp completely and disregard the original ride speed. It can also reverse the track.

Amongst other things it can also remove gps glitches automatically.

Might be of use to you

http://www.gpstrackeditor.com/

[DaveP]

Thanks ever so...
The software looks promising, but there's also quite a bit of information on the site
 I think it will be really useful.