Something I've been pondering on for a while, but haven't managed to find anything that appears to give a logical explanation for the "problem".
I understand the principles behind GPX tracks showing inaccurate height data, due to "jitter", but why would a single recorded GPX track show two different total lengths for the track - on the same device? - My Garmin GPSMAP64S consistently does just that!
I recently had a walk up Helvellyn, so I'll use data from that walk as the example.
As per norm, I had reset all trip data to zero at the start of the walk. On my return to the car, the trip computer screen was showing distance walked as 11.9 miles. At that point, again as per norm, I saved the track and switched the GPS off.
When I later downloaded the track into Garmin Basecamp software, the detailed "Track Properties" also showed the distance walked as 11.9 miles, as may be seen in the image below: -
However when I then look at the graph for the track, it ends with a distance of 11.3 miles stated - a track distance difference of over half a mile : -
Here's the raw graph: -
And here's a blow-up of the final section of the graph: -
The "route leg" point data confirms that the start and finish points of the walk were recorded at the same location, so there is no loss of data anywhere. It just seems odd that on one screen the track is shown as 11.9 miles long, and on another, as 11.3 miles long.
It happens with every track recorded on the device, and the amount of the "error/anomaly" varies with the total distance of the track in question. (0.6 miles is about the farthest difference noted so far).
Can anyone offer any suggestions as to why this might be occurring? - Might it be something specific to my particular model of GPS? - or is it something that is widely seen on GPS devices?
I'd add that it's not a cause for any concern whilst using the device, just that I'm curious as to why it happens.
Looks to me like a bug in their height profile graphing software: either it's stopping too early or, equally likely (actually more so) it's mislabelling the Y axis.
Thanks for the suggestion.
Just to add to the confusion, I just logged in and had a look at my track upload on the WalkLakes GPS Mapping page, and that too shows the track length as 11.3 miles: -
The WalkLakes track profile graph also stops at 18.2 kilometres - same distance as shown in stats above,
So it looks like the recorded GPX track is actually 11.3 miles in length.
So your GPS and Basecamp have it at 11.9 miles while the height graph and our software have it as 11.3 miles?
That's very odd. All I can tell you is how our software works out the distance which is that we first convert all the track points to OSGB and then work through all the points calculating the distance between them using Pythagoras' theorem. Now that's not perfect: it does tend to underestimate distances a bit as it's assuming you've walked in a straight line between points, the amount varying depend on how wiggly track is and how often the GPS is recording points.
This is hard to explain but consider a simple example. You walk in a complete circle of radius R and while you walk that circle your GPS records five track points, one at the start, one every 90° and one at the end, which is the same point as the start.
Let's say that R = 1 mile. A bit of schoolboy maths then leads us to two conclusions:
The real distance you've walked is 2?R - so about 6.283 miles in this case.
To our software it looks like you've walked a square of distance ?(2R² on each of the four sides - so about 5.657 miles.
Now I suppose it's possible that your GPS and Basecamp are doing some sort of curve drawing between GPS points, rather than assuming a straight line between points. If so then that would explain why the total using our method is always a bit lower.
But to be honest I'm not convinced that this is the explanation and I think you should be asking Garmin as their own software is inconsistent.
So your GPS and Basecamp have it at 11.9 miles while the height graph and our software have it as 11.3 miles? . . . . . . . . . . . . . I think you should be asking Garmin as their own software is inconsistent.
Yes, both the Trip computer screen on the actual GPS unit, and the "properties" tab of the Basecamp software (after loading the track from the device into Basecamp), both showed the track as 11.9 miles long.
The Basecamp walk profile graph, the same uploaded GPX track when opened in WalkLakes GPS mapping, and the WalkLakes walk profile graph, all show the track as 11.3 miles long.
I take on board your explanation of how the WalkLakes software works, and that does sound logical, as the means of calculating the overall distance walked.
Like yourself, I'm doubtful that the Garmin system would use some sort of curve calculation to derive total distance.
It just seems mighty peculiar that if the actual track (with over three thousand "leg-distance" points logged along that walk, within the GPS device), was, actually 11.3 miles long, why would the device's trip-computer screen say 11.9 miles? And vice-versa - If the track was actually 11 9 miles long, as shown on the trip-computer screen of the GPS, and the properties summary in Basecamp, then why would it only show 11.3 miles on the Basecamp walk profile graph.
You would think that it must be the logged "leg-distances", added together as the walk progresses, that are the basis of the GPS being able to display the length of walk on the device's screen - so if those "leg-distances" added up to 11.3 miles, then the screen would only be able to show that information and would say 11.3 miles too.
I did join the Garmin forum when I first got the GPS, so (if I can remember my username and password ), I'll give them a try. I'll report back here if they come up with anything that sounds like the right solution.
I've just opened the track in Garmin Basecamp, and exported all of the 3054 "leg-distance" measurements to a single column in Microsoft Excel.
The total of all of those individual leg-distance measurements adds up to exactly 59600 (feet).
Dividing that number by (1760yds. x 3ft.) to give miles, gives 11.29 miles.
It seems that the actual logged track was indeed 11.29 miles, (obviously rounded up to 11.3 miles) as shown on the Basecamp walk profile graph and on WalkLakes mapping.
Exceedingly odd then, that the GPS's screen and the properties summary showed 11.9 miles.
I'll still contact the Garmin forum and see if they can come up with anything.
I had a reply from the Garmin forum, which I think does adequately answer the query: -
Basically, what's been said is that by default, the device trip computer collects position data once every second. It then adds up the total distance travelled based on those one second increments, and that is the distance shown on the trip computer's data field for distance walked.
The track log though, (when set to auto), only records data once every several seconds, so unless you've walked in a perfectly straight line between each two consecutively recorded track-log points, the log will very slightly, but continually, be under-recording the distance travelled. - It's effectively recording the straight line distance between each consecutive pair of track log points, whereas in reality the walker wouldn't have walked in a perfectly straight line between the logged points.
In my case, the GPSMAP64's device settings are left on auto, so each "leg-length" recorded on the track log varies considerably, as does each "leg-time". (anything between 1 second and 50 seconds in the case of the example I gave in original post). In that example, a total of 3053 track "legs" were recorded, and the walk took 10hrs.06min. to complete.
The "average" time for each track log leg 36360(seconds) /3053(legs), thus being approximately 12 seconds. - Giving plenty of time between any two recorded points to meander away from a dead straight line between the two.
When you upload the data from the GPS device to Basecamp, the properties summary shows the total distance as the figure that was displayed on the trip computers data field, based on logged implements of 1 second apart. (i.e. 11.9 miles in this case). However, the GPX track-log, and associated graph, show the data that was recorded by the track-log, based on individual data points, each being several seconds apart from its neighbour. Thus accounting for the reduced total walk length, (11.3 miles in this case), showing on the Graph and the recorded GPX track.
This explains the reason why the recorded GPX track also shows as 11.3 miles when uploaded to WalkLakes. - That being the exact same distance as the total of all the individually recorded "leg-distances" added together. (So regardless of where that particular GPX track might subsequently be uploaded to, it would always show as being 11.3 miles in length).
I was following this topic as I have the same variation in measurements, but one thing I can add is that in Basecamp the list of data for 1 track the distance is rounded off to whole units. To test my theory I left my Etrex 20 running in a stationary position with 5 sec recording intervals and found that even when the leg length was zero it would sometimes still have forward speed which suggests that basecamp is working on different numbers than those visible. Also setting the units to metric really showed things up as in the summary the track length showed as 109m but totalling the leg distances gave 19m, although the elevation profile used the summary length of 109m.
Knowing that the official OS mapping of the farms fields is done on a flat basis, I used Pythagoras on Mikes track just to see if the difference was caused by measuring on the flat vs slope but then the distance came out at 12.6 miles, so it wasn't that but know we have the proper explanation.
However the results also gave me thought over other data fields & comparison between different apps, the result are below.
The first track was created on a rainy day on the edge of a steepish slope the second on a clear day in a gently sloping field. The track in google earth was adjusted to ground level on import. I think this shows that different apps/programs handle things differently and give quite wide ranging results.