不仅仅是一首伟大的绿洲之歌…这是一个特殊的情况下要注意使用HANA地理空间功能。这对一些人来说是显而易见的，但这里有些东西并没有很好的记录，我觉得值得分享。当天的挑战是将全球约10万个气象站的信息与附近的世界城市联系起来。这部分意味着将地理坐标信息（即经纬度对）保存在数据类型为Stu POINT（4326）–WGS84国际标准的列中，并使用Stu DISTANCE方法返回它们之间的距离。很简单。

很快，我就注意到了一些奇怪的事情——尽管几乎每个城市/车站的人都表现得和预期的一样，但有一小部分人却得到了一些荒谬的结果。这里有三个这样的例子，以及海德堡的一个合理的结果（对不起，关于大数据，SAP，Walldorf不在我的表格中）。

在第一个例子中，我的查询告诉我，离新西兰奥克兰最近的气象站在Moron de la Frontera…一个西班牙空军基地…在地球的另一边。我的直接假设是我在select语句中做了一些愚蠢的事情，或者格式化了一些错误的数据。为了检查健康状况，淘客源码，我查了每个地区的坐标。

奥克兰：（174.764980799，服务器租用，-36.850013）西班牙气象台：（-5.6，37.1833）。

快速查看谷歌地图显示，这确实是正确的……当然，在他们各自的街区。所以坐标看起来没问题，我甚至没有落入新手陷阱，把经纬度顺序弄错。（对于不熟悉的人来说，STèu POINT是按（long，西安大数据，lat）顺序排列的，这与更常见的呈现方式相反，后者有（lat，lon）。我觉得有点烦人）。显然是别的原因……

我认为尝试手动构建点是个好主意，以防我的选择或计算视图逻辑出现错误。这也给了一个零的距离。

现在让我们移动一个点，非常轻微。

天哪！现在我们看到了大约20000公里的正确距离？我们所做的只是把其中一个点移动了大约5公里——你可以在地图上看到它仍然在同一个区域？是不是因为军事基地是WGS84标准的限制区？

嗯……可能不是。让我们再试试我的另一对不起作用的。

这是中国深圳市（114.122123099，22.55237051）：

还有一个气象站在拉奎卡，阿根廷/玻利维亚边境的一个沉睡的小镇。（-- 65.6，-22.1）再一次，这些点手动地给出了零的距离。在这一点上，我看到了La QuaCa的维基百科文章有一个有趣的句子："参见"，我告诉过你……对于那些不熟悉亚洲地理的人来说，让我们放大深圳，看看它在哪里……因此，云服务器的，我们似乎找到了罪魁祸首。

在所有情况下，显示为零距离的成对距离都尽可能远，以到达地球的另一边。

在这些极端情况下，距离公式往往会有点崩溃。让我们进一步深入研究这个问题。

我相信SAP HANA中的STèu DISTANCE的实现使用了Vincenty的逆公式，您可以在这里阅读所有的内容。

数学可能对您意义不大，但最后有一点值得注意：

这正是这里发生的情况。

为了进一步支持这一点，我找到了一个带有这里显式地使用了Vincenty的公式

它附带了一个类似的警告：

而且很确定，我的坐标对抛出了一个"不是数字"的错误

所以你得到了它。如果您正在实施任何类似的地理空间项目，请务必仔细检查并防止反脚架故障。

在我的情况下，我做了一个单独的视图来显示精确零距离的对，并手动确认结果。

我希望有一天这可以帮人省去头痛。

祝您好运，找虫愉快！