简体   繁体   English

公交车公共交通算法

[英]Bus public transport algorithm

I am working on an offline C# application that can find bus routes. 我正在开发一个可以找到公交路线的离线C#应用程序。 I can extract the timetable/bus/route data. 我可以提取时间表/公交车/路线数据。 I am searching for the most simple solution that will work with basic data. 我正在寻找可以使用基本数据的最简单的解决方案。

What algorithm can be used to find a route from bus stop "A" to bus stop "B"? 什么算法可用于查找从公交车站“A”到公交车站“B”的路线? Is there a open-source solution ready for C#/Java? 是否有针对C#/ Java的开源解决方案? Is the google GTFS format for database good for a simple solution? 数据库的谷歌GTFS格式是否适用于简单的解决方案? http://code.google.com/transit/spec/transit_feed_specification.html http://code.google.com/transit/spec/transit_feed_specification.html

Thanks for any help. 谢谢你的帮助。 I am stuck with this. 我坚持这个。 I don't know where to start - how to store the data and how to find routes. 我不知道从哪里开始 - 如何存储数据以及如何查找路径。 I know about Dijkstra/A* but I have used them only on graphs that were not time dependent... 我知道Dijkstra / A *但我只在不依赖于时间的图表上使用它们...

The problem you are working on is not a trivial task. 您正在处理的问题不是一项微不足道的任务。 So much so, that is has a name: the mixed integer nonlinear programming problem (MINLP). 这么多,有一个名称:混合整数非线性规划问题(MINLP)。 In the words of one author (Deb 1998): 用一位作者的话来说(Deb 1998):

"When formulated mathematically, the time scheduling problem becomes a mixed integer nonlinear programming problem (MINLP) having a large number of resource- and service-related constraints. Although attempts have been made in the past to find an optimal schedule of a simplified model using classical optimization techniques (Bookbinder & DCsilets, 1992; Kikuchi & Parameswaran, 1993), it is observed that this is an extremely difficult task even for a small transit network. The difficulty arises mainly because of the large number of variables and constraints, discrete nature of variables, and nonlinearities involved in the objective function and the constraints." “当数学公式化时,时间调度问题变成具有大量资源和服务相关约束的混合整数非线性规划问题(MINLP)。尽管过去曾尝试使用简化模型找到最佳时间表经典优化技术(Bookbinder&DCsilets,1992; Kikuchi&Parameswaran,1993),观察到即使对于小型公交网络来说这也是一项极其困难的任务。困难主要是由于大量的变量和约束,离散性质变量,以及目标函数和约束中涉及的非线性。“

In Deb's paper he proposes a genetic algorithm. 在Deb的论文中,他提出了一种遗传算法。

Your other option would be to use simulation. 您的另一个选择是使用模拟。 Just to throw something out there you can try right away-- choose thousands of random routes that start at your origin, and fish out the ones that work reasonably well at getting to the destination. 只是为了扔东西你可以立即尝试 - 从你的起源选择成千上万的随机路线,并剔除那些在到达目的地时工作得相当好的路线。

Picture the algorithm like this: You are trying to find the quickest route from stop A to stop B, starting at a certain time. 想象这样的算法:你试图找到从A站到B站的最快路线,从某个时间开始。 You hire 1,000 people and arm them with a quarter to flip. 你雇佣了1000个人并用四分之一的武器来翻转。 You tell them to flip the coin every time they have a chance to get on or off a bus. 你告诉他们每次有机会上下车时都要翻硬币。 Heads, get off (or get on, if already off). 下车,下车(或上车,如果已经下车)。 Tails, stay on (or keep waiting, if off). 尾巴,保持(或等待,如果关闭)。 They each have an index card to write down the choices they make as they go. 他们每个人都有一张索引卡,可以记下他们所做的选择。 You go to point B and wait for the first guy to show up and take his card. 你去B点等待第一个人出现并拿走他的卡。

read this: 读这个:

Multi-Modal Route Planning. 多模态路线规划。 Master's thesis, Universität Karlsruhe (TH), Fakultät für Informatik, 2009. online available at http://i11www.ira.uka.de/extra/publications/p-mmrp-09.pdf 硕士论文,UniversitätKarlsruhe(TH),FakultätfürInformatik,2009。可在线获取: http://i11www.ira.uka.de/extra/publications/p-mmrp-09.pdf

the section on railway routing also applies for bus routing. 铁路路线部分也适用于公交路线。

The gist of it: the naive approach of expanding space and time into a single graph does not work for large networks. 它的要点:将空间和时间扩展到单个图形的天真方法对大型网络不起作用。 There are smarter solutions. 有更智能的解决方案。

There is an extensive list of publications (30+) on public transport routing algorithms that has been compiled over time by contributors to the open-source (Java) OpenTripPlanner project here: 有一个关于公共传输路由算法的出版物(30+)的广泛列表,这些算法已经由开源(Java) OpenTripPlanner项目的贡献者随时编译:

https://github.com/opentripplanner/OpenTripPlanner/wiki/RoutingBibliography https://github.com/opentripplanner/OpenTripPlanner/wiki/RoutingBibliography

OpenTripPlanner is multi-modal routing engine that also includes bike and walk - from the above link: OpenTripPlanner是多模式路由引擎,还包括自行车和步行 - 从上面的链接:

This is a list of articles, dissertations, and books that have inspired and informed both the existing OTP routing engine and some ongoing experiments. 这是一篇文章,论文和书籍的列表,它们启发并通知了现有的OTP路由引擎和一些正在进行的实验。 Currently, OpenTripPlanner uses a single time-dependent (as opposed to time-expanded) graph that contains both street and transit networks. 目前,OpenTripPlanner使用单个时间相关(而不是时间扩展)图,其中包含街道和传输网络。 Walk-only and bicycle-only trips are generally planned using the A* algorithm with a Euclidean heuristic or contraction hierarchies. 通常使用具有欧几里德启发式或收缩层级的A *算法来计划仅行走和仅自行车行程。 Walk+Transit or Bike+Transit trips are planned using a variant of the MOA* algorithm with epsilon-dominance for path pruning and the Tung-Chew heuristic (a graph providing a lower bound on aggregate weight) for queue ordering. Walk + Transit或Bike + Transit旅行计划使用MOA *算法的变体,其中epsilon-dominance用于路径修剪,而Tung-Chew启发式(提供聚合权重下限的图表)用于队列排序。

The routing bibliography above includes references for the following categories of algorithms and related work: 上面的路由参考书目包括以下类别的算法和相关工作的参考:

  • Path Search Speedup Techniques 路径搜索加速技术
  • Multi-objective Pareto Shortest Paths 多目标帕累托最短路径
  • Resource-constrained Routing 资源受限的路由
  • Contraction and Transfer Patterns 收缩和转移模式
  • Timetable-based routing 基于时间表的路由
  • ALT and Metric Embeddings ALT和度量嵌入
  • Calibration and Implementation Details 校准和实施细节
  • Post-Dijkstra Public Transit Routing 后Dijkstra公共交通路线

If you find something new that's not on the list, please feel free to add it to the wiki! 如果您发现列表中没有的新内容,请随时将其添加到维基!

As far as other open-source public transport routing libraries - there is also the RRRR project by Bliksem Labs: 至于其他开源公共交通路线图书馆 - Bliksem Labs还有RRRR项目:

https://github.com/bliksemlabs/rrrr https://github.com/bliksemlabs/rrrr

From the above link: 从以上链接:

RRRR (usually pronounced R4) is a C-language implementation of the RAPTOR public transit routing algorithm. RRRR(通常发音为R4)是RAPTOR公共交通路由算法的C语言实现。 It is the core routing component of the Bliksem journey planner and passenger information system. 它是Bliksem旅程规划和乘客信息系统的核心路由组件。 The goal of this project is to generate sets of Pareto-optimal itineraries over large geographic areas (eg BeNeLux or all of Europe), improving on the resource consumption and complexity of existing more flexible alternatives. 该项目的目标是在大的地理区域(例如BeNeLux或整个欧洲)生成一组帕累托最优路线,从而改善现有更灵活的替代方案的资源消耗和复杂性。 The system should eventually support real-time vehicle/trip updates reflected in trip plans and be capable of running directly on a mobile device with no Internet connection. 该系统最终应支持旅行计划中反映的实时车辆/旅行更新,并且能够直接在没有互联网连接的移动设备上运行。

Both OpenTripPlanner and RRRR use GTFS data. OpenTripPlanner和RRRR都使用GTFS数据。

Just wanted to share my final approach on this problem. 只是想分享我对这个问题的最终方法。 This was part of a university project, so it might not be fully suitable for real world use. 这是大学项目的一部分,因此它可能不完全适合现实世界的使用。 It had to be reasonably fast to run on a Windows Mobile device. 在Windows Mobile设备上运行它必须相当快。

I ended up using 4 tables (SQLite). 我最终使用了4个表(SQLite)。 One table keeps the list of buses, the second one keeps a list of stations. 一个表保留总线列表,第二个表保留一个站列表。 Another table keeps the combinations - what bus does stop at a specific station and where does it go from this station and how long (minutes) does it take. 另一张表保留了这些组合 - 公交车在特定车站停靠的位置以及从该车站到达的位置以及需要多长时间(分钟)。 All combinations have to be stored. 必须存储所有组合。 And the last table is a simple time-table. 最后一张表是一个简单的时间表。 For every station it lists every bus that stops there and the time (I stored the time as integer value - 14:34 is 1434, to make it faster for comparing). 对于每个站点,它列出了停在那里的每个总线和时间(我将时间存储为整数值 - 14:34是1434,以便更快地进行比较)。

I used a bi-directional breadth first search algorithm. 我使用了双向广度优先搜索算法。 The neighbor stations (directly accessible) are retrieved for the start station and destination station. 为起始站和目的站检索相邻站(可直接访问)。 There is a path from station A to station X if these two "graphs" overlap on a station. 如果这两个“图形”在一个站点上重叠,则存在从站A到站X的路径。 For example, from station A you can get to stations B,C,D,E (by using specific buses). 例如,从A站可以到达站B,C,D,E(通过使用特定的总线)。 And from the destination station X you can get directly to N,C,Z. 从目的地站X,您可以直接到达N,C,Z。 These two graphs overlap on station C. So a path A -> C -> X exists. 这两个图在站C上重叠。因此存在路径A - > C - > X. If no paths are found in this first iteration, then the algorithm continues and spreads out the graphs (BFS) again. 如果在第一次迭代中没有找到路径,则算法继续并再次展开图形(BFS)。

Time is not taken into account in the first step - this makes it fast enough. 第一步没有考虑时间 - 这足以让它足够快。 You only get a list of possible paths with a list of buses that you have to use to take these paths. 您只能获得一个可能的路径列表,其中包含您必须用来获取这些路径的总线列表。 The times are evaluated in the last step, you go through the list of possible paths and check if the bus travels within the specific time (increasing the time every stop). 在最后一步中评估时间,您浏览可能路径列表并检查公交车是否在特定时间内行驶(增加每次停车的时间)。

On a small city, with 250 stations and 100+ buses/railways, these approach works up to 3 changes (where you have to change the buses on the journey). 在一个拥有250个车站和100多辆公共汽车/铁路的小城市,这些方法最多可以进行3次更改(您必须在旅程中更换公交车)。 It takes only seconds to calculate. 计算只需几秒钟。 But I had to load the whole database into memory (Dictionary) to speed up the queries, which were taking too long. 但是我不得不将整个数据库加载到内存(Dictionary)中以加快查询速度,这些查询耗时太长。

I don't think this would work for a large network though. 我认为这不适用于大型网络。 But it works for a public transport of a single small-medium size city. 但它适用于单个中小城市的公共交通工具。

Conceptually, you take the same basic algorithm for evaluating distance between A and B, but instead of distance, you should be evaluating time. 从概念上讲,您使用相同的基本算法来评估A和B之间的距离,但您应该评估时间而不是距离。 Dijkstra can do both, if you give it the proper inputs. 如果你给它适当的输入,Dijkstra可以做到这两点。

You're used to seeing a map as a measure of distance. 您习惯将地图视为距离的衡量标准。 However, the same map can be a measure of time as well; 但是,同一张地图也可以作为时间的衡量标准; all you need is to add data about average speed, and the time it takes to cover a particular distance of a particular road will shake itself out. 您只需要添加有关平均速度的数据,覆盖特定道路特定距离所需的时间就会自动消失。 You can even visualize the map in terms of time; 您甚至可以根据时间可视化地图; routes that take longer will be longer. 需要更长时间的路线会更长。 Dijkstra doesn't care which it's evaluating, really; Dijkstra并不关心它正在评估哪个,真的; it just cares about finding the continuous route with the lowest number, and whether that number represents length or time is immaterial. 它只关心找到数量最少的连续路线,这个数字代表长度或时间是无关紧要的。

To incorporate speed, naive algorithms simply use the daytime speed limit and assume you never have to stop while going from A to B; 为了结合速度,天真的算法只需使用白天的速度限制,并假设您从A到B时不必停下来; more advanced algorithms can incorporate information about time of day and traffic patterns (which will impact the average speed you travel on that road at that time), and whether a road is a freeway or surface street (and thus make educated guesses about time spent stopped at an intersection). 更高级的算法可以包含有关一天中的时间和交通模式的信息(这将影响您当时在该道路上行驶的平均速度),以及道路是高速公路还是水面街道(从而对停止的时间做出有根据的猜测在十字路口)。 What you use depends on what you have available, but a basic 4- or 5-layer time of day dimension should be adequate for all but the absolute most time-critical applications. 您使用的内容取决于您可以使用的内容,但基本的4或5层时间维度应该足以满足除绝对时间最关键的应用程序之外的所有应用程序。 For each direction of each road in your map, you need the average speed during morning rush, daytime, evening rush and night, possibly with lunchtime numbers as well. 对于地图中每条道路的每个方向,您需要在早上高峰,白天,晚上高峰和晚上的平均速度,也可能是午餐时间的数字。 Once you have that, it's a relatively basic change to a Dijkstra algorithm to pass in a time of day and have it evaluate routes based on time. 一旦你拥有了它,这是Dijkstra算法在一天中的时间内传递并且根据时间评估路线的相对基本的变化。

If you are interested in time information, then why not label the distance values on the graph edges using the time information instead of their physical distance from each other. 如果您对时间信息感兴趣,那么为什么不使用时间信息而不是它们彼此的物理距离来标记图形边缘上的距离值。 That way you will search for the quickest route, instead of the shortest route. 这样您将搜索最快的路线,而不是最短的路线。 You can then use Dijkstra/A* in order to compute the your result. 然后,您可以使用Dijkstra / A *来计算结果。

I'm a little unclear on what you mean by time dependent. 我对你依赖时间的意思有点不清楚。 If you mean that that you need to answer queries of the form 'goes from x to y before 10am' then you can calculate what bus routes arrive before 10am, seems like a simple filter on the data. 如果你的意思是你需要回答“早上10点之前从x到y”的形式的查询,那么你可以计算在上午10点之前到达的公共汽车路线,看起来像是对数据的简单过滤。 Then apply Dijkstra/A* to the data. 然后将Dijkstra / A *应用于数据。

Try this as your data model. 试试这个作为您的数据模型。

Bus 1 goes to stops A, B and C. Bus 2 goes to stops B, D and E. 总线1到达A,B和C站。总线2到达B,D和E站。

I would store a unique node based on both bus and stop, with distances to nodes being based on time. 我会基于总线和停止存储一个唯一的节点,节点的距离基于时间。 We would have node A1, B1, C1, B2, D2 and E2. 我们将有节点A1,B1,C1,B2,D2和E2。 In the special case of transfers apply the wait for the next bus as the distance between nodes. 在传输的特殊情况下,应用等待下一个总线作为节点之间的距离。 For example, if Bus 1 arrives at stop B 30 minutes before Bus 2, travel time from B1 to B2 is 30 minutes. 例如,如果公共汽车1在公共汽车2前30分钟到达B站,则从B1到B2的行程时间为30分钟。

You should than be able to apply Dijkstra's Algorithm. 你应该能够应用Dijkstra的算法。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM