GPS Always Overestimates Distances (i-programmer.info) 131
mikejuk writes: Have you had a suspicion that your GPS app is overestimating the distance traveled? It is something that runners and walkers complain about a lot. If so, you are probably correct -- but the reason isn't an algorithmic glitch. The answer lies in the statistics, and it is a strange story. If you make a measurement and it is subject to a random unbiased error, then you generally are safe in assuming that the random component will make the quantity larger as often as it makes it smaller. Researchers at the University of Salzburg (UoS), Salzburg Forschungsgesellchaft (SFG), and the Delft University of Technology have done some fairly simple calculations that prove that this is not the case for GPS distance measurement. Consider the distance between two points — this is along a straight line, and hence it is the shortest distance. Now add some unbiased random noise, and guess what? This tends to increase the distance. So unbiased errors in position give rise to a biased overestimate of the distance. There is an exact formula for the bias and in some cases it can be more than 20%. Is there a solution? Perhaps using velocity measurements and time to work out distance is better — it isn't biased in the same way, but how accurate it could be remains to be seen. So when your fitness band tells you you have run a 4-minute mile — don't believe it.
Re: (Score:2)
No, that was you having a movement on your bar stool.
Re: (Score:2)
I have a huge bag of crisps right next to the sofa. So MY GPS told me I moved *eactly* 0 yards today and didn't over estimate. Sucks to be you. Grow up kid and get a better GPS.
BRB gotta shave my neck.
Re: (Score:2)
You had me going until you pretended you actually shave that thing. You've still got rancid cranberries from last Thanksgiving in it!
Re: (Score:2)
You had me going until you pretended you actually shave that thing. You've still got rancid cranberries from last Thanksgiving in it!
Allow me to scoff at your obvious stupidity. Clearly I never eat fruit. Any fool can see that.
Re: (Score:2)
That is why it is 90% sugar. That sweet and sour dessert sauce? Those aren't lumps, those are cranberries.
The pie might have also had a little fruit. Worse, the sugar in it is probably from beets. Which are a vegetable.
Wait until somebody tells you that there are concentrated vegetables in the gravy. You might reconsider the stomach staples at that point.
Re: (Score:2)
Wait until somebody tells you that there are concentrated vegetables in the gravy.
pfff doesn't bother me. Cheetos are all vegetable.
You might reconsider the stomach staples at that point.
Ha! Neckbeard + skinny is not a good look. Besides one needs a certain frame stretch out T-shirts so there are no wrinkles otherwise people might not be to read the condescending statements and cartoons written them,or appreciate the obvious attractiveness of the scantily clad anime characters portrayed therein.
Re: (Score:2)
Simple problem with a simple solution (Score:5, Informative)
Re:Simple problem with a simple solution (Score:5, Interesting)
The reason is pretty obvious if your GPS device has ever been slow getting a fix on multiple satellites and has a large error circle. One moment it says you're at position x, 5 seconds later it says you've warped half a mile away. The larger the positional error, the greater the distance error. Assuming you're traveling a straight line path, the positional errors average out to zero only when the errors fall along the line you're traveling. Any positional error perpendicular to your direction of motion results in an overestimate of distance traveled by tracing your route as a zig-zag instead of straight.
That would suggest a smoothing algorithm could mostly fix this. Basically draw the simplest curve you can that goes through all the error circles around the breadcrumbs the GPS has recorded.
Re: (Score:2)
No, he's right. Higher polling frequency plus intelligence is technically the best solution. If you decrease polling frequency, you become more susceptible to losing distance around curves and right angle turns. Instead, the best solution is to poll continuously (or as continuously as is practical for computational and battery needs).
Assuming you travel in a straight line, then all of those errors should be randomly distributed to both sides of your actual line of travel. You then go from the starting point
Re:Simple problem with a simple solution (Score:4, Interesting)
Assuming you travel in a straight line, then all of those errors should be randomly distributed to both sides of your actual line of travel.
They're not though. There's temporal errors in the correlation. Various atmospheric effects cause bias, for example. There are various companies offering high end devices which can record the signals then post process them based on atmospheric data. WAAS does the same thing in a more timely manner but it's a little less accurate then the offline methods (as may be expected).
Also if you're getting errors due to multipath, you'll get effectively correlated errors until you move far enough that the receiver locks on to a different one of the reflections.
And finally, a lot of receivers use a simple Kalman filter to track the frequency/code position. This produces slight biases as well, because the model in the KF doesn't quite match reality. If you model the orbital mechanics of the satellite properly and use that as a feedforward step in the filter, then you remove another source of bias. Most receivers don't because there's just no real need to introduce the extra complexity, and small, correlated errors don't matter all that much.
Nonetheless there's just a sample of how temporally correlated errors creep in. Once you have temporal correlation, additional sampling doesn't help much and obviously can never get rid of errors whose time constant is longer than that of your filter.
As for the best fit line, you need to be careful there. You need to have a model which matches how the person runs. For example you might want piecewise linear, where the size of angle doesn't introduce cost (unless it's too small?), and there's an expected distribution of distances between joints, such that anything outside that distribution (too short) introduces cost.
It's a horrendous optimization problem, but the data's quite small, and I'd bet simulated annealing would solve it pretty well, as would a number of different heuristic algorithms.
Re: (Score:2)
If you model the orbital mechanics of the satellite properly and use that as a feedforward step in the filter, then you remove another source of bias. Most receivers don't because there's just no real need to introduce the extra complexity, and small, correlated errors don't matter all that much.
When I'm evaluating GPS modules, most of them advertise approximately this feature. Without some sort of product testing saying it doesn't work, I'm not going to believe it is a real contemporary problem. A decade ago? Probably true for consumer products. Now? No. And you don't have to model the orbital mechanics, with model being a verb, you can simply have a model, (a noun) and look up the expected position in the table. "Everybody" predicts satellite position these days. And worrying about complexity is
Re: (Score:2)
Seems my information is a bit out of date then. I last looked at it quite some number of years ago. Cheap consumer units were available, but they were pretty basic. I kind of wondered why they didn't do the proper orbital positions (looking up in a table is functionally equivalent to modelling it), since it didn't seem any more complex computationally than using a KF. One theory I heard was that some reference implementation used a KF, so all the simple modules did too.
I guess there's been some consolidatio
Re:Simple problem with a simple solution (Score:5, Informative)
http://www.adafruit.com/datash... [adafruit.com]
That's the cheapo GPS chip that makers are using. ~$40 on a breadboad module, but more like $5 as an OEM part. Calculates and stores "up to 3 days" of satellite position, then uses a lookup table. That is part of why new units still take a long time to get a cold fix; they're calculating satellite positions.
This has been a standard feature since around 10-15 years ago when they started advertising improved urban accuracy. If you're not predicting locations, you'd have to do a cold fix every time you walked past a building! It would be basically unusable downtown. Like in the old days! Back then it was also largely unusable in the forest; you'd have to find a clearing, or else remain stationary for a couple minutes, to get a fix on a cheap unit. That is why back then for serious outdoor use people were dropping $500 on dedicated GPS units that had the predictive routines, and regular GPS was intended mostly for highway auto use where the sky is usually visible.
Almost everything predictive uses Kalman filters. That is not a sign of low quality. It is a system of using predictions and expected error rates to overcome noise. If the result quality is low, it is not because of using a Kalman filter it is because of having a low quality prediction routine, or an inaccurate expected noise level. There is nothing about orbital mechanics or radio propagation that makes Kalman filters a poor fit; actually, it is nearly the ideal case for them; the noise will have a Gaussian distribution.
Re: (Score:2)
I didn't know about GPS devices using Kalman filters. But I noticed this issue when using MyTracks to measure my hikes a couple years ago. I wished the project was open-source so I could go in and add some sort of algorithm to correct the issue. I think the problem isn't the lower-level GPS reports but the way the tracking apps are designed.
One could use piecewise linear regression to fit a series of line segments through the GPS data, only adding in kinks when doing so results in a significantly better fit
Re: (Score:2)
Oh it is open source [github.com] I think. Well, game on!
Re: (Score:2)
I recommend "osmtracker" https://f-droid.org/repository... [f-droid.org]
I use both in the field, but osmtracker has a lot more features. MyTracks is still useful for caching and displaying the google satellite view, but osmtracker does a better job managing waypoints IMO so I record the tracks with that one. Also, while MyTracks is open source, most users are using the official google one and so if you improve osmtracker more people will benefit.
Re: (Score:2)
Mostly. But the problem is in the time period you're averaging; if you take a longer average, the positional error would still average out. The reason it makes the zigzag is that the resolution we demand for our movements is different than the granularity of the noise errors.
Users want the small movements that are smaller than the expected noise level of the sensor. It might be possible to simply also take a longer average, and normalize the A-B distance based on that, while preserving the zigzag. That way
Re: (Score:2)
Re: (Score:2)
Nope. The problem is reduced when you poll more often.
Re: (Score:2)
As a sailor who use GPS alongside traditional navigation: stop using devices that poll and insert a new leg on your route every 5 seconds. If you lower the polling frequency to f.e. every 1 or 2 minutes this problem goes away. I realize that this doesn't work for people who insist on taking their morning run zig-zagging through city blocks.
I've honestly never had this be a serious problem when running. I've even compared it to chip times at running events and the pace my GPS puts me at is typically within a second of the official race time. Now I've never tried this in NYC or somewhere else with serious urban canyons, i have done it in other cities with blocks of tall buildings.
Re: (Score:2)
As a sailor who use GPS alongside traditional navigation: stop using devices that poll and insert a new leg on your route every 5 seconds. If you lower the polling frequency to f.e. every 1 or 2 minutes this problem goes away. I realize that this doesn't work for people who insist on taking their morning run zig-zagging through city blocks.
My dad hired a "carpenter" once who measured every board 16 inches from the previous board. By the time he got 20 or 30 boards nailed in, his being off 1/8 inches each measure had ballooned to being off almost 6 inches and the boards having a noticeable lean.
I think the other issue they're dealing with besides skew is that you shouldn't be looking at the average distance between two points to calculate the distance as the "average" is always going to be greater or equal to the straight line shortest. You
This seems really simple... (Score:2)
If the bias is known to be X percent on average, how about you subtract those X percent from the number to get an unbiased result? You might even come up with a way to estimate the bias in each particular case based on input from the sensors.
I thing apps like RunKeeper are already doing this sort of thing, because they seem pretty accurate to me, if perhaps a little too optimistic...
The thing is, you don't win users by under-estimating their achievements.
Re: (Score:2)
Then you should do whatever you can to estimate the bias as a function of time, or sample number, or what have you.
It makes no sense to throw your hands up and say "we know about a bias on our measurements, but we're not going to use that information to try to remove the bias".
Re: (Score:2)
The thing is, while there might be a function to correct the bias, that function most likely can't be applied to the "end result". For example, you can't just substract / add something to the distance calculated.
I suspect what they do is calculate the distance travelled between two measurements, and then add up that calculated distance. Which of course is a horrible way to do it, since in amplifies the errors in the location into bigger and bigger errors in distance.
They basically need to apply "smoothing"
Re: (Score:2)
Your accelerometer can give you a very good reading of zigzagginess that can bias the correction accurately.
less than 1% error in our driving testing (Score:2)
We tested a gps a couple of times over a few miles each time. This was using a handheld Windows device, for which my friend built software to function as a taxi meter.
I think TFA tried to measure distances that are two small - 1 meter and 10 meters. It describes one source of error - random errors increase the measured distance. However, there is another source of error in the opposite direction which compensates for the first. Due to sampling occasionally, the GPS-based measurement measures a curve as
Consider a Fractal Cow (Score:5, Interesting)
Imagine for a moment that instead of going from point A to point B, you instead Zigged at 45 degrees then half way you Zagged back on the slant path to point B. Clearly then your total trip is sqrt(2) times the straigtline distance. But you went needlessly off the path. Instead we shall imagine that we can detect when we have deviated by 1 foot from the straight path. So we now execute a zig zag (45 degree) path turning each time we deviate by 1 foot from the true path. How far did we go? Oh my, it's still sqrt(2) times the straight line. We work hard and improve the duidance system so we now can detect when we are 1 micron from the straightline path. How far? still sqrt(2) times the straight line.
Indeed no matter how accurate we can detect the deviation so that the true path is beyond the capacity of any instrument to measure the deviation, say 1/100th of angstrom the same logic holds.
ergo all paths between A and B including the straight path are 1.41 times the straighpath distance.
Fractal hamburger.
Understatement of the day (Score:5, Insightful)
"it can be more than 20%" -Yeah, it can be an infinite number of %, if the actual distance travelled is zero, and the random error is not.
Re: (Score:2)
"it can be more than 20%" -Yeah, it can be an infinite number of %, if the actual distance travelled is zero, and the random error is not.
The infinite case is probably the most common, too, since the real motion of an apparently stationary device is smaller than the granularity of the position reading. People are just sleeping peacefully, not even realizing that their GPS positional error is infinite.
Re: (Score:2)
Real world, it's insignificant - especially with regard to what the summary refers to - " It is something that runners and walkers complain about a lot."
Basically, it overestimates because most of the random errors cause the measured distance to be further. Picture an arc with the center at one point, and the arc passing through the other. That's an equal-distance line. The closer the two points, the more over-distance bias there is. The farther betw
Re: (Score:2)
In any case, the bias cannot be more than the GPS positioning error, maybe a couple of meters if you're having a bad day. I'd like to know who these runners/walkers are who are complaining about an extra meter or two.
"an extra meter or two" every 10 meters can add up to a huge distance over the course of a couple miles.
Re: (Score:2)
Re: (Score:2)
"it can be more than 20%"
Yeah, it can be an infinite number of %, if the actual distance travelled is zero, and the random error is not.
That's an odd use case for a GPS.
Areas and volumes, not lengths (Score:1)
Re: GPS is not always GPS (Score:2)
The military uses more accurate GPS than us lowly civilians. Something about the ionosphere.
Perhaps this explains my Garmin (Score:4, Informative)
Re: (Score:2)
According to this article (okay, okay, the summary), GPS error causes measured distances to be systematically overestimated.
What you're talking about -- a different but noticeable factor -- is that GPS polling frequency causes measured distances to be systematically underestimated. Because it's only sampling once every N seconds and then, because there's quite a bit of noise, applying a smoothing function to the result, it cuts the corners off of paths. It can cause pretty substantial underestimation, even
Re: (Score:1)
Re: (Score:2)
If you are running on a track your Garmin watch is accurate enough to underreport when worn on your inside wrist and overreport when worn on your outside wrist.
If you are running on a track and the polling frequency of your GPS is too low (not a factor with my Garmin) you also get the problem of underreporting due to chording the curve.
Re: (Score:2)
About the current pace, that's a bit to be expected. I noticed it's doing error correction as well, where at first it seems to under-report, and the next 30 seconds it's claiming I'm running much faster.
And where does "velocity" come from? (Score:2)
GPS is a position determination technology. GPS-based "velocity" is calculated by GPS device based on change in position (distance) and time. It is subject to exactly the same error as the position itself.
Apropos, in the GPS navigation software I work on, tracking uses adaptive smoothing precisely for the purpose of reducing the distance error.
Doppler Shift (Score:2)
A very common way to get better velocity data (used for example in consumer grade ublox and mediatek receivers) is to directly measure the doppler shift of each satellite signal. Since you accurately know where each satellite is and their velocities, you can use the doppler shift between each satellite's signal to determine your own velocity with respect to them. The main advantage of this technique is that it is not affected by atmospheric propagation-delay variations (the signal might come later, but the
Re: (Score:2)
Re: (Score:2)
Sorry, that's simply wrong:
The basic output (usually once per second for most GPS chipsets) consists of 7 parameters:
X,Y,Z and dX,dY,dZ along with T, wth the x,y,z values in an Earth Centered Earth Fixed coordinate system. I.e. velocity is an intrinsic output of the processing, resulting from the need to determine doppler values for all visible sats in order to track them.
Past this point many GPS units will do lots of post-processing, for some of them this includes using a lowpass filtered velocity model th
Re: (Score:2)
If you work on GPS navigation software, you must be aware that GPS computes an instantaneous speed using doppler shift of the satellites. This is completely different from position delta based speed calculation.
Re: (Score:2)
I would bet you though that 100% of the smartphone software used for tracking runs does not do that.
90% of the software used however does smooth out using one algorithm or another the run, because the coastline effect is too noticiable(basically if you had infinitely small polling time, the route would appear infinitely long)
Quite the opposite (Score:2)
My experience is that my iPhone under reports my runs by at least 100m every 5km (I get variances of 100-300m under reported for the same 5.7km loop that I run once it twice a week.
I ran the Richmond-upon-Thames 10k last year and after crossing the line I had apparently only gone 9.8km. Other people at the finish mentioned their Garmins had reported even less. I wrote an email to the organiser who came back to me with a plausible explanation and a defence that they were IAAF measured (with a certificate c
Re: (Score:2)
It would be genuinely easy to build an Arduino (or whatever)-based GPS logger for under $50 that would let you actually set the GPS frequency, support PPS, etc. A GPS module with a nice big antenna is about $13. An SD card reader module is $3. Arduino Nano clones are $3. All the code can be filched from examples.
Re: (Score:2)
I am pretty sure that this means you just don't understand the problem. I encourage you to reread it. (I haven't read it but I understand the math.) Kalman filtering (LQE, if you prefer) may reduce the errors but I assume that's already being applied by the software. You'd need to adjust it - probably specifically for the timing and inherent inaccuracies. It almost certainly wouldn't be a complete solution and, importantly, is quite likely to be already applied.
The interesting bit (Score:2)
The interesting thing about this is not that they've found an explanation for why a GPS always overestimates (which is pretty obvious), but rather that they've taken the time to work out the statistics and quantify this overestimate. Imagine a GPS implementing this, and therefore able at any point in time to give the expected error. It might tell you that it measured a path of 10 km, but that, because of the type of noise present, the actual path was probably closer to 9 km. You could even take that a bit f
Fantastic math there, guys (Score:5, Interesting)
This gem caught my eye:
That's some amazing math there. (1.2 m - 1.0 m) / 1 m = 0.2, indeed a relative error of 20%. But (5.6 m - 5.0 m) / 5 m = 0.12, a relative error of 12%, not 60%! So, let's fix this thing, with of course the opposite conclusion:
Re:Fantastic math there, guys (Score:5, Insightful)
It's not just that they can't even determine that it was 12% in that case. They're simply doing it wrong from the beginning. "Let's take a technology that gives us a measurement that contains a possible error of more than the length we are trying to measure, and then complain about how much of an error we got in that length!" The best accuracy I've ever seen reported on my GPS is 2 m. Why would I try to measure 1 m with that?! Go do the experiment with a 10 km square and see what your error is then. *sigh*
Re: (Score:2)
Re: (Score:2)
Exactly. If the resolution on my measuring device is 2 m then all I can measure is multiples of 2 m, so 2 m, 4 m, 6 m, etc. This is perfectly acceptable for distances many times greater than 2 m, and would give me a pretty accurate measurement of a 10 km distance. I would be very happy with the amount of error present in a 10 km measurement made with such a device. But I couldn't measure 1 m with that any better than I could measure the spark plug gap for the plugs in my car with it.
No sh*t (Score:1)
Just go by time, forget distance (Score:2)
If you are running while on a work trip, maybe it helps but again, but you probably are just trying to get your workout before your meeting; fussing with workout tech just adds stress and that's what you are trying to combat with the run!
If you are running on vacation, what the hell is wro
What? (Score:2)
A trivial calculation (really, I figured that out a long time ago), with a non-trivial solution.
*Ideally* you would not use the GPS signal with a Kalman filter in the input, but for distance calculations en the end of the trip you should use a variant of the filter which can "look into the future" for each point.
While the best estimate for the position at any given point in time can only be based the past data (and Kalman filters are ideal for estimating this under this condition), the estimation of a point
Unless you run in a circle (Score:1)
... like on a track. In which case it'll cut the corners and underestimate.
misleading headline (Score:2)
In case it was not clear to everyone reading TFS, "GPS Always Overstimates Distances" is incorrect. The point of TFA is that, on average, distances are overestimated. GPS distance estimates are subject to random error, and the random error is biased. So more often than not, the estimate will be too large, but not "always". A better headline would have been, "GPS Usually Overestimates Distances". Less sensational, but more accurate.
Haha, explains fudge factor in my app... (Score:2)
So, a few years ago I wrote a "Taxi Meter" app for iPhone (though got bored and never released it...).Not meant to be a real taxi meter, but a novelty, say to get the kids your ride-share partner to get a grasp how much running around you are doing, and what it would cost to get a taxi instead...
I had to multiple by a fudge factor
The fudge factor was good enough - it got it well under the 2% required for a real taxi meter. I checked it by driving specific routes and then plotting the routes on Google Ear
Not GPS but some silly mapping application (Score:1)
Researchers? (Score:2)
You need to be a researcher in order to rediscover the effort of noise on sampling?
Or not (Score:2)
Just do course smoothing and you can reduce the bias to zero.
Either way I don't know what my watch does but I have 5 marathons recorded and the recorded distances ranged from 41.95 to 42.5. Being Boston Qualifiers they were at least 42.195 so 4/5 were overestimates and a total error of less than 1%.
I also do a series of XC races where the published distances (measured by mountain bike) are notorious for being 5-10% longer than peoples GPS. Assuming the bikes aren't horribly calibrated the explanation is the
The GPS trail distance problem (Score:2)
I hike with a club two days a week, and on every outing there are several of us who measure distance and elevation change with a GPS. Our distance measurements are always different, because of the interval between readings for each device.
Imagine a twisty trail being hiked. Whenever your GPS takes a reading, it's like pushing a map pin identifying one specific point on that trail. Think of your device's distance measure as a thread stretched from pin to pin all the way along the trail. See how the sum of al
Drunken walk (Score:2)
A similar effect can be obtained when walking (don't recommend driving) home from the pub on a friday night. The distance seems twice as far....
Another reason linking up with the car is useful (Score:1)
The car can report its current velocity and compass reading, something that phones have a hard time doing on their own. For this reason and others, I look forward to a proper car to phone interface.
that's news? (Score:1)
Path Jitter, integrated (Score:2)
Likely the GPS is subject to path jitter. You might run in a straight line but the GPS path will suffer jitter of 10's of meters or more to each side of your straight path. For overall distance it adds up all those imaginary zigs and zags and boom, long run.
It's all about Jensen's Inequality (Score:1)
Jensen's inequality [wikipedia.org] says that if f(x1, ..., xn) is a convex function (curving upwards in all directions), and (x1, ..., xn) is a random vector, then the mean value (probability-weighted average) of f(x1, ..., xn) is higher than f evaluated at the mean value of (x1, ..., xn). It's easy to see this if n=1 and there are only two possible values of x, because the line drawn from (a, f(a)) to (b, f(b)) always lies above the graph of the function f.
If you take f(x1, x2, x3, x4) to be the measured distance betwee
Doppler Velocity and Uncorrelated Position Errors (Score:2)
The authors suggest that doppler velocity calculations should be immune to the kind of overestimation they claim sampling position measurements suffers from. I don't think this can be the case.
Let's first focus on what is wikipedia claims is the largest source of error: signal delay from the ionosphere. It seems reasonable to assume that this delay changes in a continuous manner with time. However, that means that the (non-shared) error introduced into position measurements as a result also shows up in t
Not always (Score:2)
GPS Always Overestimates Distances
Only if you travel in a straight line (and even then, only if you calculate your distance based on all your way points, and don't just use your start and end positions). That's why I zig-zag everywhere I go.
Not surprising (Score:1)
This news is not surprising to me, although in my case it seems to go both ways. I've run races with a BibTag while tracking it on my phone and so far, it either comes up short or makes me a faster runner than the official time registration.
I also map out routes beforehand sometimes and I always try to make the mapped route a little longer so I know the GPS will go the distance. Not 20%, though.
Two Things (Score:1)
1) Set your Garmin sampling frequency to 1-second. Always. The default of "auto-magically" or "as-needed" is not sufficient. Especially when doing a run or bike ride on a course with lots of turns or on a track.
2) If the over-estimation is fairly consistent, then what does it really matter to the average amateur? If a route that you regularly time is actually 5 miles and not really 5.15 miles, who cares? What matters is your time over that same distance. It's a like a scale that is low by 2 pounds. It doe
Re:Shortest distance is not a straight line (Score:4, Insightful)
While technically correct, your correction is not really relevant to the discussion... Add random noise to the ideal arc and you get the same result - error that always goes up, never down.
Re: (Score:2)
Yes, but random errors will increase the total distance traveled, independent from this kind of inherent estimation error.
Re: (Score:3)
No, measurement error will actually bend space time.
Re: (Score:2)
The shortest distance between two points on the surface of the earth is not a straight line. It is a path that follows the curvature of the earth.
The shortest distance is a chord that goes beneath the surface of the earth.
That's going to get my shoes dirty...
Son of a ditch!
Re:Strange reasoning and I'm no geometer but... (Score:4, Interesting)
You're missing something.
Imagine you're running along in a one dimensional world. Any positioning errors will move any two points either directly towards each other or away from each other. The average bias should be zero.
If you allow two dimensions, errors can now occur to the right and left of your path, even if you're still running along in a straight line. Any lateral error, right or left, will increase the measured distance between points. That's where the bias comes from.
If I followed your post correctly, the effect you're referring to is the same as the interpolation error mentioned in the article, and actually tends to decrease the measured distance.
Re: (Score:2)