Distance changes on joining routes

Impossible to say without having the gpx files, but often the distance measured on the GPS will vary from BaseCamp.

In the past, many users have been upset because the summary data of downloaded tracks did not agree with the their device’s real-time data – this would be the devices display of distance, speed, time (perhaps stop time, elevation, min/max elevation etc). To appease users, Garmin introduced an extension which copied the real-time data to the track log.

If this extension is present in the downloaded track, then BaseCamp will display the real-time data in the summary section instead of calculating the values from the logged data. In a gpx file, this will appear before the logged points and will begin with ”<extensions><gpxx:TrackExtension>” and end with “</gpxtrkx:TrackStatsExtension></extensions>”.

So, you could edit a gpx file and remove this section to force BaseCamp to calculated summary data from the logged data or alter the track in any way (e.g. remove/move a point or join/split tracks). For the former, you likely want to change the name of the Track in the file, not the name of the gpx file – the track name is found between <name> and </name>.

Real time data is collected at the update interval of the device – usually 1 sec. Unless the time interval for logged data is set to this interval by the user – if possible – the interval will be greater than 1 second and probably variable (i.e. the logged data will have far fewer points).

It is important to remember that devices do not give true positions, but positions with errors. If you were to walk a straight line, the logged data would show that you weaved from side to side. Hence, the logged distance will be longer than the true distance. More collected points would have a larger error than fewer points (accumulation of error). If you were to walk an arc, the distance is not that of an arc, but of multiple straight segments. For true positions, more points would be more accurate, for inaccurate positions it could go either way depending on the arc.

Distances are point to point calculations on the earth model (an ellipsoid) which has no change in elevation. Go straight up 1 mile and the device will show that you have moved 0 feet (assuming no error in position) in distance. Imagine two circles, one inside the other. The distance around the outer circle is greater than the inner circle. If the inner circle represents the earth model and you walk around the outer circle, the distance recorded would be that of the inner circle (assuming true positions).

Hopefully this will explain what you’ve observed and help to understand the limitations in the accuracy of distance based on gps data.

Thanks for that explanation, BTLAAKE. I was going to take a run at it but yours was far better than mine would have been.

...ken...

I think its a matter of sample time. On a motorcycle the location samples are more distantly spaced due to the speed of travel hence the distance and path accuracy is affected by the averaging of fewer straight line segments that approximate the actual route.

I'm afraid the explanation in that level of detail really doesn't clarify matters to me at least, apart from the fact that there will be slight errors in pinpointing location every time a point is recorded, and these will create a bit of error - but suffice it to say that this is obviously a well known problem. I have experienced minor variations in distance between that shown on the GPS, and once downloaded and viewed on BC, but never this level of error so was just querying why it seemed so extreme in this instance.

Never again trust GPS against a vehicle speedo - even on the flat if this level of error is possible.

Thanks for the responses.

Re the original tracks I saw this problem with, I have already deleted them, so can't share them.

Re, for want of a better term, "cleaning up and correcting tracked distances", I will try that on the next couple of routes - just to see what difference it makes.

Re "resetting" - on this occasion I did remember to reset and check the trip computer had reset to zero, after getting a valid grid reference location - which is why I like BC, as it allows me to correct things when I forget to reset at the start of a trip - and clear out errors such as distance accumulated during a stop if I don't turn off the GPS for the duration of the stop.

I'm still really surprised the GPSMap can accumulate so much error - but let's leave it at that

Thanks again all.

I did encounter a true bug while on vacation a view years ago. I had a track that should have been no more than 6 or 7 miles that gave a distance in the hundreds. And no, there was no long leg at the beginning of the track. I'm not sure if this added mystery distance came from the track log or from where I last turned off the GPS (this location is saved to speed up satellite acquisition at the next start-up).

In your instance, the error really is unrealistically large and I can't help but wonder where you could have used your gps in a 7-8 mile radius from the start or finish of your ride.

The important thing to know is that the summary seen on a downloaded track will match the trip computer, but it is not calculated from the logged data and that the logged data will be the more accurate of the two. A forced recalculation can be done as mentioned above or simply by deleting a single point. The former keeps all the original data and the latter change will be quite small - just choose a point on a relatively straight section of the track.

edit: I've been giving this some more thought. If my thinking is correct, I would expect no more than 0.05 to 0.1 miles of error per hour of moving travel time between the trip computer (downloaded summary distance) and the true value. Clearly your error is much much larger. If you see this again, I would suggest exporting the track from BaseCamp, a copy of the current.gpx file from your device and if possible the approximate positions when you used the device before and after the track of interest. Send this to Garmin Support/Help along with a description of the problem. If your devices's firmware is up to date, there seems to be a real device issue here.