Public Transportation Routing using Route Graph

Transcription

1 Public Transportation Routing using Route Graph Han-wen Chang Yu-chin Tai Jane Yung-jen Hsu Department of Computer Science and Information Engineering National Taiwan University, Taiwan {b92099, b92018, Abstract Public transportation routing differs from vehicle routing in that automobiles moves freely but service routes are under route constraints. While people travels in the city without their own transportation facilities, they may utilize buses and metros to arrive their destinations. This paper proposed a representation of the map of public transportation system named Route Graph (RGraph) to search for paths between the origin and the destination in a route-to-route manner. In addition, route types and route patterns are encoded and used in search to generate more intuitive solutions. The solutions are evaluated by several attributes and are ranked according to different objectives. By setting preferences among routes, the more suitable solutions may be generated earlier. As a result, the public transportation routing service find the best solutions in real time. Keywords: Route Graph, Route Pattern, Public Transportation Routing 1. Introduction Public transportation routing is different from traditional vehicle routing. Vehicle routing assumes that only one transportation facility is used from the origin to the destination. There is no transfer in vehicle routing. Moreover, it only concerns the physical road constraints such as tunnels and bridges and juristic restrictions such as one-way streets. Standard search algorithms, such as Dijkstra s [2] and the A* algorithms [3, 4], can find the shortest path from the origin toward the destination. In contrast, the route paths of public transportation are constrained that the stops are served by specific routes in a predefined order with a schedule limitation. It is not as free as vehicle routing which people can drive their own automobiles to any location where there is a road. As a result, to travel from one stop to another stop by public transportation often requires more than one service route and some walks. In addition, there are several kinds of facilities in the public transportation system, including buses, metros, trains, etc. These facilities have their pros and cons, and Correspondence author a desired trip may consist of more than one of them. Thus we may have to decide the preference of these facilities when a specific trip may served by different routes. These characteristics of public transportation system makes the problem more challenging than vehicle routing. An intuitive way to encode the transit networks is to transform the physical map into a graph with vertices reperesenting locations and edges representing connections among them. Adjacency matrices are examples for representing graphs with matrices, but they only provides the information about whether people can travel from the origin to the destination by passing numbers of intermediate stops. The fact that connectivity among stops are dependent on the service routes is not shown in the adjacency matrices. However, transfers among routes add costs in most cases, and it requires special care to find the best travel plan. Researchers have noticed that public transportation routing strongly depends on the service routes. Koncz et al. [5] employ Transit Route Connectivity Matrices for representing connectivity among routes. They transform the shortest path problem into the route-toroute fewest transfer problem. They first compare each origin route and destination route to check if there are the same, and then find the possible routes that intersect with each of the origin and destination route combinations, and so on. The search strategy is similar to the combination of iterative-deepening and bidirectional search. Liu et al. discussed hub-based hierarchical planning and matrix-based encoding of route constraints in a series of work [8, 9, 6, 7]. They translated the route-to-route connectivity matrix back to the stop-to-stop transition matrix, and they applied the Q matrix to design heuristic functions for A* algorithms searching on the graph in a location-to-location manner. In this paper we proposed another data structure called Route Graph (RGraph) to represent the relation between service routes. By converting physical city map into RGraph, paths with fewer transfers can be found more easily and quickly, and graph size will be smaller. Because the number of stops in a city is much larger than the number of service routes, the search space of the problem in a route-to-route manner is definitely smaller than in a stop-to-stop manner. In addition, most of the path attributes, such as travel time 1

2 and fare cost, are defined on service routes rather than stops. Choosing the best route to travel is more important than choosing the best stop to get on/off the route. As a result, we believe that finding path in routeto-route manner reduces the space complexity and increases the quality of solutions. Concerning the deployment on mobile devices in the future, storage usage is critical and approaches with fewer requirements on storage are preferred. In our current approach, memory requirement is smaller. If the anytime algorithm [1] can be integrated into the implementation, time requirement can be reduced and it is no more necessary to go through the whole search space and examine all possible solutions. 2. Problem definition and notation Consider travel between two locations by means of public transportation, the problem is to find the most appropriate or preferable itinerary, a sequence of service routes and the corresponding stops for transfer, to archive the trip plan and, sometimes, to meet additional temporal and/or financial requirements. Fig. 1. An example of public transportation system. 2.1 Stops and Service Routes Representation Geographically, stops are linked along the roads and streets, meaning that two stops are accessible to each one by foot. There are also directed service routes passing stops to provide higher mobility. To model the world of public transportation, two fundamental sets are defined. The set S consists of the stops in the area of interest, and unique identification number is assigned to each stop. The set R is composed of the service routes serving this area, and each service route has a unique identification number, too. For grouping the service routes with similar characteristics, a set of route types is denoted by ρ, and a function type: R ρ is defined to group these routes. Each service route r R consists of a sequence of stops s r,1 s r,2 s r,lr, where s r,1, s r,2,..., s r,lr S, and l r means the amount of stops the route r serves. For each pair of service route r and stop s, an ordinal number O r,s is attached to express the service order relationship. If a stop s is the departure terminal of one service route r, O r,s = 1. If a service route r arrives stop s right after leaving from stop t, O r,s = O r,t + 1. If a route r does not serve a stop s, O r,s = 0. { i, if s = sr,i O r,s = 0, otherwise Fig. 1 is an example of public transportation map. There are 18 stops, S = {s 1, s 2,..., s 18 }, and five service routes, R = {r 1, r 2,..., r 5 }. Routes are separated into two types, ρ= {BoldLine, GrayLine}, and type(r 1 ) = type(r 2 ) = BoldLine, type(r 3 ) = type(r 4 ) = type(r 5 ) = GrayLine. Service route r 1 can be represented as a sequence of stops s 17 s 12 s 7 s 6 s 1, and O r1,s 1 = O r1,s Transfers and Path The basic building block of a path is one transit. Without consideration on service time constraint, one valid transit is a 3-tuple (s f, r, s t ) composed of one stop s f to get on the transportation, one service route r, and another stop s t to take off, which satisfies that O r,st > O r,sf > 0. To archive the trip plan, sometimes more than two transits are required. That is, there may be transfers in one path. The boolean function f t (s, t) returns true if the stops s and t are transferable; otherwise, it returns false. A general principal to decide the function value is to count the distance between the two stops, and s S, f t (s, s) = true. Then a valid path p a,b from stop a to stop b is a sequence of transits, (s 1f, r 1, s 1t )...(s mf, r m, s mt ), where i = 1...m 1, f t (s it, s i+1f ) = true and s 1f = a, s mt = b, m is the length of the path. This path means taking route r 1 from stop s 1f to stop s 1t, then transferring from stop s 1t to stop s 2f, then taking route r 2 from stop s 2f to stop s 2t, and so on. Take Fig. 1 for example. Assume we use distance to determine the transferable function f t, then stop s 14 and s 17 are very close to each other, so f t (s 14, s 17 ) = true. However, s 15 and s 6 are far apart, and f t (s 15, s 6 ) = false. Based on the definition, (s 16, r 5, s 14 )(s 17, r 1, s 1 ) is a valid path from s 16 to s 1, while (s 16, r 5, s 15 )(s 6, r 1, s 1 ) is not a valid path from s 16 to s Objectives Possible solutions for one request may be more than one, but according to the objective specified, the preferences to each solution are different. To evaluate the 2

3 quality of one path, several attributes can be calculated, including number of transfer, fare cost, estimated travel distance and time, etc. Common objectives based on these attributes include minimum transfer, minimum fare cost, minimum travel distance, minimum walking distance and minimum travel time. These objectives, in most cases, are not consistent, and sometimes even opposite to each other. The underlying idea to have a mixed combination to evaluate the result is to trade off among these attributes to obtain an acceptable choice. 3. Approach Before the routing process, the transportation information is compiled into a graph called RGraph representing the possible transfers among service routes. Then start point and destination are translated into two sets of service routes which serve the two stops. With the conversion, the problem to find the sequence of stops to travel from start point to destination is transformed to find the service route combinations between two service routes. The generate-and-test approach is applied to find the solutions. Based on the graph and some predefined patterns, DFS-like search algorithm is used to obtain the solutions. After generating all the possible itineraries, another sorting process is applied to ensure the optimality according to the given objective. 3.1 Route Graph Before finding a path from starting point to destination, we build a special directed graph called Route Graph or RGraph. In RGraph, vertices represent service routes R, and edges linking two vertices represent the set of transferring-stop-pairs which enables the passengers to change vehicles between routes. If there is no way to transfer from one service route to another one directly, there is no edge linking the two vertices. G = (R, E) E = {(r 1, r 2 ) e r1,r 2, r i R} e r1,r 2 = {(s 1, s 2 ) f t (s 1, s 2 ) = true and O r1,s 1, O r2,s 2 > 0} There are labels and attributes associated with the vertices, such as the name of the route and the number of vehicles serving the route. On each edge records the transferring-stop-pairs defined by the boolean transferable function f t which is defined before. The transferring-stop-pairs (s f, s t ) means that pedestrians can transfer from one route to another by taking off at one stop s f, walking to another stop s t, and then getting on the other route. Some common methods to define f t includes the distance between two stops and so on. Take Fig. 1 as example to explain the idea behind RGraph. There are five service routes in this example, so there are five vertices in the RGraph. For each pair of routes, transferring-stop-pairs are assigned as described below. R = {r 1, r 2, r 3, r 4, r 5 } E = {(r 1, r 2 ), (r 1, r 3 ), (r 1, r 4 ), (r 1, r 5 ), (r 2, r 1 ), (r 2, r 3 ), (r 2, r 4 ), (r 2, r 5 ), (r 3, r 1 ), (r 3, r 2 ), (r 4, r 1 ), (r 4, r 2 ), (r 5, r 1 ), (r 5, r 2 )} e r1,r 2 = {(s 17, s 18 ), (s 12, s 14 )} e r1,r 3 = {(s 6, s 3 )} e r1,r 4 = {(s 12, s 9 )} e r1,r 5 = {(s 17, s 14 )} e r2,r 3 = {(s 2, s 5 )} e r2,r 4 = {(s 8, s 11 )} e r2,r 5 = {(s 14, s 14 ), (s 15, s 15 ), (s 13, s 16 )} e rb,r a = {(t, s) (s, t) e ra,r b } 3.2 Service Route Patterns In general, when people take public transportation, they tend to fit some regular patterns based on the types of routes. This property comes from different user preferences to each route types and the combination of route types. Consider the real case in Taipei where there is only one metro system. Taking metro lines has several advantages comparing to taking buses. Metros are faster, the service schedule is more regular, and transferring between metro lines is easier. As a result, few people accept the pattern to take metro bus metro because of the convenience of transfer between metro lines. By this property, service route patterns can be utilized as a mean to find reasonable paths and to prune some not-so-good solutions. There are two ways to define these service route patterns. One way is to define by human beings based on common-sense and/or domain knowledge. This is more intuitive and understandable by people. The other way is to be statistically calculated by computer. According to user feedbacks on the recommendation of solutions from the system, the sorting criterion changes dynamically. This is more scientific, but sometimes gives no reasons in semantics. In our implementation, five service route patterns are predefined as described later in experiments. 3.3 Algorithm The routing problem takes two stops as input, one is starting point s f and the other is destination s t, and it returns the recommended paths in a global set variable P. The set R f contains the service routes which pass the stop s f, and the set R t is defined in the similar 3

4 way. The generate-and-test approach is adapted to first search for possible solutions and then to sort the results to meet the objective. The generator searches the RGraph using DFS with heuristics to decide the search order of the successors and with pattern-checking to prune the solutions which we don t like. The tester fills the candidate solutions with more information, calculates the related attributes and sorts the results to have those better solutions with higher level of recommendation. Algorithm 1 Generator(R f, R t, patterns, pastpath) 1: for all r in R f do {ordered by heuristic} 2: if r is not in pastpath then 3: newpath pastpath concatenating r 4: if r R t and newpath satisfies patterns then 5: append newpath to solution P 6: else if newpath can be extended to satisfies patterns then 7: R n neighbors of r 8: Generator( R n, R t, patterns, newpath) 9: end if 10: end if 11: end for First, it sorts possible to-be-expanded service route nodes by some heuristic functions it defines. There are many heuristic functions, such as the service interval of service route, the total number of overlapping service routes and the minimum distance to destination of each service route. Second, it uses predefined route patterns to check each possible path s prefix. Route patterns restrain the depth of path and eliminate the searching time of impossible combination of path. Finally, when it finds a service route in destination set of service route, it saves this combination of path and backtracks to find out other possible solutions. Thus, it figures out many possible combinations of service routes. Then it fills up transferring stops, finds the time and total money cost of each path, and pick up a suitable path for specific user. 3.4 Heuristic Approach When the generator travels the graph, it depends on heuristic function to decide which successor is going to be explored first. The service route with higher heuristic value tends to result in a good solution. Hence, a good heuristic function will help the search process to obtain better route path solutions earlier. Here we propose 3 possible heuristic functions for a service route. A route with more service vehicles is better. If there are more vehicles serving this service route, Fig. 2. Our system. higher chance one can take the route to other places. A route with shorter average interval between two contiguous services is better. The interval is shorter, the waiting time is shorter, and the earlier one can get on the service route. A route which can transfer to more routes is better. The more service routes it can transfer to, the higher chance one can get another route to arrive the destination. Besides these heuristic functions, there are more possible alternations, such as the direction of the service route. But it is hard to calculate this kind of heuristic function because it depends on higher-level information rather than data-level statistics. 4. Experiments The routing agent is implemented (Fig. 2) with the approach described in previous section to find out the possible itineraries. Firstly, after receiving the request and transforming to route-to-route query, it constructs the RGraph according to the public transportation data collected in the database. Secondly, it compiles the service route patterns for further use on limiting the search depth and pruning the not-so-good solutions. Thirdly, it computes the heuristic function for each vertex to help decide the expanding order. Afterward, it searches the RGraph using DFS to generate possible solutions. In our experiment, we use the public transportation system of Taipei as example. The public transportation system of Taipei by the time the research was conducted consists of 395 bus lines with 5718 bus stops and 9 metro lines with 67 stations. Because of the different characteristics between buses and metros, the service routes are separated into these two route types. Some user surveys show that there are 5 service route patterns which people would accept: bus lines only (limited in 2 transfers), metro lines only (limited in 3 transfers), one bus line after metros, metros after one bus line and one bus line metros one bus line. For simplicity in implementation, the transferable function f t returns true if the Manhattan distance is 4

5 less than 250 meters according to longitude and latitude. The heuristic function we adapt when deciding the expanding order depends on the route type and its unique identification. Metros have higher priority to be expanded than buses, and among the routes with same type, the one with smaller identification is expanded earlier. The results are sorted according to the number of transfer, the total stops passing by and the fare cost. The fewer, the better, and the best solution is defined to be the one with fewer transfers. For each query, one starting stop and one destination stop are randomly selected from all bus stops and metro stations. Every 1000 queries is grouped as a trial, and then we use our system to calculate the recommended paths by public transportation only. There are 10 trials in total, so we have queries. The experiement runs on a FreeBSD 6.2-STABLE #3 machine with AMD Athlon(tm) XP and three 256MB RAMs. The average wall time running a trial is seconds, so running one query requires about microseconds. During the generating stage, an extra tag is attached to the solution it found indicating the generating sequence of the results. That is, a solution with smaller sequence number is generated earlier than the one with larger sequence number. By using this tag, we can analyze how fast our implementation can generate an acceptable solution or even the best solution. For each query, the sequence number of the best solution and the smallest sequence number of solutions in the path recommendation are recorded. In Table 1, among the first c solutions generated by generator for each case, the amount of queries which has best solution found is calculated. For example in Trial #01, if only the first ten solutions are considered, that is c = 10, 357 out of 1000 queries have the best solution. Table 2 is similar to Table 1, but it counts whether among the first c solutions generated there are acceptable solutions or not. The result concludes that it is not easy to get the best solution at the very beginning of searching, but the first few solutions may be good-enough for the problem (See Fig. 3, Fig. 4). In Trial #01, 925 queries have solutions. Among them, more than 500 have the best solution generated if only first 50 solutions are given, and more than 700 accept the first 20 solutions generated. In Fig. 5, it shows that the slope of curve becomes small after generating the 50th solution. Although it requires time to search the whole graph in order to get the best solution for all queries, with less time, the system can still generate some good solutions for most queries. Fig. 3. Cases with best solution found in early stage. Fig. 4. Cases with acceptable solutions found in early stage. 5. Conclusion This paper defines the static part of public transportation system, including stops, service routes, trans- Fig. 5. Result after different stage in generator. 5

6 Table 1. The amount of queries which has best path in the first c solutions generated. Trials c #01 #02 #03 #04 #05 #06 #07 #08 #09 # Table 2. The amount of queries which has acceptable path(s) in the first c solutions generated. Trials c #01 #02 #03 #04 #05 #06 #07 #08 #09 # fers and paths. In addition, it adapts the boolean function f t to determine the transferability between two stops. Once the information is ready, the physical map can be transformed into a directed RGraph representing the relations between service routes. In most cases, the amount of service routes is much less than the amount of stops, so this graph conversion can dramatically reduce the space requirement of memory usage. During the search process, the generate-and-test approach is adapted and many methods are used to reduce the search space and to find good solutions as earlier as possible. Heuristic function on each vertex helps decide the search order, and different heuristic function may lead first-generated solutions to meet different objectives. Service route patterns work as dynamic depth limitation for DFS, so the searching process won t dives too deep and return some not-so-good solutions. In addition, the pattern constraints may prune some vertices during search, so only part of the RGraph needs to be loaded into memory. With utilizing all these features, the system can generate good solutions as soon as possible and can use less computing power and memory space than traditional approach. Although there are several vehicle routing applications for automobiles on web and on mobile devices nowadays, only few systems take public transportation into consideration for pedestrians. Google Transit and UrMap are examples which provides routing service of public transportation, but they are on the web and are designed for browsers on desktops and laptops. However, in order to extend the mobility to outdoor users, much efforts should be devoted into system implementation to fit the resource limitation of mobile phones and/or PDAs. Hardware constraints include small memory and storage, short power-supply of batteries, accessibility to computer networks, and limited I/O media. How to utilize the limited I/O media to create an impressive human-computer interaction and to provide good user experiences is an issue, but this paper concerns more about making the routing agent small and fast. By our approach using RGraph and route patterns, experiments show that for most queries solutions can be found in early stage. Future focus will be on designing admissible heuristic function to deliver the best or acceptable solution as soon as possible. Once it becomes true that for most cases, first few solutions generated are good enough, anytime algorithm can be applied to terminate the routing process earlier than finding all possible paths. In that case, routing agents working on mobile devices will no longer be dreams. Acknowledgements 6. Future Work The iwalk public transportation routing system ( introduced in this paper is the final product of senior project conducted by Hanwen Chang, Kuo-hwei Lin, Yu-chin Tai and Ying-sian Wu from Fall 2006 to Spring The supervisor is Professor Jane Yung-jen Hsu. Most of the data are retrieved from the website of Taipei Bus and Transportation Information System and Taipei Rapid Transit Corporation. Thanks to UrMap for supports on the latitude and longitude data of bus stops in Taipei. 6

7 References [1] T. Dean and M. S. Boddy, An analysis of timedependent planning, in AAAI, 1988, pp [2] E. W. Dijkstra, A note on two problems in connexion with graphs, Numerische Mathematik, vol. 1, pp , [3] P. E. Hart, N. J. Nilsson, and B. Raphael, A formal basis for the heuristic determination of minimum cost paths, IEEE Transactions on Systems Science and Cybernetics, vol. SSC-4, no. 2, pp , [4], Correction to a formal basis for the heuristic determination of minimum cost paths, SIGART Bull., no. 37, pp , [5] N. Koncz, J. Greenfeld, and K. Mouskos, A strategy for solving static multiple-optimal-path transit network problems, Journal of Transportation Engineering, vol. 122, no. 3, pp , [6] C.-L. Liu, Best-path planning for public transportation systems, in Proceedings of the Fifth International IEEE Conference on Intelligent Transportation Systems, 2002, pp [7] C.-L. Liu and T.-W. Pai, Methods for path and service planning under route constraints, in International Journal of Computer Applications in Technology, vol. 25, no. 1, 2006, pp [8] C.-L. Liu, T.-W. Pai, C.-T. Chang, and C.-M. Hsieh, Path-planning algorithms for public transportation systems, in Proceedings of the Fourth International IEEE Conference on Intelligent Transportation Systems, 2001, pp [9] C.-L. Liu, T.-W. Pai, S.-M. Huang, and C.-T. Chang, Route-information management and provision for public transportation systems, in Proceedings of the Eighth World Congress on Intelligent Transport Systems,