Genetic Algorithm Based Dynamic Route Planner for Public 1

Transport 2 3 Abhishek Basu 4 Former undergraduate student, 5 Department of Civil Engineering 6 Indian Institute of Technology Madras, 7 Chennai, Tamil Nadu 600036 8 Tel:+91 - 9600153209 9 Email: abhishek.sfy@gmail.com 10 11 and 12 13 Lelitha Vanajakshi1 14 Associate professor, 15 Department of Civil Engineering 16 Indian Institute of Technology Madras, 17 Chennai, Tamil Nadu 600036 18 Tel: +91 - 44 - 2257 4291 19 Email: lelitha@iitm.ac.in 20 21 Paper revised and submitted for presentation and publication in 22 Transportation Research Record, Transportation Research Board, 23 National Research Council, Washington, D. C. 24 Word Count: Body text (5728) + Figures (1000) + Tables (750)= 7478. 25 Submitted on: November 15, 2015 26

1 Corresponding Author

Basu and Vanajakshi 2

Genetic Algorithm Based Dynamic Route Planner for Public 1

Transport 2 3 ABSTRACT 4 This paper aims to address the issue of unreliability associated with the public transportation 5 system and hence looks at developing a robust and accurate route planner using Global 6 Positioning System (GPS) data recorded from individual buses. Real-time data from the buses of 7 Metropolitan Transport Corporation (MTC) Chennai, were used for demonstrating the results. 8 With the help of such a route planner, users can make informed decisions and they can optimise 9 their schedule in the desired way. Genetic Algorithm (GA) is a robust algorithm, which provides 10 good solutions within computational time constraints for the chosen problem, and hence has been 11 used in this study. The developed route planner was initially tested for static networks, and then 12 extended to real-time data. In order to speed up the GA based framework, the algorithm was 13 segmented and a temporal cache was introduced. The performance of the developed framework 14 was found to be satisfactory showing a great scope for scalability and citywide implementation 15 of the solution for real-time route planning. 16

Basu and Vanajakshi 3

Genetic Algorithm Based Dynamic Route Planner for Public 1

Transport 2 3 INTRODUCTION AND BACKGROUND 4 Traffic congestion is a serious problem faced by many urban areas in India. A solution is to 5 attract more travellers to public transport services. However, public transportation in India is 6 unreliable as buses often do not adhere to the schedule due to delays caused by congestion. A 7 route planner for bus transportation system would try to solve this reliability issue to a certain 8 extent. A bus-based trip-planner would help passengers identify the correct routes to be taken 9 with minimum stopovers or waiting or walking times and thus would lead to increased usage of 10 public transportation system. The parameters to be minimised may vary according to personal 11 preferences. 12

Depending on the data used, a route planner can be static or real-time. A static route 13 planner can help a user plan the trip beforehand, whereas a real-time route planner can be used 14 for updates during the trip and this would take into account the variation in bus schedules. Hence, 15 an ideal route planner should operate at both static and real-time levels to be effective as a 16 solution. The present study aims to develop a trip-planner taking Chennai Metropolitan 17 Transport Corporation (MTC) as the case study. Real-time tracking data collected using onboard 18 GPS units were used. An existing travel time prediction algorithm (1) was used in addition to 19 GPS data, for the real-time trip-planner. 20

Various approaches have been reported for route optimization of multi-modal travel 21 problem Genetic Algorithm (GA) is one of them. Genetic Algorithms are adaptive heuristic 22 search algorithms based on the evolutionary ideas of natural selection and genetics. As such they 23 represent an intelligent exploitation of a random search used to solve optimization problems (2). 24 GA has been used in a host of optimization and search problems. Some of the basic terms 25 associated with GA are explained as follows. The space of all feasible solutions to the problem 26 represents the search space. Each point in the search space represents a unique solution that 27 could be marked by its fitness for the problem. Fitness is an attribute defined as per the 28 problem’s objectives, which distinguishes one solution from the other in terms of its ideal nature. 29 Each solution obtained from GA is represented as a string of elements (values) in a particular 30 order, and is called a chromosome (3). Each element that constitutes the chromosome is called a 31 gene. The specific representation of a chromosome is termed as encoding. Genetic operators are 32 applied on successive generations of population, which is the set of chromosomes generated at a 33 particular iteration, in an attempt to increase the fitness of individual solutions. Selection, 34 crossover and mutation are three commonly used genetic operators. Genetic algorithms have 35 been often used in bus network optimization problems and in shortest path applications. 36

Some of the relevant literature in this area are discussed here. Nanayakkara et al. (4) 37 implemented a genetic algorithm based route planner for large urban street networks. Each 38 chromosome consisted of a sequence of positive integers that represented the IDs of nodes, 39 which constituted the path. The initialisation step proposed in the paper was to simultaneously 40 search for paths from both origin and destination. It was observed that the population size has a 41 huge impact on the execution time. It was also observed that the population size depended upon 42 the complexity of the route. Greater the complexity, higher is the required population size. It was 43 tested on a Singapore based network (10,000 nodes) and was shown to outperform the ant-based 44 algorithm, which they tried out as an alternate algorithm. 45

Nilesh et al. (5) developed a real-time trip-planner that used GPS data from buses and 46 found out multi-criterion optimal paths using K-shortest path algorithm. Breadth First Search 47

Basu and Vanajakshi 4 (BFS) algorithm was used to search the travel plans. GPS data from only two routes were 1 utilized in presenting the results. Rahim et al. (6) used GA for time-dependent personal tour 2 planning and scheduling. This was solved using GA to search the solution of the shortest 3 multi-modal path problem. They encoded the chromosome in a non-binary fashion, with 4 alternate genes representing node and mode. During initialisation, randomly generated genes 5 were appended sequentially until the destination node was reached, to construct a chromosome 6 (path). The algorithm was terminated, if the temporal differences between fifteen paths with best 7 costs in the successive iterations reached a certain level (chosen as zero). The algorithm was 8 successfully implemented for the city of Tehran, and about 400 test cases were evaluated. Chen 9 et al. (7) explored the idea of a multi-modal trip-planner, however it did not consider real-time 10 scenario. Jariyasunant et al. (8) developed an algorithm to calculate the travel times of K-shortest 11 paths in a public transportation network, and all wait and travel times were known at real-time. 12 The precomputation of paths was shown to speed up the solution generation. Kumar et al. (9) 13 showed that the solution obtained should satisfy the minimum criteria of reaching a fixed number 14 of generations and optimal budget allocation (time and money) and that no successive iterations 15 should produce better results. 16

Route optimization of multi-modal travel being a NP-hard problem and it is difficult to 17 get global optimal solution by exact algorithms in an acceptable amount of time (10). Genetic 18 algorithm was adopted in this paper for this purpose, since they were reported to have worked 19 well for time-constraint shortest path problems in earlier studies. 20 21 METHODOLOGY 22 Due to the advantages offered by GA, it was adopted to develop the framework for the route 23 planner presented in this paper. The encoding scheme used is as follows: each odd gene 24 represents bus stop (or any other boarding location) and the even genes represent the route IDs of 25 the vehicles that are used to traverse from one bus stop to the other. Each step of the genetic 26 algorithm was modified to suit the computational needs of the problem in hand. The basic 27 structure of the algorithm is as follows: the first step involves initialisation of the population, 28 followed by evaluation of their fitness value and ranking them. The second step involves 29 application of genetic operators. The invalid chromosomes are repaired to make them feasible, 30 followed by evaluation and ranking. The second step is repeated until the termination criteria is 31 satisfied. 32

Broadly, the GA could be divided into two steps, the initialisation step and the mating 33 step. In the initialisation step, the chromosome is constructed starting from the source, after 34 which a random node adjacent to the source and a corresponding mode of travel are chosen. This 35 process is continued further with the newly reached node and so on, until the destination is 36 reached. The length of a chromosome depends on the number of intermediate nodes in each path. 37 Thus, its limit is fixed at the beginning based on the maximum number of transfers that the user 38 is willing to take. As a particular node is reached, it is added to the scan list to keep track of all 39 the nodes that have been visited, thereby avoiding loops. The initialisation step may sometimes 40 never reach the destination. For example, during the initialisation process if a node from which 41 no arcs exist was reached, or if all nodes adjacent to this particular node were already present in 42 the scan list, the algorithm would get stuck in a loop and the solution gets trapped at that 43 particular node. To avoid this, a counter is maintained, which counts the number of random 44 attempts to select an adjacent node, and the partial solution is discarded upon exceeding the limit. 45 Since GA is probabilistic, it is imperative to use a pre-defined limit, which is independent of the 46 node chosen. To generate the initial population of chromosomes, this process was repeated until 47 the predefined population size was achieved. If the population size is too low, the computation 48

Basu and Vanajakshi 5 time would be less. However the diversity in the solution set would be low, which might lead to 1 convergence to a local minima. On the other hand, if the population size is too high, the 2 computation time would be high, but the diversity in the solution would be greater and there 3 would be a greater probability of convergence to a global minimum. 4

Cost associated with each chromosome is computed and validity is examined as per the 5 schedule. This is a cost minimisation problem; hence the fitness function is inversely related to 6 cost function (11). If a solution is invalid, a high penalty is imposed, which makes the cost very 7 high, thereby rendering the solution infeasible. The cost function considered here is the sum of 8 travel time and the waiting time, or in other words, the total duration of the trip. 9

After initialisation, the next step is the Mating step. In this step, genetic operators such as 10 crossover, selection and mutation are applied on the successive generations of the population, till 11 the termination criterion is satisfied. The genetic operators - Selection, Crossover and Mutation, 12 have been used in the study. A selection mechanism in GAs is simply a process that favors the 13 selection of better individuals in the population for the mating pool. The present study uses 14 elitism, which ensures that better solutions have greater chance of selection as compared to 15 poorer solutions. The crossover operator looks for common genes in two parent chromosomes 16 and then swaps parts of these to produce two new offspring chromosomes. A crossover 17 probability (Pc) decides whether crossover takes place in a particular iteration. The first step 18 during the implementation of the crossover mechanism is to choose two chromosomes. During 19 crossover mechanism, two parent chromosomes are chosen randomly. Potential sites (nodes) for 20 crossover are identified in the parent chromosome. If multiple such sites are identified, one of 21 them is chosen randomly. Following this, crossover takes place, and two new offspring 22 chromosomes are generated. A post-processing procedure is employed after this, which removes 23 loops and repetitions. The cost associated with each solution obtained in the crossover step is 24 computed and infeasible solutions are rejected. Mutation represents a random order change that 25 ensures that the solution does not converge to a local minima. In the present study, order change 26 was carried out for odd genes (representing bus stops, except for the first and last gene). The 27 probability, Pm was used to denote the probability of mutation. A repair function was used in 28 case the resulting chromosome was infeasible. 29

30 IMPLEMENTATION ON A STATIC NETWORK 31 The GA based framework was implemented using Python language. Parameters for the planner 32 were based on user preferences obtained through survey conducted in Chennai city. Static 33 networks contain pre-determined and invariant temporal information at the time of computation 34 of solution. For the purpose of implementation, GPS data were obtained from buses operated by 35 the Metropolitan Transport Corporation (MTC), Chennai. Each record (or log) containing the 36 data included a timestamp and the corresponding longitude and latitude of the location of the 37 bus. 38

The constraints of the problem were broadly divided into two categories: hard constraints 39 and soft constraints. Hard constraints were used during computation of results and the soft 40 constraints were used after the computation of results to filter the solution set obtained, in order 41 to present user-relevant solutions. The hard constraints were of two types. The first type was the 42 network constraint such as buses that travelled on certain fixed routes, and that could not travel 43 on any physical link (road) at free will. The buses were also constrained by the schedule and trip 44 route. To make it computationally easy to incorporate this condition, the bus network was 45 represented in the form of a directed graph, with links corresponding to a particular route ID, and 46 the to and fro directions within the same route were assigned different route IDs. The second 47

Basu and Vanajakshi 6 type of hard constraint was the maximum number of transfers in a particular solution. This limit 1 not only helped in eliminating a large number of solutions but also, reduced the computation 2 time of the algorithm. The soft constraints included the limit on transfers, maximum walking 3 distance and the maximum travel time, as per the user’s preferences. These limits helped in 4 presenting user-specific solutions. 5 The selection of GA parameters, as discussed in the earlier section, is usually decided 6 considering the tradeoff between accuracy and computational efficiency. In GA domain, these 7 parameters are heuristically decided for the specific problem under consideration and the same 8 was done in this study. A low probability value of mutation was considered since mutation 9 results in breaking up of already fit solutions to generate new solutions (Pm value of 0.1). Since 10 the new solutions generated need to undergo additive repair and the network chosen in the study 11 was “sparse”, this often led to increased length, implying that solutions with multiple transfers, 12 often exceeding the global limit, were generated. Hence, the crossover operator was given 13 preference and a comparatively higher probability value was chosen in the study (Pc = 0.8). 14 After the operator probabilities were decided, the remaining parameter was the population size. 15 To find the optimal value for this, the computational time and percentage of iterations producing 16 optimal solution were taken as the main criteria and a trial and error procedure was followed. 17 Thus, the final GA parameters chosen were as follows: for the initialisation step, a chromosome 18 length limit of 7 and a predefined population limit of 10 were chosen. For the mating step, a 19 chromosome length limit of 7, Probability of crossover (Pc) value of 0.8, Probability of mutation 20 (Pm) value of 0.1 and Total number of generations value of 21 were chosen. 21

All the network and schedule data that was used for the algorithm were stored in a 22 temporal-geospatial database called the Service and Time Table (STT) database. This had two 23 sub-components. First was the network structure data, which was stored in the form of an 24 adjacency matrix and it contained the information of all nodes that were adjacent to a given node, 25 with corresponding arcs representing various bus routes. Second component of STT was the 26 temporal data for the routes. The GPS data obtained from the buses and the corresponding 27 predictions constituted the temporal data. Using this data, the departure times from each bus stop 28 were found out and this was stored in the STT as independent trip files for each route. 29 30 Evaluation 31 Five routes were chosen with route IDs - 5A, 5B, 5E, 21D, 21L, 23C and 154. The algorithm was 32 tested for different origin-destination combinations and the performance was checked. Solution 33 for a sample query for origin as “Broadway”, destination as “ESI Hospital” and time of travel as 34 10:30 am is shown in Figure 1. 35 36

Basu and Vanajakshi 7

1 FIGURE 1 Program output for sample query – static case. 2

Basu and Vanajakshi 8 Computation Time Measurement 1 To measure the computing time required to produce solutions for a general query, an origin node 2 was chosen at random, and then solutions were computed for all destination nodes. Time taken 3 for each such iteration was noted. It was observed that iterations that failed to yield a solution 4 within a time limit of 0.6 second were those that had no feasible solution (for the given 5 origin-destination pair). Hence, for the network chosen, 0.6 seconds was taken as the cutoff time 6 limit. Sample result for a randomly selected origin node (Broadway) and time (10:30 am) was 7 calculated. 8

A total of 168 valid iterations were produced, which implies that a total of 168 9 destination nodes could be reached from the selected origin node, that is “Broadway”. The 10 average time taken to compute each solution was found to be 0.27 seconds. The standard 11 deviation was calculated and was found to be 0.08 seconds. Since the network chosen was sparse, 12 the number of iterations were fixed, and this served as the termination criterion. 13 14 REAL-TIME INTEGRATION 15 Traffic networks are dynamic in nature and hence the trip-planner needs to work with real-time 16 data or predicted data. In order to achieve this, the algorithm has to be integrated functionally 17 with real-time data input (predictions). Real-time data were available for a subset of buses in 18 sixteen routes namely - 19B, 154, 21L, 221H, 23C, 47A, G18, M119A, M14, 5A, 5B, 5E, 7B, 19 M7A, M7 and M70. A prediction algorithm was used, which received raw data from buses and 20 generated the Estimated Time of Arrivals (ETAs) at various bus stops that were part of its route. 21 The prediction algorithm generated a separate file referred to as the ETA file, for each bus on a 22 particular route and for a specific bus stop. These predictions were made at small time intervals 23 until the specific bus stop was reached, at which point the prediction process stopped. Although 24 the prime focus of this study was to create a trip-planner for bus routes, walking and a portion of 25 Chennai Mass Rapid Transit System (MRTS) was also included in the geospatial database to 26 extend the trip-planner’s capabilities. The MRTS section between “Velachery” and “Chennai 27 Beach” (to and fro) was included as a separate mode. For walk mode, a simple distance 28 calculation based on GPS coordinates was proposed. A connector was defined as a link between 29 a bus stop and the nearest MRTS station which would be traversed by walk. A fixed time was 30 also added towards "ticket purchase" at the MRTS station. 31 32 Evaluation 33 A sample query is discussed here. A hypothetical user made a query at 11:48 am for a trip 34 required at 12:15 pm. The origin was Karapakkam (bus stop) and the destination was Chennai 35 Beach Station (MRTS station). The route suggested to the user is shown in Figure 2. 36

Basu and Vanajakshi 9

1 FIGURE 2 Program output for sample query – real-time case. 2

3 Let us assume, the user chose this solution and made multiple queries at different times before 4 and during the journey, each representing a scenario, as follows. 5

Ø Scenario 1: Before starting the trip, roughly 30 minutes before journey. 6 Ø Scenario 2: Before reaching the origin bus stop “Karapakkam”, ten minutes before 7

journey start time (as estimated in Scenario 1). 8 Ø Scenario 3: During journey between origin and terminal bus stop. 9 Ø Scenario 4: Ten minutes before estimated time of reaching the terminal bus stop. In this 10

case, “Madhya Kailash” bus stop. 11 Ø The actual time of arrival is represented as scenario 5. This information is the real trip 12

information available only after the entire trip is completed. 13

Let the cost function chosen in the study was total travel time, and a high variation in the value 14 of this function can happen enroute due to a missed transfer. Or a better alternate solution could 15 come up after the journey had begun. This would mean that the solution could change 16 mid-journey. This may be unfavourable for a class of users who would want a “conservative” 17 solution that would not drastically change during mid trip, a situation that could lead to 18 unforeseen transfers and lack of an accurate estimate of the total journey time. These fluctuations 19 are especially serious for Scenario 3 and 4, since these queries are made after the journey has 20 begun. For example, Table 1 lists the ETAs at different times of the sample query and the 21 corresponding cost function values. Figure 3 shows the corresponding scenario plot with cost 22 function value, where the start of the journey is represented by a vertical line at Scenario 3. It 23 could be observed that there is significant variation in the cost function value beyond Scenario 3, 24 which implies that the user would get fluctuating values for the estimated travel time. 25 26

Basu and Vanajakshi 10

TABLE 1 ETAs at different times of query and corresponding cost 1

Scenario Time of query

Bus stops Walk & ticket time

Boarding: MRTS

Cost Karapakkam

Madhya Kailash

Kasturbai Nagar

Chennai Beach Station

1 11:48 12:17 12:39 12:48 12:51 13:20 3747 2 12:09 12:19 12:46 12:53 13:11 13:40 4860 3 12:30 N/A 12:42 12:51 13:11 13:40 4843 4 12:32 N/A 12:40 12:49 12:51 13:20 3643 5 Actual data 12:19 12:43 12:52 13:11 13:40 4843

2 FIGURE 3 Cost Function value against scenario. 3

4 Since, this fluctuation in cost function value may cause discomfort to certain commuters, 5

they may prefer a conservative solution. These fluctuations happen mainly due to uncertainty in 6 predicted values (ETAs), and they should be captured within the trip-planner to provide buffers 7 around the predicted time and ensure that the solution does not change drastically, if the user 8 wanted “conservative” solutions. However, there may be users who would like to know the 9 updates and make changes accordingly. The present solution tries to address the requirements of 10 both these group of users: those who wants to stick to a conservative solution and those who 11 want live updates, as follows. 12 13 Addressing the errors 14

When a user queries, the algorithm uses predicted data, which is available at that instant. 15 This predicted data may contain prediction error, and this needs to be accounted for within the 16 trip-planner to generate “conservative” solutions. Broadly speaking, these errors are dependent 17 on the route, the bus stop and the time of the day. To explore this error, data corresponding to 18 bus on route “19B” and bus stop “Madhya Kailash” were selected as an example. The errors 19 were categorised into different groups, depending on the time of the day and the time to reach the 20 bus stop. The mean error values were calculated separately for each category. Separate values 21 were obtained for positive and negative errors. A positive error occurs when the bus reaches 22 earlier than predicted and a negative error occurs when the bus reaches later than predicted. A 23

Basu and Vanajakshi 11 sample data is presented in Table 2. It can be seen that reasonable errors exist when the 1 prediction horizon is more than 30 minutes. Thus, if a user queries more than half an hour before 2 the time of travel, the solution given may have errors upto 5 minutes. These should be absorbed 3 by the solution in order to prevent the solution from changing drastically. 4 5

TABLE 2 Mean error values (all values in seconds, magnitude only) 6

Time to reach bus stop

Period 1 Period 2 Mean positive

error Mean

negative error Mean positive

error Mean negative

error > 1800 295.15 135.33 293.55 111.52

1200 - 1800 114.47 67.48 229.37 135.52 600 - 1200 85.41 43.8 119.34 55.08 300 - 600 67.75 41.42 88 63.04

< 300 36.67 5 52.17 25.625 7

To incorporate the above errors, an error function was constructed, which took into 8 account the time of day, the bus stop ID concerned, the route ID and the time of query. Let 𝑡!" be 9 the ETA at time 𝑡!. Let 𝑡! be the actual/observed time of arrival at the bus stop. To buffer the 10 expected time of arrival, error limits were imposed as shown in equation (1). 11

12 𝑡!" − ∈! ≤ 𝑡! ≤ 𝑡!" + ∈! (1)

Here ∈! represents the magnitude of mean positive error and ∈! represents the 13

magnitude of the mean negative error. It is difficult to choose the error value since 𝑡! is unknown 14 at the time of prediction. Hence, the error values of (𝑡!" − 𝑡!) from pre-computed tables such as 15 Table 2 are used. To ensure that this solution remains valid with a high probability, bounds are 16 placed on the predicted data to consider the worst-case scenario. This also ensures that the 17 solution or the cost function value does not fluctuate, so that the user gets an upper limit value of 18 total time of the journey. In other words, this leads to the generation of conservative solutions. 19

The sample real-time query presented earlier is explored again, with lower and upper 20 bounds placed on the ETAs with the help of error function. Table 3 provides the bounds on the 21 ETAs. The scenario notation remains the same as earlier. Plot of the cost function value against 22 scenario is shown in Figure 4. It can be observed that the cost function value does not fluctuate at 23 all after the trip begins due to inclusions of bounds. Hence, the error function proves to be a 24 useful feature to reduce fluctuation in the solutions (and corresponding cost value). 25

However, if the user decides to obtain a dynamically optimised solution, then an alternate 26 mode of solution generation is adopted. This feature termed as “LiveUpdate Mode” is offered as 27 a choice at the time of query. Under this feature, the user is initially provided with an optimised 28 solution based on data available at the time of initial query. This solution is then updated and 29 may be modified depending on conditions, to provide the user alternate travel routes that are 30 optimal. The term "stop-wise" is used since the solution is updated at each bus stop in the transit 31 path of the initial solution so that the user is able to make a transfer in case the alternate optimal 32 path is preferred over the current path. Moreover, the latter option is especially useful for the 33 user in case the original solution suggested by the trip planner is void due to delays, congestion, 34 etc. This could often lead to missed transfers, and thus necessitates an alternate solution to be 35 presented to the user. 36

37

Basu and Vanajakshi 12

TABLE 3 Bounds on ETAs: Real-time sample query (UB – Upper Bound, LB – Lower 1 Bound) 2

Scenario Time of Query

Bus Stops Walk & Ticket Time

Boarding: MRTS

Cost Karapakkam Madhya Kailash Kasturbai

Nagar

Chennai Beach Station LB UB LB UB

1 11:48 12:14 12:19 12:38 12:45 12:54 13:11 13:40 5104 2 12:09 12:17 12:21 12:41 12:48 12:57 13:11 13:40 5430 3 12:30 N/A N/A 12:38 12:44 12:53 13:11 13:40 5104 4 12:32 N/A N/A 12:36 12:43 12:52 13:11 13:40 5104 5 Actual 12:19 12:43 12:52 13:11 13:40 5104

3

4 FIGURE 4 Cost function value against scenario with error function. 5

6 Through experimentation, it was found that a higher population size gives better diversity 7

that helps to prevents early convergence to a local minima and increases the chance of finding 8 better solutions, but this also increases the computation time. Hence, a modification in algorithm 9 was carried out to achieve the dual objective of diverse population set and less computation time. 10

The algorithm was segmented so that the search space could be narrowed down during a 11 real-time query. Hence, partial network solution was generated beforehand and stored as solution 12 files. The solutions stored in these files could be retrieved and temporally validated during a 13 real-time query. In this manner, the initialisation step could produce a diverse population since it 14 would get enough time for computation. 15

In the segmented algorithm, seed individuals (solutions from a pre-calculated solution 16 pool) were injected into the population during initialisation. Two different seeding mechanisms 17 were identified and tested on the bus network data available. In the first mechanism, the usual 18 procedure for initialisation was carried out; hence the initial population was created using 19 solutions built by random selection of genes and appending, till a predefined population limit 20 was reached. In the second mechanism, a modified initialisation technique was suggested which 21 involved crossover and selection operation on the set of solutions obtained during initialisation. 22

In the first mechanism, initialisation was performed, with a chromosome limit of 10. And 23

Basu and Vanajakshi 13 in the second mechanism, initialisation with a chromosome limit of 30 followed by random 1 crossover step, with equal fitness assigned to each chromosome was carried out. The probability 2 of crossover was 0.8 (Pc = 0.8). After the solutions to the network problem were generated and 3 stored, these could be retrieved whenever a query was made to seed the GA. After retrieving the 4 partial network solutions, these would be assigned a cost value based on the real-time data 5 available at the time of query. Following this, the usual mating step is carried out. The two 6 seeding mechanisms mentioned above were tested and the number of nodes reached in the 7 second scenario was considerably more compared to that in the first scenario (20.41% 8 approximately). Hence, due to the advantage offered, the seeding mechanism proposed in the 9 second scenario was chosen. 10 11 Computing Time in Segmented Algorithm 12 The time required to produce solutions for a query in case of segmented algorithm was obtained 13 for multiple iterations, to find out the variation in time required to produce valid solutions from a 14 solution file. An origin node “Saidapet” and time of travel as 10:30 am was selected. A total of 15 24 valid iterations were produced, which implies that a total of 24 destination nodes could be 16 reached from the selected origin node, that is, “Saidapet”. The average time taken to compute 17 each solution was found to be 0.02 seconds and the standard deviation was calculated and found 18 to be 0.01 seconds. Thus, segmentation produced results faster than the basic algorithm. 19 20 APPLICATION DEVELOPMENT 21 The above findings have helped in determining the essential requirements of a trip-planner that 22 operates at both the static and real-time levels. The trip-planner was implemented for a set of 23 routes within the MTC using Genetic Algorithm (GA) based framework. Once satisfactory 24 results were obtained for the static networks, the algorithm was implemented with real-time data. 25 A survey was conducted to understand the needs of a typical bus commuter in the city of 26 Chennai and based on those suitable modes of information dissemination were developed. A 27 dedicated website aimed at static route planning and a mobile application aimed at real-time 28 route planning, were developed. The mobile application gives the user to choose real time 29 updates, if interested. Such a real-time strip-planner would enable a user to access the 30 information on the go and the user can opt for a route that matches their requirements, both 31 “conservative” as well as a dynamically updated solution. 32 Once such a solution is open to the public, the problem of handling multiple queries in 33 real time can be a major practical issue and is discussed in the section below. 34 35

Basu and Vanajakshi 14 Handling Multiple Queries in Real-Time 1 If multiple requests were sent to the trip-planner simultaneously, it would lead to delays. A way 2 of optimising computing time in case of multiple simultaneous queries is to maintain a cache, 3 which is like a container that would store recent queries. Results of previous queries were stored 4 in Temporary Solution Files (TSF) and were assigned a Validity parameter that would denote the 5 time after which the solution file would no longer be valid. Each time a fresh query was made, 6 the TSF would be checked. This cache would help when there are multiple similar (same origin 7 and destination) queries in the queue. To evaluate the performance of this, three queries were 8 sent to the trip-planner, with similar first and last query, and the intermediate query for a 9 different origin and destination. It was observed that, due to the cache, solution to the repeated 10 query (query 3) was generated 56% faster compared to the scenario without a cache. 11 12 SUMMARY AND CONCLUSION 13 The present study was an attempt towards developing a trip-planner operating at both the static 14 and real-time levels for the Metropolitan Transport Corporation (MTC) bus service. The MTC 15 bus service often does not conform to the timetable due to a variety of reasons, like the 16 uncertainty associated with Indian traffic due to heterogeneity and lack of lane discipline, delays 17 caused due to traffic jams, etc. These factors often lead to delays and hence commuters have to 18 suffer, as a consequence of which they shift to private modes of transport. 19

An accurate trip-planner can address this issue to a great extent and is the motivation for 20 the present study. The study developed a trip-planner using Genetic Algorithm (GA) based 21 framework. The trip-planner was initially implemented for a set of routes within the MTC, 22 considering it as static. Once satisfactory results were obtained for the static network, the 23 algorithm was implemented with real-time data. It was noted that the prediction values contained 24 an inherent error that could sometimes lead to breakdown of solution suggested to the user, 25 during the journey. To resolve this issue, an error function was created. Further, inclusion of 26 MRTS data showed that this framework could be integrated with other modes of public transport. 27 In order to speed up the GA based framework, the algorithm was segmented and a temporal 28 cache was introduced. Overall, the results showed that there is great scope for scalability and 29 citywide implementation of the real-time route planner developed in this study. The only 30 requirements would be GPS data obtained from the buses and any other mode of transportation 31 that is included. The algorithm is is optimised to be computationally efficient and can be easily 32 deployed as long as network information is available for a locality. The solution can be easily 33 used for other public modes of travel, thereby expanding the network information available to a 34 commuter. Web based and mobile based applications were developed for disseminating this 35 solution based on the requirements of the users identified based on surveys. 36

As a future extension, the cost function could be improved and the weights could be 37 altered for travel and waiting time based on field experiments and user surveys. Instead of a 38 linear equation based cost function, a criterion based on pareto-optimality could also be looked 39 into. Introduction of a recommender system that would suggest similar solutions to similar group 40 of people (similarity based on factors such as economic background, gender, age group, etc.), 41 which may accommodate each group's needs and preferences can also be attempted. 42 43 ACKNOWLEDGEMENT 44 The authors acknowledge the support for this study as a part of the sub-project 45 CIE/10-11/168/IITM/LELI under the Centre of Excellence in Urban Transport project funded by 46 the Ministry of Urban Development, Government of India, through letter No. 47

Basu and Vanajakshi 15 N-11025/30/2008-UCD. 1 2 REFERENCES 3

1. Vanajakshi,L., S.C. Subramanian, and R. Sivanandan. Travel time prediction under 4 heterogeneous traffic conditions using global positioning system data from buses. InIET 5 Intelligent Transport Systems, Volume 3, 2009, pp. 1-9. 6

2. Genetic Algorithms, Hiu W. http://www.doc.ic.ac.uk/~nd/surprise_96/journal/ 7 vol1/hmw/article1.html, Accessed Aug 4, 2014. 8

3. Obitko M.Genetic Algorithms. http://www.obitko.com/tutorials/genetic-algorithms 9 /index.php. Accessed Aug 5, 2014. 10

4. Nanayakkara S. C., S. Dipti, L.W.Lup, G. Xavier, T. Elizabeth and S.H. Ong.Genetic 11 Algorithm Based Route Planner for Large Urban Street Networks. InIEEE Congress on 12 Evolutionary Computation, 2007, pp. 4469 - 4474. 13

5. Nilesh, B.,R. Dillip, N. Goel, P. Vedagiri and Tom V. Mathew. Multimodal Public Transit 14 Trip Planner with Real-Time Transit Data. In 2nd Conference of Transportation Research 15 Group of India (2nd CTRG), 2013, pp. 775-784. 16

6. Rahim A., F.Samadzadegan. Time-dependent personal tour planning and scheduling in 17 metropolises. InExpert Systems with Applications, Vol.38, 2011, pp. 12439 - 12452. 18

7. Chen, C., R. Kitamura, and J. Chen. Multimodal daily itinerary planner interactive 19 programming approach. In Transportation Research Record: Journal of the Transportation 20 Research Board, No. 1676, Transportation Research Board of the National Academies, 21 Washington, D.C., 1999, pp. 37-43 22

8. Jariyasunant, J., E. Ma, and R.Sengupta. Algorithm for Finding Optimal Paths in a Public 23 Transit Network with Real-Time Data. In Transportation Research Record: Journal of the 24 Transportation Research Board, 2256, 2011, pp. 34-42. 25

9. Kumar, M., Husian, M., Upreti, N., Gupta, D. Genetic algorithm: review and application. 26 InInternational Journal of Information Technology and Knowledge Management, Vol. 2 27 No. 2, 2010, pp. 451 - 454. 28

10. Yajuan, D., and S. Hu. Route Optimization of Multi-modal Travel Based on Improved 29 Genetic Algorithm. InInternational Conference on Transportation, Mechanical, and 30 Electrical Engineering (TMEE), pp. 1701 - 1704. 31

11. Goldberg, D. E. Genetic Algorithms in Search, Optimization, and Machine Learning. 32 Addison-Wesley Publishing Company, Inc., Mass., USA, 1989. 33