This is a fascinating problem where a little analysis can be most revealing.
First consider the effects of elevation. When a mapped unit distance is traversed, and the elevation changes by an amount dz (which for ground-based vehicles is always small compared to the map distance), then the actual distance traversed is very close to sqrt(1 + dz^2). (This would be perfectly accurate when the motion is made perfectly in a straight line. For actual motions over short distances that's usually a good approximation.) Because dz is presumed small, dz^2 is very small and dz^4 is incredibly small. This allows us to approximate the square root by 1 + dz^2/2, because the error made is proportional to dz^4.
Let's run some numbers to get a handle on the sizes of these errors. To make computation easy, choose our units of distance so that the vehicle traverses one unit between each GPS reading. Over the course of n readings, the mapped distance totals n*1 = n and neglects the additional distance from the elevation changes totaling about n * dz^2 / 2. How big might that be? Because dz determines the slope, the error depends on typical slopes. Approximately, a slope of t degrees translates into a value of dz of about t/60. The error relative to the mapped distance therefore equals (approximately)
(n * (t/60)^2 / 2) / n = t^2 / 7200.
For instance, for typical slopes of t = 10 degrees (fairly steep for most vehicles), the relative error equals 10^2 / 7200 = 1/72 = 1.5%.
Notice that this error should be thought of as negative: calculations from the mapped GPS coordinates would underestimate the true distance by this amount.
A similar analysis shows how one could correct a GPS reading based on an appropriate average of slopes encountered during a trip.
What about the other source of error, the measurement error in the GPS itself? This can be thought of as a random "drift" in the discrepancy between the observed GPS coordinates (X,Y) and the correct coordinates (x,y). The drift is a usually manifest as a gradual change in (X-x, Y-y) over time. It does indeed introduce some error, but it usually is not as great as one would think. In an answer at https://stats.stackexchange.com/a/2497, I report a typical 0.5% overestimate of total trip length. It would be difficult to produce an error that not only cancels out the negative error due to ignoring elevation, but also adds 3-5%.
These errors typically do not depend on duration of travel, but they do depend on the route. Normally, though, as a route becomes more tortuous, the GPS readings tend to replace "wiggles" with line segments, once more underestimating the distance. Again it is difficult to see how the GPS could be introducing a net 3-5% overestimate. Several possible alternative explanations are:
The GPS may be subject to unusually erratic conditions, such as those that might be faced by a unit traveling deep within urban clutter.
The distance believed to be correct might actually be incorrect. (For example, a car's tires can wear by 3% - 5% of their diameter during their usable lifetimes, resulting in a 3 - 5% increase in odometer readings. If the odometer is calibrated for a new fully inflated tire but the car is run on worn partly inflated tires to measure a route, it conceivably could overestimate the distance by 5% or more.)
The "correct" distances may have been calculated on a map using a projection with substantial scale error.
This looks like an encoded polyline to me - for the algorithm to encode/decode, see:
https://developers.google.com/maps/documentation/utilities/polylinealgorithm
Google also has an online tool that can encode/decode:
https://developers.google.com/maps/documentation/utilities/polylineutility
As you noted decoding your polyline seems to result in locations off the coast of Africa:
Judging by the lastTimestamp in the XML file (and assuming this is UTC in milliseconds), these locations were recorded back in 2013 (Tue, 12 Mar 2013 20:50:42 GMT to be exact). So, this data may not be valid tracking data.
I know manufacturers have gotten in trouble in the past over logging device locations to system files as part of the device development process, and then they forget to remove/purge these files before the software is launched to production. My guess is that this file is a leftover debug file from Samsung's internal software testing with the Galaxy S2.
Best Answer
I’ve used the Bluetooth GPS app from Google Play to connect an android tablet to an external NMEA GPS over Bluetooth.