An adaptive scaled network for public transport route optimisation
 276 Downloads
Abstract
We introduce an adaptive network for public transport route optimisation by scaling down the available street network to a level where optimisation methods such as genetic algorithms can be applied. Our scaling is adapted to preserve the characteristics of the street network. The methodology is applied to the urban area of Nottingham, UK, to generate a new benchmark dataset for bus route optimisation studies. All travel time and demand data as well as information of permitted start and end points of routes, are derived from openly available data. The scaled network is tested with the application of a genetic algorithm adapted for restricted route start and end points. The results are compared with the realworld bus routes.
Keywords
Public transport Route optimisation Network design Benchmark instance Genetic algorithm1 Introduction
In the majority of cities around the world, public transport networks have been developed using a combination of local knowledge, planning experience and published guidelines. Most often these networks have evolved over time rather than being designed as a whole (Mumford 2013). Multiple reports have pointed out the insufficiencies of this process and the need for a systematic computerbased approach (see e.g. Zhao and Gan 2003; Nielsen et al. 2005).
The task to generate efficient public transport networks can be treated as five interconnected phases (Ceder and Wilson 1986): (1) route design, (2) vehicle frequency setting, (3) timetabling, (4) vehicle scheduling and (5) crew scheduling. Solving all five phases simultaneously would be optimal. However, due to the high complexity of the task, most researchers focus their efforts on simplified versions of the problem. One common simplification is to focus on the route design phase under the assumption of a fixed transfer time between different routes. This approach will also be used in this paper.
Research for public transport route optimisation requires information on the available transport network and the travel demand. These combined datasets are usually referred to as instances. Many researchers have tested their algorithms on the few fully published instances. A prominent example is the instance published by Mandl (1979) [used e.g. in Ahmed et al. (2019), Arbex and da Cunha (2015) Baaj and Mahmassani (1991), Fan and Mumford (2010) and Nayeem et al. (2014)]. Another often used test instance [e.g. used in Poorzahedy and Safari (2011) and Soehodo and Koshi (1999)], a 24node network published by Leblanc (1975), is based on the city of Sioux Falls, USA. As these two instances are rather small (15 and 24 nodes), Mumford published four larger instances ranging from 30 to 127 nodes, based on the Chinese city Yubei and the two UK cities of Brighton and Cardiff (Mumford 2013). These have been used by several studies since (e.g. John et al. 2014; Nayeem et al. 2014). In addition to these studies, other researchers built their own test instances based on data from urban areas around the world. Among these are Silman et al. (Haifa, Israel, 1974) (Silman et al. 1974), van Nes et al. (Groningen, Netherlands, 1988), Pattnaik et al. (Madras, India, 1998) (Pattnaik et al. 1998), Feng et al. (TaoyuanCounty, Taiwan, 2011) (Feng et al. 2010), Cipriani et al. (Rome, Italy, 2012) (Cipriani et al. 2012), or GutiérrezJarpa et al. (Concepcíon, Chile, 2017) (GutierrezJarpa et al. 2017).
Few publications describe the rules of instance generation in detail. One exception is the work by Mauttone and Urquhart (2009) who generated a network with 84 nodes to represent the city of Rivera, Uruguay. The nodes were placed on street junctions close to the centres of housing blocks. This method is only suited to cities built in a strict grid pattern. Another node selection algorithm was proposed by Bagloee and Ceder (2011) to generate instances for Winnipeg, Canada, and Chicago, USA. They select every stop point as a node provided it is further than 300 m from another with a higher expected travel demand. A similar method was also used by John (2016) to generate networks for the UK cities of Nottingham and Edinburgh. Here a fixed number of stops was selected randomly while a minimal distance between selected stops was ensured.
The methods from Bagloee and Ceder (2011) and John (2016) are applicable to most urban areas, but both share the same disadvantage: as the locations of the selected stops within the street network are not fully taken into account, the chance that the resulting network does not reflect the real spatial layout of the city is high (John 2016), especially if the number of selected stops is only a fraction of the total number available.
As the layout of the street network is essential for the design of bus routes, it is important that an instance network sufficiently reflects the characteristics of the street network. We therefore propose a network design procedure which scales down the network to a size manageable for metaheuristicbased optimisations, while at the same time preserving the characteristics of the urban street network. Scaling down an urban street network is desirable principally to restrict the computation times needed for the passenger objective, which is usually the main bottleneck and leads to an increase of the run time with \(f(N^3)\), N being the number of nodes in the network [see Mumford (2013) for a full explanation]. For our modest desktop set up,^{1} we determined 500 nodes, which would result in a runtime of about 600 h, to be the uppermost limit for practical work.
The downscaling of the street network is achieved by devising simple and robust rules applicable to all urban layouts. The procedure further includes the identification of potential terminal nodes, an aspect vital for route design in an urban context.
We will limit this work to instance generation and route network optimisation with restricted start and end points, as it is part of an incremental approach to more realistic public transport network optimisation. Our generation procedure is used to produce an instance for bus route optimisation in the extended urban area of Nottingham, UK. Further, a route initialisation procedure and a modified heuristic route optimisation algorithm, both specialised for work with restricted route start and end points, are applied to the generated instance. The optimisation results are compared to the realworld bus routes.^{2}
 1.
A novel methodology for generating an instance dataset, by systematically scaling down a street network and utilising census data (see Sect. 2). The generated instance will be published online for free use for all researchers.
 2.
An additional methodology for transforming preexisting public transport routes to fit the scaleddown street network (see Sect. 4).
 3.
A multiobjective genetic algorithm modified for restricted route start and end points, to allow direct comparison with the preexisting public transport routes, showing potential to improve performance (methodology in Sect. 3 and results in Sect. 5).
2 Generating a scaled instance network for bus route optimisation
2.1 Problem description
An available transport network can be represented as an undirected graph \(G=\{N,E\}\), with nodes \(N=\{n_1,n_2,\ldots ,n_{N}\}\) representing access and interchange points (see Sect. 2.3.2) and links \(E=\{e_1,e_2,\ldots ,e_{E}\}\) representing the edges (e.g. streets) connecting the nodes (see Sect. 2.4). Given such a graph, a public transport route can be represented as a list of directly connected nodes \(r=[n_f,\ldots ,n_l]\) and the public transport network as a set of routes \(R=\{r_1,r_2,\ldots ,r_{R}\}\). It is necessary to ensure that the first and the last node on each route is a designated terminal node \(V=\{v_1,v_2,\ldots ,v_{V}\}\in N\) which allows uturns (see Sect. 2.5 ). Travel times T and travel demand D are symmetrical matrices as defined below.
 T:

Gives the travel times \(t_{i,j}\) along the connection between the nodes \(n_i\) and \(n_j\). Travel times between nodes that are not directly connected are set to \(t_{i,j}=\infty\) and self connections are set to \(t_{i,i}=0\).
 D:

Gives the number of passengers \(d_{i,j}\) travelling from source \(n_i\) to destination \(n_j\). Travellers staying at one node are not considered (\(d_{i,i}=0\)).
2.2 Definitions

Catchment radius c:
Defines circular catchment areas around the nodes used to assign travel demand (see Sect. 2.6). For the Nottingham instance we used \(c=400\) m, a value widely considered as an acceptable walking distance to a bus stop (Ammons 2001).

Snapping Distance s:
Distance within which two or more junctions are snapped together to be represented by one single node in between (see Sect. 2.3.2). The value for this snapping distance is not critical and has been chosen to be \(s=c\cdot \sin (\frac{\pi }{4})\), resulting in \(s=283\,\text {m}\).
2.3 Constructing the network
The first step is to select which streets will be taken into consideration for the network. This is followed by a process to determine the positions of the nodes on the street map.
2.3.1 Defining the street network
For the Nottingham application we base our selection of streets on the integrated network layer from 2011^{3} generated by the UK Ordnance Survey.^{4} We selected all streets classified as “A”, “B” or “Minor Road”. Streets classified as “Local Street” were only selected if they fulfil two conditions: (a) bus stop points exist alongside them^{5}; (b) they are not parallel to any street classified as “A”, “B” or “Minor Road” within a distance s. Oneway streets are only selected if travel in the other direction is possible on streets within s.
2.3.2 Placing nodes
With the streets selected, the positions of the nodes N need to be determined. In contrast to the instances generated by Bagloee and Ceder (2011) and John (2016), the nodes in our network do not directly represent bus stop points. Instead they usually represent street junctions. The interpretation is not that buses stop at each node but rather that they travel from node to node and stop at the stop points they encounter on the way. The nodes simply allow us to identify the path a bus will take.
 1.
Initial nodes are placed on all points where two or more of the previously selected streets meet. This includes junctions, (t)intersections, roundabouts, etc.
 2.
Nodes within a distance s of each other form clusters, and each cluster of nodes is snapped together to form a new node. This leads to a simplification error of up to \(\frac{s}{2}\) for the distance between two nodes, but removes the clustering nodes (see Figs. 2, 3).
 3.
It can happen that two directly connected nodes are too far apart to assign all the demand from zones along the connection to one of the nodes (see Sect. 2.6). In these cases additional nodes need to be placed inbetween the regular nodes to properly capture the demand for a bus route along this route (see Fig. 4). The same situation might occur in case of deadend streets which are longer than c.
2.4 Generating links
After placing the nodes, a travel times matrix T is required for the optimisation stage. Thus the travel times \(t_{i,j}\) between connected nodes need to be determined. We do this by calculating along the shortest path between two directly connected nodes using ArcGIS. The process takes turning restrictions and traffic calming zones into account. The details are given in Appendix 1. Travel times between nodes that are not directly connected are set to \(t_{i,j}=\infty\) and self connections are set to \(t_{i,i}=0\).
2.5 Determining terminal nodes
One often overlooked aspect in route optimisation studies is that public transport routes cannot terminate everywhere, as this implies that the vehicles are able to turn around and traverse the route in the opposite direction. Therefore, possible terminal nodes require sufficient infrastructure to perform uturns. It is vital to take this constraint into account when modelling realworld data in an urban context (see e.g. Amiripour et al. 2014).
While it is possible to check the surrounding area of every node manually for turning possibilities, this process would be very timeconsuming. Instead we identified possible terminal nodes based on the journey patterns of realworld buses. These journey patterns can be extracted in the form of lists of traversed stop points from the UK’s 2011 National Public Transport Data Repository (NPTDR).^{6} The stop point lists are then projected on the generated instance network (this process is described in Sect. 4.2). This allows us to determine the nodes at which realworld journey patterns end, either by leaving the study area or by using an existing turn possibility to start the journey in the reverse direction. There may be further nodes which offer such possibilities and are not used by the existing routes. However, as this method already identified 168 terminal nodes in our Nottingham instance (39% of all nodes), we are confident that this process is sufficient. Four additional nodes had to be added to the list of terminal nodes. These are deadend nodes and in the algorithm used in this paper can only be included at the beginning or end of a route. For them, manual examination ensured the turning possibilities.
2.6 Assigning travel demand
The final step is to generate a nodetonode travel demand matrix D for the network, which gives the demand \(d_{i,j}\) between the nodes \(n_i\) and \(n_j\), with (\(d_{i,i}=0\)).
Generating a fully realistic travel demand dataset is a very complex task and not within the scope of this work. What we will show here is not a process for extracting travel patterns from raw data sources, but rather a method to transform given travel data between specified zones to a nodetonode demand matrix. Zonal demand data can be generated in different ways. One option is to estimate the number of trips between zones based on the number of origins and destinations in each zone and other parameters [see e.g. Wills (1986) or Wilson (1969)]. This methodology, however, depends much on the quality of the land use data and requires trip survey data or trip counts for calibration. Another methodology well studied in recent years is to extract the travel demand from mobile phone data [see e.g. Golding (2018) or Zhang et al. (2010)], which requires the cooperation of one or several telecommunication companies. A third option is to use survey data. Producing trip surveys is usually time consuming and expensive, and it is preferable to try to access existing survey data if available. In our case we used traveltowork flow data from the 2011 UK census. It lists the number of commuters from all output areas (in the following origin zones) to all workplace zones (in the following destination zones).^{7}

Natural or manmade barriers (rivers, rail tracks, etc.) prevent the commuters from having access to the part of the street network the node represents.

If a centroid is outside of the catchment area of any node, even when its associated zone overlaps with one or more catchment areas, then these catchments are extended to include this population. (This is to reduce the number of additionally placed street nodes as described in step 3 in Sect. 2.3.2).

A street node (see step 3 in Sect. 2.3.2) represents the whole street and not just the point where it is placed. (This removes the need to place several nodes along longer streets.)
There are of course problems with using traveltowork data to generate the demand matrix. It represents only a subset of all trips, e.g. trips for shopping or leisure purposes are not included. We will therefore in the following limit our comparisons with the realworld bus routes to the morning rush hour when trips to work dominate the overall travel pattern. This represents a sufficient estimate for this step of our incremental approach. It is worth noting that the demand matrix does not have to be an accurate count of trips but only a weighting for the trip demand within the generated instance network.
3 Optimisation procedure
The main goal of this paper is to present a new approach to bus route network design. Thus, we use a genetic algorithm (GA) here simply to produce some viable results to demonstrate the potential of the new network design method. Improvements to the optimisation procedure will follow as future work. For our present purpose, we have implemented an NSGAII algorithm based on the one in John et al. (2014), making some necessary changes to the initialisation process and the genetic operators to accommodate the specified terminal nodes in our Nottingham instances [in the paper by John et al. (2014), any node in the network could act as terminal node for a route].
3.1 Initial definitions
3.1.1 Passenger and operator objectives
Optimisation will attempt to minimise the travel times for individual passengers, while at the same time ensuring the cost to the bus company is reasonable. Our objectives are the average travel time as cost for the passengers, and the total drive time of the route sets as cost for the operator. These are the same objective functions which have been used in John et al. (2014) and other studies (e.g. Mumford 2013). We are using them as it is our aim to only adapt the algorithm described in John et al. (2014) for the use of terminal nodes. Changes to these objectives are possible but beyond the scope of this paper.
Changes in route frequency would effect both costs for the operator and the average travel time, which would in turn require a reoptimisation of the route design. For the present we will set a standard headway of 10 min, in line with UK Government definitions for frequent services (Turfitt 2018).
3.1.2 Optimisation constraints
 1.
Each route set R consists of a predefined number of routes, R
 2.
Each route r in a route set R will consist of a number of nodes greater than or equal to \(l_{min}\), and less than or equal to \(l_{max}\): \(l_{min} \le r \le l_{max}\).
 3.
No route fully overlaps with another route in the same set.
 4.
The route set is connected—it is possible to travel between each pair of nodes in the transport network.
 5.
Each node \(n_i\) is present in at least one route in a route set.
 6.
No loops or cycles are present in a route.
 7.
Buses travel back and forth along each route, for which the inbound journey is the reverse of the outbound journey.
 8.
There is a fixed waiting/transfer time for passengers transferring from one route to another.
 9.
Each route r begins and ends at a terminal node \(v \in \{v_1,v_2,\ldots ,v_{V}\}\), where buses can turn around.
3.2 Heuristic construction of route sets
 1.
production of a shortest path usage map and a transformed shortest path usage map
 2.
generation of candidate routes to form a palette of routes
 3.
selection of candidate routes to form route sets
3.2.1 First step: constructing a shortest path usage map and transforming it
We use the technique described in Kiliç and Gök (2014) to create a demand map based on edge usage. The process begins by evaluating shortest travel time paths between each pair of nodes for which there is a source to destination travel demand. Then, by recording the total usage of each edge (assuming that each passenger is able to travel along their shortest path) it is an easy matter to create a ‘shortest path usage map’.
Next we perform a simple transformation on the usage map, to reverse the ranks of the labels on the edges. This is where our technique diverges from that of Kiliç and Gök (2014), who convert the usage values directly into edge selection probabilities. In our approach we transform usages into distances, so that the highest usage value becomes the shortest distance and vice versa. We use these transformed values in a deterministic way to create routes, based on shortest path distances through the transformed usage network. The transformation is achieved simply by subtracting the usage on each edge from the total demand for the network as a whole.
3.2.2 Second step: generating candidate routes
This second step produces a palette of routes from which selections can be made to construct the initial population of route sets for our GA. It makes sense to ensure that edges with the highest usage occur in one or more routes within the palette. On the other hand, the inclusion of less busy links will almost inevitably be required to satisfy some of the demand. Thus, although our algorithm begins by selecting the busier edges, the weight on each edge will be very slightly increased every time it is selected, so that the more times an edge is chosen, the less likely it is to be chosen again. We use an arbitrary factor of 1.1 (chosen after some sensitivity tests), making the updated weights equal to 1.1 times the previous weight.
In our initialization we ensure that all routes generated for the route palette begin and end at a terminal node. To this end, our algorithm iterates through all pairs of terminal nodes in turn, choosing the sourcedestination pair with the highest total demand first, and then the pair with the secondhighest total demand, and so on. The algorithm then selects the sourcedestination node pairs from a presorted list (on total demand for each node pair), created at the start of this second step. For each pair of terminal nodes, the shortest paths from source to destination are then computed according to the transformed demand usage map. (Note: the edge weights for the shortest paths here are entirely different from those used in stage 1. The stage 1 weights are travel times, but the stage 2 weights are transformed demand usages).
Each shortest path through the transformed usage map forms a candidate route which can be added to our route palette. Following the creation of each new route, the transformed demand usage map is updated by applying the factor 1.1 to the edge weight of each link selected for the route. The iterations cease once we have included each of the nodes in the instance in at least one of the routes included in our palette. It is likely that the algorithm iterates more than once through the list of terminal node pairs, to ensure that all the nodes are included somewhere in the palette. One further point is that in the presence of problem constraints, such as limitations to the lengths of the routes, our procedure will discard any routes that do not obey all the constraints. However, the transformed usage map is updated, whatever the outcome. It is worth noting that, if the imposed constraints are too severe, it may not be possible to generate a route set that obeys all of the constraints, so care is needed when setting the parameters for an instance.
The question now arises whether it is possible to construct legal route sets by making selections from the routes generated by our heuristic construction method. To begin with, we delete duplicate routes from our palette of routes. In the next paragraph we describe a simple method to select and aggregate subsets of routes from the above palette of routes to form route sets that obey all the constraints.
3.2.3 Third step: forming route sets by combining routes from the palette of candidate routes
We select routes from the palette one at a time until we have generated an initial population, of route sets \(P_0\) (50 for our experiments), each containing exactly R (i.e. 69) routes. For the first route set, the procedure begins by selecting the first route in the palette. We then add further routes in such a way that: (1) the chosen route has at least one node in common with a route already in the selected subset (beginning with just the first route), and (2) the addition of the selected route maximises the proportion of new nodes included, related to the total number of nodes in the candidate routes. At each iteration, the current subset of routes is tested for inclusion of all the nodes present in the instance. Once all the nodes are present, unused routes from the palette are added at random until the first route set contains R routes. To generate the second route set for the initial population, the second route in the palette is the first route to be selected, and the third route set is seeded with the third route in the palette, and so on.
3.3 Genetic algorithm
3.3.1 Outline of our implementation of NSGAII
To save space we do not give full details of the genetic algorithm here, but refer the interested reader to Deb et al. (2002) and John et al. (2014). In summary, let \(P_0\) be an initial population with P route sets. All these route sets are evaluated and sorted into a series of Pareto fronts (\(f_1, f_2,\ldots\)) based on their level of domination. Each solution is assigned a fitness value according to its front membership, with \(f_1\) being the fittest, \(f_2\) the second fittest, and so on. An offspring population \(Q_0\), also of size P, is then generated from \(P_0\) through binary tournament selection, crossover and mutation (see Fig. 5).
Next, the combined (mating) population \(M_{0} = P_{0} \cup Q_{0}\) is used to select P route sets as a new parent population \(P_1\). This selection is primarily based on domination, but crowding distance is also taken into account (see Fig. 5). Crowding distance is an additional fitness measure used to obtain a wide spread of solutions that adequately covers the full extent of the Pareto front (Deb et al. 2002). \(P_1\) is then used to generate \(Q_1\) via binary tournaments, crossover and mutation as previously. The stages of NSGAII repeat for a predetermined number of generations.
3.3.2 The genetic operators
Crossover: In the crossover step, route sets of the current parent population \(P_k\) are selected in binary tournaments and used to generate in total P offspring route sets. For each parent route set it is decided probabilistically^{10} if it is either directly inserted in the offspring population, or if it performs a crossover operation with one other parent to generate an offspring route set. In the crossover operation, routes from both parent route sets are selected in alternation to construct the new route set. The route selection prefers routes which visit nodes not already included in the offspring route set. Before the new route set is allowed to enter the offspring population, a feasibility test is applied (see below). If it fails the test, the crossover process is restarted.

“Delete nodes”: selects a route at random, ensures that it includes more than two terminals and starts to delete nodes from one of its ends until it reaches another terminal. If less than Z nodes^{12} are deleted in this way, another route is chosen and the process is repeated until at least Z nodes are deleted.

“Add nodes”: selects a route at random and adds nodes at one of its ends. The new nodes are selected by a guided random walk to ensure that the route ends at the next possible terminal. If fewer than Z nodes (see footnote 12) are added in this way, another route is chosen, and the process is repeated until at least Z nodes are added.

“Exchange”: extracts two intersecting routes at random, splits them at one common vertex and forms two new routes from the split paths.

“Replace”: calculates which route satisfies the least demand and deletes it. The route is replaced by a newly generated route^{13}.

“Merge”: randomly selects two routes which share one terminal node and do not overlap elsewhere and merge them into one route. Afterwards a new route is generated\(^{13}\).
Further details of add nodes and delete nodes are given in the appendix Sects. 1 and 2, respectively. The other operators are changed very little from those in John (2016).

“Add missing nodes”: In cases where nodes are missing, we adopt a repair procedure based on that used in Mumford (2013). However, this method required some adaptation to work effectively with predefined terminal nodes and is explained in detail in Appendix 3.

“Replace overlapping”: In cases where one route fully overlaps with another route in the same set, we replace the shorter route with a newly generated route\(^{13}\). Details are given in John (2016).
4 Comparison of optimisation result and real bus routes
One way to evaluate the effectiveness of our bus routing optimisation is by comparison with realworld bus routes. Such comparisons are relatively rare in the available literature. One reason for this could be that the often used published instances, such as the Mandl instance (Mandl 1979), do not come with a given set of realworld bus routes. From the researchers who create their instances, a few have made comparisons with the realworld routes within their study area [e.g. Bagloee and Ceder (2011), Bielli et al. (2002), or Cipriani et al. (2012)].
4.1 Necessary network reduction
For our Nottingham instance generated with the method in Sect. 2, a comparison between the realworld bus routes and the routes generated by the algorithm described in Sect. 3 is not straightforward. As the evaluation procedure for route sets is based on the average travel time between the different nodes, it consequently requires that all nodes of the network are included in the route sets. The realworld route set, however, does not include all the nodes generated by the rules in Sect. 2.3, as bus operators drop those parts of the network they consider too unprofitable. To make a comparison with the realworld routes possible, we first need to generate a reduced version of the Nottingham instance in which all the nodes not visited by the realworld routes are excluded (see Fig. 6).
Excluding the nonvisited nodes essentially generates a second instance network. Travel times between the remaining nodes have to be recalculated and the travel demand has to be reassigned, as described in Sects. 2.4 and 2.6, respectively. Demand from zones which are not within the catchment area of any of the remaining nodes will not be taken into account.
The final reduced instance has 376 nodes, 52 less then the full instance. The total demand is reduced by 14%. In the following we will run experiments with both instances to point out the differences necessary to serve different network sizes.
4.2 Extracting realworld routes
As mentioned in Sect. 2.5, it is possible to extract information about the existing bus routes from the UK’s 2011 National Public Transport Data Repository (NPTDR)\(^{6}\). The NPTDR provides this information in the form of 990 Journey Patterns (JP). A JP consists of a list of stop points the buses traverse and the starting times of the bus journeys. To convert this information into a route set comparable with the results of our optimisation requires a threestep process: filtering JPs by starting time, converting stop points to nodes, and filtering out overlaps.
4.2.1 Filtering journey patterns by starting time
As not all Journey Patterns are in use at a given time, we need to filter out those routes which fit our demand data. As we generated our demand data from travel to work data, we aim to include only JPs active during the morning rush hour into our realworld route set. We therefore select only the 210 JPs which, according to the journey starting times, cover the entire time window of 7:30 am to 10:30 am.
4.2.2 Converting stop point lists to node lists
4.2.3 Filtering out overlaps

If \(\lambda (\omega _{j,i}) = \lambda (j)\): j is fully overlapped by i and is not inserted.

If \(\lambda (\omega _{j,i}) = \lambda (i)\): i is fully overlapped by j and j replaces i.

If \(\lambda (\omega _{j,i})  \lambda (j) \le m_i\) and \(\lambda (\omega _{j,i})  \lambda (i) \le m_i\) and \(\lambda (i))  \lambda (j) \le \frac{m_i+m_j}{2}\) with \(m_x =\text {min}(2,\frac{\lambda (x)}{10})\):
There are only very small variations between j and i. If j’s first journey starts earlier than i’s first journey, j replaces i. Otherwise j is not inserted.
5 Experimental results
We ran two computer experiments. Experiment 1 used the reduced instance (following Sect. 4) and its results can be directly compared with the realworld route set. Experiment 2 used the full instance (following Sect. 2). As the full instance network includes about 14% more nodes than served by the realworld routes the results of experiment 2 cannot be directly compared. However, optimising the route set on the full instance network is, nevertheless, a useful exercise in demonstrating the conditions under which a public transport service for the entire area can be realised.
In each case, we generated \(P=50\) initial route sets and optimised them with the described GA over 200 generations. Each of the route sets has \(R = 69\) routes, the same number as the realworld route set.^{16} For experiment 1 the maximal number of nodes per route was set to \(l_{max}=45\), which is around 10% more than the longest realworld route.^{17} For experiment 2 we used \(l_{max}=52\), to reflect the approximately 14% larger size of the instance network. The minimal number of nodes per route was set to \(l_{min}=3\) for both experiments, one less than the shortest realworld route.
To ease the discussion, the results at four key positions in the Pareto fronts for both experiments are highlighted and compared. At the extremes, the most passengerfriendly route sets (red) and the most operatorfriendly route set (blue) are identified in the figure. Further, in yellow we can see the most passengerfriendly route set with shorter total route length than the realworld route set, while the most operatorfriendly route set with shorter average travel time than the realworld route set is identified in green.
For experiment 1, the highlighted results are shown in more detail in Table 1. From the table we can see that the route set marked in yellow has slightly cheaper operator costs (\(\) 1.24%) than the realworld route set, shortening the average travel time by half a minute. On the other hand, the route set marked in green reduces the operator cost by 12.9%, yet still achieves a better passenger cost (\(\) 0.7%) than the passenger cost for the real route set. The general trend towards higher optimisation potential on the operator side is also present at the extreme ends of the Pareto fronts. We can observe that the most passengerfriendly route set (red), reduces the average travel time by 12.6 % (to 12.5 min) but increases the operatorcost by 69.8%. On the other hand, the most operatorfriendly route set (blue) reduces the operator cost by 46% by driving up the average travel time by 38.5% (to almost 20 min).
While the yellow and green marked route sets of experiment 1 indicate that the realworld routes can be improved upon with our optimisation procedure, yellow and green marked route sets of experiment 2 show that it is possible to construct route sets serving the entire study area producing very similar operator and passenger costs to the realworld route set. The green route set offers approximately the same travel time as the realworld routes (14.2 min), although this comes at an increase in operator cost of about 22.7%. The yellow route set serves the larger network for approximately the same operator cost (\(\) 1.7%) by prolonging the average travel time to 15 min.
Comparison between optimisation results (as highlighted in Fig. 7) and the real world for optimisation criteria and transfer statistics
Real routes  Red  Blue  

Average travel time  14.3 min  12.5 min  \(\) 12.6%  19.8 min  + 38.5% 
Total route length  1369 min  2325 min  + 69.8%  741 min  \(\) 45.9% 
% direct trips  30.6%  39.5%  + 8.9%  16.9%  \(\) 13.7% 
% of 1 transfer trips  54.1%  48.5%  \(\) 5.6%  34.4%  \(\) 19.7% 
% of 2 transfer trips  13.9%  11.1%  \(\) 2.8%  28.0%  + 14.1% 
% of 3 + transfer trips  1.4%  0.9%  \(\) 0.5%  20.7%  + 19.3% 
Real routes  Green  Yellow  

Average travel time  14.3 min  14.2 min  \(\) 0.7%  13.8 min  \(\) 3.5% 
Total route length  1369 min  1192 min  \(\) 12.9%  1352 min  \(\) 1.24% 
% direct trips  30.6%  29.2%  \(\) 1.4%  30.5%  \(\) 0.1% 
% of 1 transfer trips  54.1%  47.7%  \(\) 6.4%  48.5%  \(\) 5.6% 
% of 2 transfer trips  13.9%  20.0%  + 6.1%  18.8%  + 4.9% 
% of 3+ transfer trips  1.4%  3.1%  + 1.7%  2.27%  + 0.9% 
Table 1 further shows transfer statistics of the route sets, another performance measure used in the literature (see, e.g. Feng et al. 2010). The transfer statistics show the percentage of travellers reaching their destination, with none, one, two, three or more transfers. For the four marked route sets we see an evident increase in transfers for route sets with shorter total route length and longer average travel times. This observation is confirmed by the transfer statistics for all route sets shown in Fig. 8. This graphic shows a clear correlation between the passenger cost and proportion of passengers needing to make a specific number of transfers, with the number of passengers making zero or one transfer decreasing and the number making two or more transfers increasing, with increasing passenger cost. This behaviour is present in the results of both experiments indicating that it is independent from the specific network or network size. The reason for it lies in the differences in route coverage density in the network as shown in Fig. 9 for the two extreme Pareto route sets for the full instance. By the route coverage density, we simply mean the number of routes covering each link of the network.
6 Conclusion
In this paper we introduced a new methodology for modelling and scaling down a street network to facilitate optimisation of public transport networks in a realistic way. Furthermore, we built our model using only data that is freely available from public sources. The process involves a systematic placement of nodes on junctions of a street network suitable for bus travel. The travel times between the nodes are generated from street data, the information about potential terminal nodes is derived form existing bus routes, and the travel demand was extracted from UK census data. In the initial study, we applied our techniques to the bus network of greater Nottingham.
We showed that the preexisting public transport routes can be projected onto the generated instance network, allowing the direct comparison between optimisation results and preexisting public routes in a reduced version of the generated instance. Additionally, we adapted an evolutionary multiobjective optimisation algorithm (NSGAII) to operate effectively on our Nottingham instance characterised by restricted terminal nodes (i.e., where buses can turn around). The comparison between our results and the actual 2011 bus routes of the study area indicate that it is possible to reduce both the average passenger travel time and the operator cost simultaneously. Our results further suggest that a bus network optimised for direct travel (i.e. for a fragmented service with many different operators) is not the most effective network for passengers or operators. Given that this work is only the first step in an incremental approach for general public transport optimisation, these results are very promising.
There are several possible directions for future work. One is to improve the instance generation, e.g. by using better resolved demand data, or by generating asymmetric travel time matrices to better capture the impact of turn restrictions in a similar way to what was done in Perugia et al. (2011). Extending the optimisation to one or more of the four remaining phases mentioned in Sect. 1 (Vehicle Frequency Setting, Timetabling, Vehicle Scheduling and Crew Scheduling), is another. Allowing variable numbers of routes in our route sets, is also an important investigation to be carried out, as well as introducing multiple modes of public transport. In addition, many improvements could be made by changes in the objective functions. This may include technoeconomic aspects such as vehicle crowding or required fleet size for more realism [see e.g. JaraDiaz and Gschwender (2003) or Moccia et al. (2018)]. Further, changes to the objective function can also alleviate some of the less realistic constraints for valid route sets. Most notably is the constraint that all nodes have to be part of every route set, which forced us to generate a reduced instance in order to compare our optimisation results against realworld routes.
We provide the instance data as well as the realworld route set, our results and a python program for route set evaluation alongside this paper to allow other researchers to employ their own optimisation algorithm. The material is also available online under https://data.mendeley.com/datasets/kbr5g3xmvk.
Footnotes
 1.
We used a desktop PC with an Intel i56500 3.20GHz Quadcore CPU and 8GB RAM.
 2.
It should be noted that this work focuses on monomodal transport, and the Nottingham tram network, with only two lines in 2011, was not taken into account. For the instance generation, the interoperation of the tram could be included in principle with the rules described in Sect. 2. However, the optimisation algorithm (see Sect. 3) would require modifications beyond the scope of this paper to deal with multimodal optimisation.
 3.
The same year of census data used to assign the demand (see Sect. 2.6).
 4.
Researchers with UK institutional access can download ITN data from http://digimap.edina.ac.uk/. The procedure can also be applied to data from other sources. The only constraints are a sufficient classification to select streets available for bus travel and the ability to convert the data to a network dataset for use in ArcGIS to generating the travel time matrix (see Appendix 1). Such data should be available from most national transport authorities, or local authorities. Alternatively, street data from OpenStreetMap (https://www.openstreetmap.org) can be used as long as it is sufficiently accurate for the study area.
 5.
The location of bus stops can be extracted from the National Public Transport Access Nodes (NaPTAN) which is included in the National Public Transport Data Repository (NPTDR) downloadable from https://data.gov.uk/dataset/nptdr. Outside the UK similar datasets should be available from national transport authorities, local authorities or public transport operators. For operators which use General Transit Feed Specification (GTFS) these datasets can be downloaded from https://transitfeeds.com/. Also OpenStreetMap (https://www.openstreetmap.org) usually provides bus stop locations with a sufficient accuracy.
 6.
The 2011 NPTDR contains a snapshot of every public transport journey in Great Britain in a selected week in October 2011 (UK Department for Transport 2015). It can be downloaded from https://data.gov.uk/dataset/nptdr. For outside the UK, datasets containing lists of traversed stop points as well as the location of stops should be available from national transport authorities, local authorities or public transport operators. For operators which use GTFS, the datasets can be downloaded from https://transitfeeds.com/.
 7.
Output areas and workplace zones are lowlevel census geographical types. They are redefined for every census. Every output area includes between 40 and 250 households (for the 2011 census on average 309 residents). Workplace zones are created using similar criteria to output areas, to capture employment statistics. It should be noted that output areas and workplace zones overlap (UK Office for National Statistics 2016a). The geometries and flow data can be downloaded from https://census.ukdataservice.ac.uk/.
 8.
Population weighted centroids are generated by the UK data service, UK Office for National Statistics, together with the respective areas (UK Office for National Statistics 2016b). They can be downloaded from https://census.ukdataservice.ac.uk/. If using other datasets where the exact distribution of the population within the zones is not known, the geometric center of a zone can be used instead. These can be calculated with GIS software.
 9.
This is in line with the definition for “frequent services” given by the UK Department for Transport, which is to have at maximum 10 min between buses (Turfitt 2018). For Nottingham the majority services in the morning rush hour fall into this category.
 10.
The probability to perform a crossover with another route set is in our case set to \(\rho _{cross}=0.9\).
 11.
We use in principle the same mutation operators as John et al. (2014). The operators Delete Node and Add Node, both originally from Mumford (2013), had to be modified to work with terminal nodes. The operator Exchange is used as it was originally proposed by Mandl (1979). The operators Merge and Replace, both from John et al. (2014), stay as they were, apart from the changes in the route generation procedure. Only the operator Remove Overlapping (John et al. 2014) is deleted from the set of mutations as it is part of the feasibility test.
 12.
\(Z \in [0,\frac{n_{max}}{2}]\) is randomly selected at the beginning of the operation [as in Mumford (2013)].
 13.
The new route is generated by a version of the generation procedure of Shih and Mahmassani (1994) which is modified for the use of terminal nodes. The original procedure selects the node pair with the highest travel demand that is not yet directly connected and generates a shortest path route between them. For the use with terminal nodes it has to be ensured that only terminal nodepairs can be picked.
 14.
It is important to note that for the operation “Delete Nodes” the repair function is disabled as it could undo the mutation.
 15.
It should be noted that some postprocessing is always needed to make sure that all stop points are correctly allocated.
 16.
We have chosen this after a sensitivity analysis showed that changing the number of routes does not lead to a general improvement of results.
 17.
The higher limit reflects the possibilities for planners to construct slightly longer routes than currently exist.
 18.
These routes are not related to the public transport routes we talked about in other sections of this paper. The reason why we use the term again here is to be consistent with the ArcGIS terminology.
 19.Parameters used for “Closest Facility” function:
 Analysis settings:

Impedance: drive (min)

Facilities to find: as many as possible

UTurns at junctions: not allowed

Output shape type: true shape with measures

Use hierarchy: yes

Ignore invalid locations: yes

Restrictions: MandatoryTurnRestrictions, OneWay, TurnRestrictions


Accumulation attributes: drive (min)
 Network locations—finding network locations:

Search tolerance: snapping distance s

Snap to: closest streetnetwork (shape).


 20.Parameters used for locating features along routes function:

Search radius: half snapping distance \(\frac{s}{2}\)

Keep only the closest route location: no

 21.
For the generation of extra routes the same settings for the “Closest Facility” function are used as before. The only differences are that the extra nodes are used as “Incidents” and the “number of facilities to find” is set to 2.
 22.
The expected degree \({\varDelta }_i\) of a node \(n_i\) has to be generated manually.
Notes
Acknowledgements
We are thankful for the very helpful comments and suggestions of three anonymous reviewers. This work is partly funded by the Leverhulme Programme Grant RP2013SL015.
Supplementary material
References
 Ahmed L, Mumford CL, Kheiri A (2019) Solving urban transit route design problem using selection hyperheuristics. Eur J Oper Res 274(2):545–559CrossRefGoogle Scholar
 Amiripour SM, Ceder AA, Mohaymany AS (2014) Designing largescale bus network with seasonal variations of demand. Transp Res Part C Emerg Technol 48:322–338CrossRefGoogle Scholar
 Ammons DN (2001) Municipal benchmarks: assessing local perfomance and establishing community standards, 2nd edn. SAGE Publications, Thousand OaksGoogle Scholar
 Arbex RO, da Cunha CB (2015) Efficient transit network design and frequencies setting multiobjective optimization by alternating objective genetic algorithm. Transp Res Part B Methodol 81:355–376CrossRefGoogle Scholar
 Baaj MH, Mahmassani HS (1991) An aibased approach for tansit route system planning and design. J Adv Transp 25:187–209CrossRefGoogle Scholar
 Bagloee SA, Ceder AA (2011) Transitnetwork design methodology for actualsize road networks. Transp Res Part B Methodol 45(10):1787–1804CrossRefGoogle Scholar
 Bielli M, Caramia M, Carotenuto P (2002) Genetic algorithms in bus network optimization. Transp Res Part C Emerg Technol 10(1):19–34CrossRefGoogle Scholar
 Ceder A, Wilson NHM (1986) Bus network design. Transp Res B 20B(4):331–344CrossRefGoogle Scholar
 Cipriani E, Gori S, Petrelli M (2012) Transit network design: a procedure and an application to a large urban area. Transp Res Part C Emerg Technol 20(1):3–14CrossRefGoogle Scholar
 Deb K, Pratap A, Agarwal S, Meyarivan T (2002) A fast and elitist multiobjective genetic algorithm: NSGAII. IEEE Trans Evol Comput 6(2):182–197CrossRefGoogle Scholar
 ESRI (UK) Ltd (2007) Using OS MasterMap Integrated Transport Network (ITN)\({}^{{\rm TM}}\) Layer with ArcGIS . ESRI (UK) White PaperGoogle Scholar
 Fan L, Mumford CL (2010) A metaheuristic approach to the urban transit routing problem. J Heuristics 16(3):353–372CrossRefGoogle Scholar
 Feng C, Hsieh C, Peng S (2010) Optimization of urban bus routes based on principles of sustainable transportation. J East Asia Soc Transp Stud 7:1137–1149Google Scholar
 Golding J (2018) Best practices and methodology for ODmatrix creation from CDRdata. Technical report, University of Nottingham, Business School, NLABGoogle Scholar
 GutierrezJarpa G, Laporte G, Marianov V, Moccia L (2017) Multiobjective rapid transit network design with modal competition: the case of Concepción, Chile. Comput Oper Res 78:27–43CrossRefGoogle Scholar
 JaraDiaz SR, Gschwender A (2003) Towards a general microeconomic model for the operation of public transport. Transp Rev 23(4):453–469CrossRefGoogle Scholar
 John MP (2016) Metaheuristics for designing efficient routes & schedules for urban transportation networks. Ph.D. thesis, University of CardiffGoogle Scholar
 John MP, Mumford CL, Lewis R (2014) An improved multiobjective algorithm for the urban transit routing problem. In: Blum C, Ochoa G (eds) Evolutionary computation in combinatorial optimisation. Springer, Berlin, pp 49–60Google Scholar
 Kiliç F, Gök M (2014) A demand based route generation algorithm for public transit network design. Comput Oper Res 51:21–29CrossRefGoogle Scholar
 Leblanc LJ (1975) An algorithm for the discrete network design problem. Transp Sci 9(3):183–199CrossRefGoogle Scholar
 Mandl CE (1979) Applied network optimization. Academic Press, CambridgeGoogle Scholar
 Mauttone A, Urquhart ME (2009) A route set construction algorithm for the transit network design problem. Comput Oper Res 36(8):2440–2449CrossRefGoogle Scholar
 Moccia L, Allen DW, Bruun EC (2018) A technology selection and design model of a semirapid transit line. Public Transp 10(3):455–497CrossRefGoogle Scholar
 Mumford CL (2013) New heuristic and evolutionary operators for the multiobjective urban transit routing problem. In: 2013 IEEE congress on evolutionary computation. IEEE, pp 939–946. https://ieeexplore.ieee.org/abstract/document/6557668
 Nayeem MA, Rahman MK, Rahman MS (2014) Transit network design by genetic algorithm with elitism. Transp Res Part C Emerg Technol 46:30–45CrossRefGoogle Scholar
 Nielsen G, Nelson J, Mulley C, Tegner G, Lind G, Lange T (2005) HiTrans Best Practice Guide 2: Public transport – planning the networks. HiTrans. https://www.crow.nl/downloads/documents/13359
 Pattnaik S, Mohan S, Tom V (1998) Urban bus route network design using genetic algorithm. J Transport Eng 124(4):368–375CrossRefGoogle Scholar
 Perugia A, Moccia L, Cordeau JF, Laporte G (2011) Designing a hometowork bus service in a metropolitan area. Transp Res Part B Methodol 45(10):1710–1726CrossRefGoogle Scholar
 Poorzahedy H, Safari F (2011) An ant system application to the bus network design problem: an algorithm and a case study. Public Transp 3(2):165–187CrossRefGoogle Scholar
 Shih M, Mahmassani H (1994) A design methodology for bus transit networks with coordinated operations. Technical report, University of Texas, Center for Transportation ResearchGoogle Scholar
 Silman LA, Barzily Z, Passy U (1974) Planning the route system for urban busses. Comput Oper Res 1(2):201–211CrossRefGoogle Scholar
 Soehodo S, Koshi M (1999) Design of public transit network in urban area with elastic demand. J Adv Transp 33(3):335–369CrossRefGoogle Scholar
 Turfitt R (2018) Statutory Document No. 14 Local bus services in England (outside London) and Wales. Technical report, Senior Traffic Commissioner (UK)Google Scholar
 UK Department for Transport (2015) National public transport data repository. https://data.gov.uk/dataset/nptdr. Accessed 6 June 2019
 UK Office for National Statistics (2016a) Census geography. http://www.ons.gov.uk/ons/guidemethod/geography/beginnersguide/census/index.html. Accessed 6 June 2019
 UK Office for National Statistics (2016b) Census output areas population weighted centroids 2011. https://geoportal.statistics.gov.uk/datasets/ba64f679c85f4563bfff7fad79ae57b1_0. Accessed 6 June 2019
 Wills M (1986) Gravityopportunities trip distribution model. Transp Res Part B Methodol 208(2):89–111CrossRefGoogle Scholar
 Wilson AG (1969) The use of entropy maximising models, in the theory of trip distribution, mode split and route split. J Transp Econ Policy 3(1):108–126Google Scholar
 Zhang Y, Qin X, Dong S, Ran B (2010) Daily OD matrix estimation using cellular probe data. In: TRB 89th annual meeting compendium of papers DVD, Transport Research Board. http://odd.topslab.wisc.edu/publications/2010/Daily%20OD%20Matrix%20Estimation%20using%20Cellular%20Probe%20Data%20(102472).pdf
 Zhao F, Gan A (2003) Optimization of transit network to minimize transfers. Technical report, Florida International University, Department of Civil and Environmental Engineering, Transport Research Board. https://trid.trb.org/view/697978
Copyright information
Open AccessThis article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.