定位精度定义 - iOS
Location accuracy defined - iOS
iOS 上返回的 "accuracy" 或 "uncertainty" 的统计意图是什么，即使是近似值？
例如 Android 文档将其返回的准确度数字解释为在这个意义上大约是一个标准偏差：
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. This accuracy estimation is
only concerned with horizontal accuracy, and does not indicate the
accuracy of bearing, velocity or altitude if those are included in
this Location.
我们的设置是，我们需要以与 Android 相同的定量方式处理从 iOS 返回的“准确性”或“不确定性”的值，以使我们能够构建应用程序具有有效相同的功能。是否需要对 iOS 的准确度结果进行任何转换才能获得与上述相同的解释？具体来说，假设两个设备具有相同的 GPS/location 硬件，在相同的物理位置，在同一时刻使用相同的参数查询 GPS 地理定位，两者之间最典型的关系是什么Android 返回值（1 个标准偏差径向不确定性）和 iOS 值?
Apple 没有记录这些细节。
GPS芯片制造商甚至没有记录这些细节。
在内部，此值源自 Gps 属性 "hdop"（或 hAccEstim 和 hdop 使用内部协方差），这是一个无单位的数字，表示与 1-sigma 值相关的精度因子。
大约 2.5 - 3.5 m。使用 WAAS 或 EGNOS（美国和欧洲）时，如果没有 GPS 校正，则为 5m。
因此，当 hAcc 基于 1sigma（或 RMS）时，美国和欧洲的平均设备应显示 3m。在ios上最低值为5m，这可能是一个固定的下限。
只能测量 ios 和 adroid 设备并比较 horrAcc 值。
如果他们 1:1 或 ios 使用因子 2，我不会感到惊讶。
(2DRMS) 这意味着该位置有 95-98% 的概率在半径内。
Apple 回复了我就此问题提出的技术支持请求。
What is the statistical intention, even if an approximation, of the
returned “accuracy” or “uncertainty”?
iOS 没有一个。我无法对 Android 的位置 APIs/hardware 发表评论，但我认为研究为什么下面的描述会在 iOS 上发生灾难性失败应该可以说明一些事情：
“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.
问题的症结在于假设错误呈正态分布在 iOS 上是无效的。目前，CoreLocation 的位置信息依赖于 3 个位置源，每个源都有截然不同的故障特征。
-基站。从错误的角度来看，这些实际上是最简单的模型。蜂窝无线电信号不是特别反射，并且所涉及的距离足够大，以至于反射率影响相对较小，并且（更重要的是）在一般区域内通常是一致的。中心位置是最有可能的位置，距离中心点越远，可能性越小。
-全球定位系统。 GPS 通常被认为是定位的“黄金”标准，但尤其是在城市环境中，这可能会产生严重的误导。问题是 GPS 信号比蜂窝信号更容易反射，它可以并且将会从根本上改变设备的已知“位置”。在密集的城市景观中，在 walking/driving 非常直截了当的路线上，经常会看到疯狂和随机的设备移动。除了那些突然的变化（根据特定应用程序的用例相对容易过滤掉）之外，系统性故障也很常见，因为特定区域的特定几何形状已经显着改变了“GPS 位置”
从它的真实位置。
-无线网络。在许多方面，WiFi 是最棘手的。问题在于，对于单个基站的最简单定位情况，不可能推断出“靠近基站的某处”之外的任何真实位置信息。可以根据信号强度推断出一些关于径向距离的信息，但结构架构对信号强度的影响往往大于距离，这使得该数字相当无用。更重要的是，根本没有可用的方向信息。然而，更大的问题是 WiFi 位置依赖于 WiFi 热点的注册位置……如果数据库完全错误怎么办？举个例子，几个月前，我与一位开发人员合作，他非常生气，因为他收到了一个位置跟踪，显示该设备在整个 3 小时的车程内完全静止。经过大量调查，最终确定他会：
a) 把他的 phone 放在一个袋子里，袋子放在他的前座下面（切断 GPS 和手机信号塔）。
b) 在整个驱动过程中让他的 MiFi 个人热点保持打开状态。
…在早些时候，iOS 已经针对该 MiFi 注册了一个位置，因此它很高兴地认为该设备在整个旅程中都是静止的。
最后，CoreLocation 在此基础上增加了它自己的复杂性。它知道所有这些问题，并根据它在 provides/infers 中收集的所有数据，最好猜测一个“真实”位置……但这只是第一步。 CLActivityType 是 API 的一部分的原因是为 iOS 提供有关设备使用方式的更多信息，以便它可以代表您过滤数据。如果您在城市环境中用一台两台设备高精度跟踪同一个驱动器，但一台设备设置为“CLActivityTypeAutomotiveNavigation”，另一台设备设置为“CLActivityTypeOther”
并比较数据，你会发现你得到了非常不同的数据点。这并不是因为设备实际上接收的是完全不同的数据。相反，CLActivityTypeAutomotiveNavigation 正在查看它接收到的位置，并延迟它认为有问题的事件传递（“汽车真的开到路肩上了吗”）或者如果它们看起来不合理则完全丢弃事件（“不，我不认为汽车向左移动 100 米，然后在 1-2 秒内回到原来的位置……”)。
所有这一切的结果是，用数学术语来思考错误根本没有帮助。真实情况是设备可能位于 horizontalAccuracy 半径内的某个位置……除非不是。试图推断用户在该半径范围内的位置不会有好的结果
一般来说。
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?
说白了，我觉得一般情况下是做不到的。我的猜测是，对于最简单的情况，例如开阔地中的 GPS，设备将 return 基本相同的数据。另一方面，当在现实世界中更复杂的环境中使用时，我预计该设备会出现不可预测的差异，并且没有真正的方法来纠正这些设备差异。
DTS 中的 KevinE (Apple)
iOS 上返回的 "accuracy" 或 "uncertainty" 的统计意图是什么，即使是近似值？
例如 Android 文档将其返回的准确度数字解释为在这个意义上大约是一个标准偏差：
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. This accuracy estimation is only concerned with horizontal accuracy, and does not indicate the accuracy of bearing, velocity or altitude if those are included in this Location.
我们的设置是，我们需要以与 Android 相同的定量方式处理从 iOS 返回的“准确性”或“不确定性”的值，以使我们能够构建应用程序具有有效相同的功能。是否需要对 iOS 的准确度结果进行任何转换才能获得与上述相同的解释？具体来说，假设两个设备具有相同的 GPS/location 硬件，在相同的物理位置，在同一时刻使用相同的参数查询 GPS 地理定位，两者之间最典型的关系是什么Android 返回值（1 个标准偏差径向不确定性）和 iOS 值?
Apple 没有记录这些细节。
GPS芯片制造商甚至没有记录这些细节。
在内部，此值源自 Gps 属性 "hdop"（或 hAccEstim 和 hdop 使用内部协方差），这是一个无单位的数字，表示与 1-sigma 值相关的精度因子。 大约 2.5 - 3.5 m。使用 WAAS 或 EGNOS（美国和欧洲）时，如果没有 GPS 校正，则为 5m。 因此，当 hAcc 基于 1sigma（或 RMS）时，美国和欧洲的平均设备应显示 3m。在ios上最低值为5m，这可能是一个固定的下限。
只能测量 ios 和 adroid 设备并比较 horrAcc 值。 如果他们 1:1 或 ios 使用因子 2，我不会感到惊讶。 (2DRMS) 这意味着该位置有 95-98% 的概率在半径内。
Apple 回复了我就此问题提出的技术支持请求。
What is the statistical intention, even if an approximation, of the returned “accuracy” or “uncertainty”?
iOS 没有一个。我无法对 Android 的位置 APIs/hardware 发表评论，但我认为研究为什么下面的描述会在 iOS 上发生灾难性失败应该可以说明一些事情：
“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.
问题的症结在于假设错误呈正态分布在 iOS 上是无效的。目前，CoreLocation 的位置信息依赖于 3 个位置源，每个源都有截然不同的故障特征。
-基站。从错误的角度来看，这些实际上是最简单的模型。蜂窝无线电信号不是特别反射，并且所涉及的距离足够大，以至于反射率影响相对较小，并且（更重要的是）在一般区域内通常是一致的。中心位置是最有可能的位置，距离中心点越远，可能性越小。
-全球定位系统。 GPS 通常被认为是定位的“黄金”标准，但尤其是在城市环境中，这可能会产生严重的误导。问题是 GPS 信号比蜂窝信号更容易反射，它可以并且将会从根本上改变设备的已知“位置”。在密集的城市景观中，在 walking/driving 非常直截了当的路线上，经常会看到疯狂和随机的设备移动。除了那些突然的变化（根据特定应用程序的用例相对容易过滤掉）之外，系统性故障也很常见，因为特定区域的特定几何形状已经显着改变了“GPS 位置” 从它的真实位置。
-无线网络。在许多方面，WiFi 是最棘手的。问题在于，对于单个基站的最简单定位情况，不可能推断出“靠近基站的某处”之外的任何真实位置信息。可以根据信号强度推断出一些关于径向距离的信息，但结构架构对信号强度的影响往往大于距离，这使得该数字相当无用。更重要的是，根本没有可用的方向信息。然而，更大的问题是 WiFi 位置依赖于 WiFi 热点的注册位置……如果数据库完全错误怎么办？举个例子，几个月前，我与一位开发人员合作，他非常生气，因为他收到了一个位置跟踪，显示该设备在整个 3 小时的车程内完全静止。经过大量调查，最终确定他会：
a) 把他的 phone 放在一个袋子里，袋子放在他的前座下面（切断 GPS 和手机信号塔）。 b) 在整个驱动过程中让他的 MiFi 个人热点保持打开状态。
…在早些时候，iOS 已经针对该 MiFi 注册了一个位置，因此它很高兴地认为该设备在整个旅程中都是静止的。
最后，CoreLocation 在此基础上增加了它自己的复杂性。它知道所有这些问题，并根据它在 provides/infers 中收集的所有数据，最好猜测一个“真实”位置……但这只是第一步。 CLActivityType 是 API 的一部分的原因是为 iOS 提供有关设备使用方式的更多信息，以便它可以代表您过滤数据。如果您在城市环境中用一台两台设备高精度跟踪同一个驱动器，但一台设备设置为“CLActivityTypeAutomotiveNavigation”，另一台设备设置为“CLActivityTypeOther” 并比较数据，你会发现你得到了非常不同的数据点。这并不是因为设备实际上接收的是完全不同的数据。相反，CLActivityTypeAutomotiveNavigation 正在查看它接收到的位置，并延迟它认为有问题的事件传递（“汽车真的开到路肩上了吗”）或者如果它们看起来不合理则完全丢弃事件（“不，我不认为汽车向左移动 100 米，然后在 1-2 秒内回到原来的位置……”)。
所有这一切的结果是，用数学术语来思考错误根本没有帮助。真实情况是设备可能位于 horizontalAccuracy 半径内的某个位置……除非不是。试图推断用户在该半径范围内的位置不会有好的结果 一般来说。
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?
说白了，我觉得一般情况下是做不到的。我的猜测是，对于最简单的情况，例如开阔地中的 GPS，设备将 return 基本相同的数据。另一方面，当在现实世界中更复杂的环境中使用时，我预计该设备会出现不可预测的差异，并且没有真正的方法来纠正这些设备差异。
DTS 中的 KevinE (Apple)