地理空间路由答案

【问题标题】：Geospatial Routing地理空间路由
【发布时间】：2012-01-21 06:05:13
【问题描述】：

我是一名物流程序员，有人要求我确定 GPS 点是否“偏离路线”，其中路线由多个地理空间点（纬度、经度）组成。

确定一个点是否在路线附近的最佳算法是什么？我将使用 C# 和 SQL Server，但如果我知道要使用什么算法，那真的没关系。

我考虑过

查找最近的两个点并确定三角形的面积是否超过特定限制。
对所有点对使用矢量，然后检查其中任何点是否与 GPS 点定义的矢量以及我确定为路线中“下一个”的点“相似”。

我没有数学学位，但只要有正确的术语和搜索引擎，我就可以处理任何事情。

我必须每小时至少进行 4000 次计算，因此由于体积的原因，使用映射解决方案可能是不可接受的。

【问题讨论】：

你问的是一个有趣的问题。这种三角形的表面积解决方案不起作用，因为相距很远的两个点会生成一个表面积很大的三角形，即使该点只是稍微偏离路线。不确定我有更好的解决方案。感谢您给我一些思考。
您使用的是什么版本的 SQL Server？除了纬度/经度之外，您是否有关于巴士位置的属性？可以将公共汽车 ID、路线 ID 等绑定到它应该在的正确道路/路线上怎么样？
@RyanDalton 2005 不幸的是。据我了解，2012 年有一些关于空间数据的非常好的功能。我不喜欢使用 mongo 或其他一些数据库，但这最终将需要更多的工作来设置和维护另一个具有实时信息的数据库。
@BrianWillis 是的，这就是我提出这个问题的原因。我想那会奏效。也不会找到 GPS 点到相关线路的距离。

标签： math c#-4.0 geospatial

【解决方案1】：

我必须每小时至少进行 4000 次计算，因此使用由于体积，映射解决方案可能不可接受。

事实上，这是一个完美的例子，其中映射解决方案将是有益的。不是您传统的“查看地图并确定距离”，而是“让数据库确定离您的 GPS 点最近的路线。

既然你说你不反对使用不同的数据库，你可以考虑：

SQL Server 2008，具有Spatial Database Engine 函数，或
带有开源 PostGIS（空间）扩展的 PostgreSQL，它具有比 MS SQL 2008 更多的空间分析功能。

看看 PostGIS ST_Distance 函数或 MS SQL Server 2008 STDistance 函数。这是一个很好的blog entry，它描述了 SQL2005 与 SQL2008 的优势。

您也可以考虑在gis.stackexchange 阅读（或询问更详细的映射）帖子。整个小组都致力于空间分析。一些不错的讨论供您查看

【讨论】：

谢谢。我有一个朋友也向我推荐了 gis.stackexchange。速度是我对使用映射解决方案的关注。我必须每小时至少完成 4000 次。但你是对的可能是最准确的解决方案。

【解决方案2】：

Google 搜索“Along-track distance”，您应该会找到航空中常用的公式。或者，cross-track distance 也可能是您想要的。

【讨论】：

谢谢，这看起来就是我正在寻找的答案。

【解决方案3】：

下面的怎么样...

遍历所有线段

lineSegSlope = 计算每条线段的斜率

从与当前线段相交的点画一条假想线。这是通过反转 lineSegSlope 并乘以 -1 以获得新的斜率来完成的，然后将目标点 X、Y 和新斜率替换为 y-y1 = b * (x-x1)。你的 X 进入 x1，你的 Y 进入 Y1，你的 newSlope 进入 B。

为线段做一个方程。

如果将两条线相互重叠，它们应该在每个角为 90 度的地方形成一个 X。

计算两条线的交点

计算交点和新点之间的距离。如果它大于某个可容忍值，那么新点就太远了。

这看起来像一团糟，但希望它可以工作。

【讨论】：

路线上的点与相关点的角度是我推理出来的原因。如果线段距离该点较远，但路线两点的角度使得该线在延伸时非常靠近该点，则会产生错误答案。我有点难以理解这一点，所以我可能对此有错误的回应。
我明白你在说什么，很好。我认为在这种情况下，线段的实际末端将是最近的点。然后，您可以计算从目标点到线段末端的距离。你在这里遇到了有趣的小问题。

【解决方案4】：

您能否将现有路线作为二维线段序列，然后获取您的查询点并找到最近的点和最近的线段？到最近的点/线段的距离就是您关心的距离。

如果您坚持使用相对较低的纬度（低于 60 度），您可能可以将纬度和经度视为简单平坦的，就像在墨卡托投影上一样。

如果不是，那么您可以将坐标系转换为相对于穿过某些路线点的大圆。

除非您要处理数百万个路由点，否则 CPU 时间应该不会有问题。

【讨论】：

这是我考虑过的公式之一，但我发现根据路线的形状它不起作用的情况。他们中的大多数人都不在一条直线附近，其中一些人会自己翻倍。当涉及到时间时，它会变得更加复杂，但我把它留到另一个问题上。

【解决方案5】：

一种天真的方法是在沿途的各个位置插入新的 GPS 点。首先将其插入到您的第一个点 P0 之前，然后在您的第一个和第二个点 P0 和 P1 之间，依此类推，直到您尝试将其作为最后一个点插入。每次尝试将其插入某个位置时，计算电路的总距离并保存最短的总距离。这可以通过预先计算腿部距离并存储该总和来加快速度。通过减去要插入新点的腿的腿距离来检查距离，然后将点 P(n) 到 GPS 点的新距离添加到 P(n+1)。如果最短的总距离在您的容忍范围内，您可以接受。

这可能不是“最佳”算法（取决于您对最佳的定义），但对于时间和空间复杂度而言，路线中的点数为 O(n)。因此，除非您的路线中有大量点，否则每次检查应该不到一秒，所以这应该在您的时间要求之内。

另外，在计算路线上连续点之间的距离时，请务必使用 haversine distance equations。

【讨论】：

对我来说最好的是在很大一部分情况下快速准确。当路线中点之间的距离更大时，这种情况下的容忍度需要增加，不是吗？