GIS数据库中是否有更新的路由算法（比Dijkstra，A *）？

诸如微软研究人员的Reach for A *和Sanders和Schtolz的Highway Hierarchies（如果我正确拼写名字的话）都来自Karlsruhe Uni。两者都大大减少了计算顺序，并在大型图形上加快了数千倍的速度（请参见链接文档中的结果）。后者的工作导致了开源路由机器，不幸的是，它不够流行，并且没有适应（尽管努力了，但我无法编译）。

同时，根据他们的文档，我尝试过的数据库Spatialite和PgRouting仅提供Dijkstra和A *算法。我什至都没有提到双向搜索，根据我的经验，它可以节省两次计算时间。

是否有针对数据库或其他应用程序的更好算法？

事实是，大多数人都使用A *算法的自定义变体。您会在大多数“大人物”中看到这一点（我不能说他们在公共论坛上是谁，但我可以告诉您您可能使用了其中的一个-保证），其中启发式的修改是非常依赖于他们使用的数据集。

您已经提到过灌浆，我认为这是“传统”的选择。这对于执行简单的路由算法和大多数问题非常有用。它也易于使用，并且在后端使用传统数据库。

但是，这实际上取决于要解决的问题的规模和类型，而布线是图形问题。

再一次，“大佬”通常会拥有许多与他们的图表相关的数据（例如，交通数据，公交路线，人行道），这些数据会影响路由算法。这些被称为多模式旅行计划者（在这里，您还可以选择“模式”的计划-没有自行车道-只有公共交通-这种事情）。你可以想怎么行程规划也成为一个时间敏感的问题（例如，如果你走回来的几个边缘回来，你将能够赶上，把你带到目的地的地铁前锋比，如果你只是试图向前导航边缘快得多使用最低的费用）。

“大佬”本身并不将数据存储在传统数据库中，而是使用预先计算的图（欢迎使用hadoop / mapreduce集群！）。可以想象，这些图非常大，因此知道如何连接相邻图的边缘可能是一个挑战。

无论如何，我建议您看一些多模式路由图项目：

Graphserver浮现在脑海。没有太多的文档，但是有很多纯净的代码编写能力（AFAIK，我相信MapQuest在某些路由产品中使用了该项目的变体）。

另一个选择是OpenTripPlanner，它背后有很多聪明的人（包括来自graphserver的人）。

不知道它是否较新，但是pgRouting具有Shooting-Star算法：

流星算法是pgRouting最短路径算法中的最新算法。它的特长是它在链接之间进行路由，而不是像Dijkstra和A-Star算法那样从一​​个顶点到另一个顶点。例如，这使定义链接之间的关系成为可能，并解决了其他一些基于顶点的算法问题，例如“并行链接”，这些问题的来源和目标相同，但成本却不同。

ESRI的Network Analyst扩展使用您提到的分层方法来限制求解时间：

由于需要搜索大量的边，因此在全国范围的网络数据集上查找确切的最短路径非常耗时。为了提高性能，网络数据集可以在交通系统中对自然层次结构进行建模，在该系统中，州际公路上的驾驶比本地道路上的驾驶更可取。一旦创建了分层网络，就可以使用双向Dijkstra的修改来计算起点和终点之间的路线。

ESRI网站上有非常详细的白皮书，其中包含有关此方法的示例-但是，您需要登录才能下载（ArcGIS Network Analyst白皮书中的“分层路线”）。

收缩层次结构是一种非常快速的算法：

• http://algo2.iti.kit.edu/1087.php

该算法在执行查询时对RAM友好（要保留一个收缩的图，还需要更多的RAM以及大量的预处理）

还有其他一些算法-包括解决公交路线的算法：

• http://i11www.iti.uni-karlsruhe.de/members/thomas_pajor/publications

微软也在做一些研究：

• http://research.microsoft.com/en-us/people/dadellin/

（恩，丹尼尔·戴林（Daniel Delling）也是来自卡尔斯鲁厄的人）

您可以很好地介绍和概述可用算法：

• http://i11www.iti.uni-karlsruhe.de/teaching/sommer2012/routenplanung/index

警告：德语（！）讲座。但至少标题可以帮助您获取更多信息（ALT，Arc-Flags，CHASE等）或随附的文献！

更新

GraphHopper现在实现了收缩层次结构以及其他算法，您也可以尝试演示。