0

我阅读了这个问题并在 Python 中实现了公认的答案（见下文）。它原则上有效，但结果始终比预期高出约 30%（捷克共和国）——这是该算法的预期准确性吗？

为了验证算法，我使用BoundingBox得到一个对角距离已知的边界框（建筑物，两个城市），并使用输出坐标作为“我的”算法的输入。

问题出在哪里？

  • 我的实施？
  • 算法本身？
  • Python？
  • 测试？

我的实现：

R= 6371 #km
dLat = math.radians(lat2-lat1)
dLon = math.radians(lon2-lon1)
lat1 = math.radians(lat1)
lat2 = math.radians(lat2)

a= math.sin(dLat/2)*math.sin(dLat/2) + math.sin(dLon/2) * math.sin(dLon/2) * math.cos(lat1) * math.cos(lat2)
c= 2 * math.atan2(math.sqrt(a), math.sqrt(1-a))
d = R * c;
return d
4

1 回答 1

3

不，该算法不应该有那么大的误差。该链接指定您可以预期大约 0.3% 的错误。

我无法用您的代码重现您的结果，所以我相信错误在于您的测试。

以下是来自一个站点的一些测试数据，其中布拉格和布尔诺之间的距离和坐标采用十进制度格式：

lat_prague, long_prague = 50.0833, 14.4667
lat_brno, long_brno = 49.2000, 16.6333
expected_km = 184.21

以下是测试结果：

>>> def calc(lat1,lon1, lat2,lon2):
# ... your code ...

>>> calc(lat_prague,long_prague,lat_brno,long_brno)
184.34019283649852
>>> calc(lat_prague,long_prague,lat_brno,long_brno) / expected_km
1.0007067631317437

一个疯狂的猜测：对于捷克共和国的位置，你得到的错误似乎在正确的数量级，因为混合了纬度和经度：

>>> calc(long_prague,lat_prague,long_brno,lat_brno)
258.8286271447481
>>> calc(long_prague,lat_prague,long_brno,lat_brno) / expected_km
1.405073704710646

这显然是一个已知的混乱。仅指定为一对数字的坐标是不明确的（例如：BoundingBox 和上述距离的参考都使用 (long, lat)，并且算法使用排序 lat, long）。当您遇到具有不熟悉的数据源而没有正式规范的模棱两可的格式时，您只需要进行完整性检查。像维基百科这样的网站会毫不含糊地告诉你布拉格位于“50°05′N 14°25′E”——也就是说，非常粗略地，大约在纬度 50 度（南北）和经度 14 度（东西）。

于 2013-06-16T16:03:19.993 回答