Apple 回复了我就这个问题提出的技术支持请求。
统计意图是什么，即使是近似值
返回“准确性”还是“不确定性”？
没有适用于 iOS 的。我无法评论 Android 的位置 API/硬件，但我认为为什么下面的描述会在 iOS 上灾难性地失败应该能说明问题：
“我们将准确度定义为 68% 置信度的半径。换一种说法，
如果您以该位置的纬度为中心画一个圆，并且
经度，半径等于精度，则有
真实位置在圆圈内的概率为 68%。在
统计术语，假设位置误差是随机的
一个正态分布，所以 68% 的置信度圈代表一个
标准差。请注意，在实践中，位置错误不会
总是遵循这样一个简单的分布。
问题的症结在于，假设错误是正态分布的，这在 iOS 上是无效的。目前，CoreLocation 的位置信息依赖于 3 个位置源，并且每一个都具有完全不同的故障特征。
-手机信号塔。从错误的角度来看，这些实际上是最简单的建模。蜂窝无线电信号不是特别反射的，并且所涉及的距离足够大，以至于反射率影响相对较小并且（更重要的是）在一般区域内通常是一致的。中心位置是最有可能的位置，离中心点越远，可能性越小。
-GPS。 GPS 通常被认为是定位的“黄金”标准，但尤其是在城市环境中，这可能会产生严重的误导。问题是 GPS 信号比蜂窝信号更容易反射，它可以并且将会从根本上改变设备的已知“位置”。在密集的城市景观中，在步行/驾驶非常笔直的路线时，经常会看到疯狂和随机的设备转移。除了那些突然的变化（根据特定应用程序的用例相对容易过滤掉）之外，系统故障也很常见，其中特定区域的特定几何形状显着改变了“GPS位置”
从它的真实位置。
-WiFi。在许多方面，WiFi 是最棘手的。问题在于，对于单个基站的最简单定位情况，除了“靠近基站的某处”之外，不可能推断出任何真实的位置信息。可以根据信号强度推断出有关径向距离的一些信息，但结构架构对信号强度的影响往往大于距离，因此该数字相当无用。更重要的是，根本没有方向信息可用。然而，更大的问题是 WiFi 位置依赖于 WiFi 热点的注册位置……如果数据库完全错误怎么办？举个例子，几个月前，我与一位开发人员一起工作，他非常生气，因为他收到了一个位置跟踪，显示该设备在整个 3 小时的车程中完全静止。经过大量调查，最终确定他会：
a) 把他的手机放在一个包里，包在他的前座下面（切断 GPS 和手机信号塔）。
b) 将他的 MiFi 个人热点保持在整个驱动器上。
...在早些时候，iOS 已经针对该 MiFi 注册了一个位置，因此它很高兴地认为该设备在整个旅程中都是静止的。
最后，CoreLocation 在此基础上增加了它自己的复杂性。它知道所有这些问题，并根据它收集的所有数据提供/推断它是对“真实”位置的最佳猜测……但这只是第一步。 CLActivityType 是 API 的一部分的原因是为 iOS 提供有关设备使用方式的更多信息，以便它可以代表您过滤数据。如果您在城市环境中以高精度跟踪同一驱动器，两台设备，但一台设备设置为“CLActivityTypeAutomotiveNavigation”，另一台设置为“CLActivityTypeOther”
并比较数据，你会发现你得到了非常不同的数据点。这并不是因为这些设备实际上正在接收完全不同的数据。相反，CLActivityTypeAutomotiveNavigation 正在查看它接收到的位置，或者延迟它认为有问题的事件传递（“汽车真的开到路肩上”），或者如果它们看起来不合理（“不，我不认为汽车向左移动 100m，然后在 1-2 秒内回到原来的位置……”）。
所有这一切的结果是，用数学术语来思考错误根本没有帮助。真实情况是，该设备可能位于水平精度半径内的某个位置……除非不是。试图推断用户在该半径范围内的位置不会很好地结束
一般来说。
具体来说，在两个设备的假设情况下
相同的 GPS/定位硬件，在相同的物理位置，具有
在同一时刻以相同参数查询 GPS 地理定位
时间，Android之间最典型的关系是什么
返回值（径向 1 个标准偏差不确定性）和 iOS
价值？
坦率地说，我认为这在一般情况下是做不到的。我的猜测是，对于最简单的情况，例如开放场地中的 GPS，这些设备将返回基本相同的数据。另一方面，当在现实世界中更复杂的环境中使用时，我预计设备会出现不可预测的差异，并且没有真正的方法来纠正这些设备差异。
DTS 中的 KevinE（Apple）