Distance changes on joining routes

Former Member
Former Member
I'm intrigued. I went for a cycle yesterday, but forgot to switch the GPS on until part way round. Tracked distance on the GPS = 30.8 miles. I plotted the untracked portion in basecamp - 2.4 miles. I then imported the tracked portion of the ride, and the distance showed as 30.8 miles. After joining the two sections to make a single complete route, the distance showed as 25.4 miles, which as it happens is virtually the same as when I planned the route - so I believe this is probably the correct distance.

Any ideas why this variation is occurring? Thanks
  • 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.
  • Former Member
    0 Former Member
    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.
  • Former Member
    0 Former Member
    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.
  • The more points collected, the more small errors get added together to create a larger final error. When the track is downloaded, some of the values in the summary are copied from the real-time data and not calculated from the logged data. Any time a change is made to a track, the summary data will be recalculated.

    Here is a way to remove these values from within BaseCamp.
    1. Duplicate (not copy and paste) the track
    2. Use the scissors tool to cut the duplicated track into two separate tracks. Choose a place near the beginning.
    3. Select the two tracks in the lower left corner pane, right click, select advanced>join selected tracks. (the order should be “duplicate track name” above “track xxx”.
    4. This will create a new track with one more point than the original. The extra point comes from the last point in the first segment is duplicated to become the first point in the second segment.
    5. If you want, the extra point can be deleted. It will show 0 leg distance, 0 leg time and have a duplicate time stamp with an adjacent point. You will find it more quickly if the cut is near the beginning of the track. Just delete either point with the same time stamp.
    6. Now when you click in the summary area the results will have been calculated from the log data.

    To see the summary data that is sent from the device, just export a track after you download it without making any changes. Open with Notepad -you will see it at the beginning of the track. GPS uses meters for distance, seconds for time and therefore meters/s for speed. The number of points will be the points in the track log.

    A separate issue that I think I have observed at times is that an extra distance, sometimes, somehow gets added in. The size of your error makes me suspect this happened in your case. It is a good idea to get in the habit of obtaining signal lock, resetting the trip computer (if your device has one) and clearing the track log before starting and saving the track immediately after stopping.

    And the real-time speed on a gps will be quite good; probably no more than 0.5 - 0.7 mph most of the time.
  • Former Member
    0 Former Member
    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.