我正在开发一个Journey Planner网站。目前在这种情况下很少有简单的事情,即现在网站只能规划公交线路,目前公交车的时间不可用。所以这意味着我们只有存储在数据库中的总线路由,因为总线时序不可用,所以旅行者的等待时间也不相关。可用的是单个公共汽车两站之间的时间和距离。
我认为使用无向加权图存储每个公交车站的时间和距离成本是每条公交车的出路。然后我可以使用Dijkstra算法根据用户偏好计算用户根据时间或距离输入的两个位置之间的最短路径。如果公交车路线在停靠点相交,然后使用这些交叉路口以便旅行者更换公交车,我会发现是否需要通过简单的C#功能使用两辆或三辆公交车。但是每辆公交车都会有一张单独的图表。另一种方法(不确定这是否正确)的方法是使用包含城市的每个公共汽车站的图表作为节点,然后使用这种技术找出两站之间的旅行方式。哪种方法正确?我应该使用A *算法代替Dijkstra算法吗?
设计的一些一般要点:我希望应用程序是可扩展的,以便我可以在需要时添加其他传输方式。此外,如果可能的话,也可以在以后添加公交车时间而不对网站进行重大更改。我在这里见过很多专家,他们参与了许多复杂的交通项目。因此,请以最具扩展性,模块化和可扩展的方式帮助我实现此功能的最佳方式。
答案 0 :(得分:3)
图表必须是一个方向图 - 公路停在道路的两侧(即使在像英国这样很少有中位数的国家)也不是一样的停止!
答案 1 :(得分:3)
我去年夏天开始使用类似的应用程序并且从未完成它,但我对此图表有一些建议,以及如何构建数据。
我的计划是将每个停靠点作为节点,并在每次总线通过时在每个节点之间建立路径。例如,如果公共汽车在6小时内每半小时停一次,则两个节点之间将有12条路径。时间是路径“成本”背后的主要驱动因素,因此通常选择最快的路径。
在启动应用程序之前,将在接下来的5个小时内查询数据库中的所有路径(根据需要进行调整)。然后它将与Dijkstra的算法紧密相关。
考虑成本的其他因素包括路线的实际货币成本,转移(及其成本),没有屋顶的停靠点(如果您有恶劣的天气)等等。
这个计划对我有用。我住在一个有3个公共汽车系统的地区。
最后,以与Google Transit Feed Specification类似的方式构建数据可能对您有所帮助,因为许多代理机构都会生成您可以导入的此类数据。
答案 2 :(得分:0)
我认为最重要的优化是将您可以更改路线和车站的车站分开。然后,您只需要考虑可以将路径更改为图表中间工作站的工作站。这应该使图表变得如此之小以至于Dijkstra没问题。
我只用两条边来区分节点,只需将它们从图中切出,然后用增加长度的边连接它们的两个邻居。然后我在这个缩小的图上进行寻路,这应该快得多。即只考虑可以切换路线的站点。
答案 3 :(得分:0)
也许你可以使用paddydubs工作TransportDublin找到on github。
答案 4 :(得分:0)
我为测试应用程序编写了这样的算法。每个站点都有一本字典,作为源和目的地。该算法是递归的。递归的每一步都是这样的:给定源和目标,它将生成进入目标的路由列表,离开源的路由列表。如果有任何常见的停留,我们就完成了,我们报告了路线。如果没有,那么我为源生成相邻的停靠点并递归。下一个递归生成接收器的相邻停靠列表,递归。在递归之前,我记录了前一个路径,最后我会有一个列表。
我确实记得我必须设置一些截止条件,因为递归有时会卡在某些“坏”区域。
我也看过这篇论文:
www.citeulike.org/user/rchauhan/article/819528
如果您设法以不同的方式解决此问题,我感兴趣。