Apple responded to a technical support ticket I raised on this question.
What is the statistical intention, even if an approximation, of the
returned “accuracy” or “uncertainty”?
There isn’t one for iOS. I can’t comment on Androids location APIs/hardware, but I think working why description below will fail catastrophically on iOS should illuminate things:
“We define accuracy as the radius of 68% confidence. In other words,
if you draw a circle centered at this location’s latitude and
longitude, and with a radius equal to the accuracy, then there is a
68% probability that the true location is inside the circle. In
statistical terms, it is assumed that location errors are random with
a normal distribution, so the 68% confidence circle represents one
standard deviation. Note that in practice, location errors do not
always follow such a simple distribution.
The crux of the problem is that assuming errors are normally distributed isn’t valid on iOS. Currently, CoreLocation relies on 3 location sources for it’s location information and each of those has radically different failure characteristics.
-Cell towers. These are actually the simplest to model from an error perspective. Cellular radio signals are not particular reflective and the distances involved are large enough that that reflectivity effects are relatively minor and (more importantly) generally consistent inside a general area. The center location is the most likely position with decreasing likelihood the further from the center point.
-GPS. GPS is general considered the “gold” standard of positioning but, particularly in urban environments, that can be deeply misleading. The problem is that GPS signals reflect much more easily that cellular which can and will radically alter the known “position” of the device. In a dense urban landscape, it’s common and expected to see rabid and random device shifts occur will walking/driving very straight forward routes. On top of those sudden shifts (which are relatively easy to filter out based on the use case of a particular app), systemic failures are also common where the particular geometry of a particular area has significantly shifted the “GPS location”
from it’s true position.
-WiFi. In many ways, WiFi is the trickiest of all. The problem is that for the simplest positioning case of a single base station it’s impossible to infer any real position information beyond “somewhere close to the base station”. Some information about radial distance could be inferred based on signal strength, but strutural architecture tends to effect signal strength more than distance making that number fairly useless. More to the point, no direction information is available at all. However, the bigger problem is that WiFi location relies on the registered location of the WiFi hotspot… and what if the database is simply wrong? Case in point, several months ago I worked with a developer who was quite angry that he’d received a location trace that showed the device as completely stationary for and entire 3 hour drive. After much investigation, it was eventually determined that he’d:
a) Placed his phone in a bag and the bag under his front seat (cutting off GPS and cell tower).
b) Left his MiFi personal hotspot on for the entire drive.
…At some earlier point, iOS had registered a location against that MiFi so it happily considered the device stationary for the entire journey.
Finally, CoreLocation adds it’s own complexity on top of this. It’s aware of all these issues and based on all of the data it’s gathering in provides/infers it’s best guess of a “true” location… but that’s really on the first step. The reason CLActivityType is part of the API is to give iOS more information about how the device is being used so that it can filter the data on your behalf. If you track the same drive one two device in an urban environment at high accuracy but with one device set to “CLActivityTypeAutomotiveNavigation” and the other to “CLActivityTypeOther”
and compare the data, you’ll see that you’re getting very different data points. This is not because the devices are actually receiving completely different data. Instead, CLActivityTypeAutomotiveNavigation is looking at the locations it’s receiving and either delaying event delivery it considers questionable (“Is the car REALLY driving onto the shoulder”) or dropping events entirely if they don’t seem reasonable (“No, I don’t think the car shift 100m to the left, then back to it’s original position over 1-2 seconds…”).
The result of all this is that think of error in mathematical terms simply isn’t helpful. The real truth is that the device is likely to be somewhere inside the horizontalAccuracy radius… unless it’s not. Attempting to infer the users position inside that radius beyond that is not going to end well
generally.
To be concrete, under a hypothetical situation of two devices with
identical GPS/location hardware, at the same physical location, with a
query to GPS geolocate with the same parameters at the same moment in
time, what is the most typical relationship between the Android
returned value (1 standard deviation uncertainty radially) and the iOS
value?
To be blunt, I don’t think this can be done in the general case. My guess is that for the simplest cases, like GPS in an open field, the devices will return essentially identical data. On the other hand, when used in the more complex environments of the real world I’d expect the device to diverge unpredictably and with no real way to correct for those device differences.
KevinE in DTS (Apple)
