Procedures for planning multi-leg journeys with fixed-route and demand-responsive passenger transport services

Transportation Research Part C 12 (2004) 33–55 www.elsevier.com/locate/trc

Procedures for planning multi-leg journeys with fixed-route and demand-responsive passenger transport services Mark E.T. Horn

*

CSIRO Mathematical and Information Sciences, Australian National University, GPO Box 664, Building 108, North Road, Canberra ACT 2601, Australia Received 13 April 2000; accepted 21 August 2002

Abstract This paper describes journey-planning procedures designed for use in a traveller information system covering fixed-schedule and demand-responsive public transport modes. The task is to construct a sequence of journey-legs to meet a travellerÕs requirements with the least possible generalised cost, subject to timewindow and other constraints. A journey may be carried out in a single leg by walking or by taking a taxi all the way from the origin to the destination, or by a sequence of one or more legs carried by public transport services sandwiched between walked segments connecting an initial pickup and final setdown stop. The public transport services may include fixed-route modes such as bus and train, and demandresponsive services running between fixed points. The main planning procedures are a high-level requestbroker and a branch and bound procedure to handle multi-legged journeys; the request-broker also invokes a fleet-scheduling module to obtain bookings on demand-responsive services. The paper describes planning conditions, the planning procedures, and reduction techniques that are used to obtain acceptable computational performance. Tests with simulated demand suggest that the procedures are well suited for use in a real-time traveller information system. Ó 2003 Elsevier Ltd. All rights reserved. Keywords: Traveller information systems; Public transport; Multi-modal; Demand-responsive; Optimisation; Journey planning; Itinerary planning; Branch and bound

1. Introduction Recent improvements in information and communications technology have made possible the development of a variety of new information services for urban travellers, referred to under the *

Tel.: +1-612-6216-7000; fax: +1-612-6216-7111. E-mail address: [email protected] (M.E.T. Horn).

0968-090X/$ - see front matter Ó 2003 Elsevier Ltd. All rights reserved. doi:10.1016/j.trc.2002.08.001

34

M.E.T. Horn / Transportation Research Part C 12 (2004) 33–55

general heading of Traveller Information Systems. Although some such systems are designed primarily for drivers (providing route guidance, incident warnings, weather information, etc.), many of them are oriented rather to users and prospective users of public transport. Delivery mechanisms for public transport information systems (PTIS) include information kiosks, electronic bus stop displays, on-board information, telephone enquiry services, and networked access mechanisms such as the Internet (Infopolis, 1999). For what may be called ‘‘passive’’ systems, the information provided typically includes public transport timetables (e.g. London, 1999), and impending arrival times obtained through real-time vehicle tracking (e.g. Mehaffey and Lowe, 1997; BT, 1999). This paper is concerned with computational tasks posed by more ‘‘active’’ PTIS, which provide journey-planning services to travellers. Such systems have been introduced recently in a number of cities (e.g. Ventura, 1999; TransPerth, 1999; for an air-travel analogue see ITN, 1999). They embody automated procedures to generate solutions to problems that are posed––at a minimum––in terms of an origin, a destination, and an available set of fixed-schedule transport services. A solution to such a problem is referred to here as a journey comprising one or more legs. Early research published on problems of the kind outlined above used adaptations of DijkstraÕs label-setting algorithm (Dijkstra, 1959), with a network link representing each pair of points (e.g. bus stops) connected directly by a public transport route (e.g. Dial, 1967; Tong and Richardson, 1984). That research was carried out mainly for modelling purposes, but there has since been a greater emphasis on requirements of the ‘‘active’’ PTIS mentioned above, and in particular on explicit provision for interactive usage. Bander and White (1991) developed a multi-leg journeyplanning procedure using the A
variant of DijkstraÕs algorithm, with heuristic adaptations for interactive usage. Han and Hwang (1992) used a hashing technique for efficiency in finding all journeys with one or two public transport legs. A procedure developed by Koncz et al. (1996) is addressed to the more general multi-leg problem, and includes provision for walking between transfer points: this problem is addressed by enumerating all distinct multi-leg journeys, and then selecting the journey with the shortest overall travel time for presentation to the user. Li and Kurt (2000) addressed the problem of finding a journey with minimum ‘‘disutility cost’’, defined in terms of the number of transfers, frequency of service on the selected routes, fares, and perhaps other criteria. Their procedure uses a label-setting procedure to find the K shortest-time journeys, then selects the least-cost member of this ‘‘attractive’’ subset of feasible solutions. A two-step procedure was adopted also by Chen et al. (1999) in their work on an ‘‘itinerary-planning’’ problem. In summary, a set of places is to be visited between the origin and destination points, and an itinerary is defined as a sequence of segments connecting those places, with a transport mode (public transport, car, taxi, or walking) designated for each segment. Although it clearly has PTIS applications, this approach may be pertinent also in an activity-modelling context (see also Abdel-Aty, 1999). The first step of the procedure developed by Chen et al. enumerates all possible itineraries, using DijkstraÕs algorithm to plan travel by each mode in each itinerary-segment so as to minimise generalised costs, and with provision for the logistics of car usage (e.g. in park-and-ride situations). The second step arrives at an ‘‘optimal’’ solution by means of an interactive process in which the userÕs preferences with respect to itinerary attributes are elicited through choices made between successive pairs of alternatives. The procedure is of interest for its treatment of usersÕ preferences, and for its accommodation of private as well as public modes. A similar breadth of approach with respect to available modes may be seen also in

M.E.T. Horn / Transportation Research Part C 12 (2004) 33–55

35

the research of di Febbraro and Sacone (1997), who used neural network techniques to find shortest-time paths in a network synthesised from fixed-route public transport services and travel by private car. The procedures described in the present paper are distinguished from the above-mentioned research in several respects. In the first place, the transport modes considered here include both demand-responsive services (e.g. taxis) and fixed-schedule modes, as in the proposal of Engels (1994). The framework within which these services are represented includes provision for dynamic variability in the availability of demand-responsive services under varying demand, thus allowing greater precision than is possible in more approximate approaches (e.g. the treatment of taxis in Chen et al. (1999). Secondly, a precise treatment is given to the timing of transport services. In previous research the practice has been generally to treat public transport routes as basic units for planning purposes, assuming fixed headways and invariant travel times between each pair of points on each route. For example, the duration of a multi-leg journey is typically calculated as the sum of those times, with (sometimes) a headway-based allowance for waiting at transfer points. By contrast, the present paper plans each leg taken on a timetabled mode as a segment of an actual, timed, run of a given route (cf. Tong and Richardson, 1984). As a result, a journey-planning procedure can be made temporally precise, avoiding any need to assume fixed headways, and assuring robustness in the planning outcomes. This approach to travel timing is accompanied by the use of timewindow constraints in the formulation of travel requirements (cf. Solomon and Desrosiers, 1988; Desrochers and Soumis, 1988). Note however that the term ‘‘envelope’’ is used here for the temporal range of a journey, ‘‘time-window’’ being applied specifically to demand-responsive trips within a journey. Thirdly, the precise approach to travel timing outlined above is combined with an objective of minimising generalised costs, defined as fares plus linear weightings applied to elapsed time (timeminimisation is covered as a special case, with all-zero fares and unitary time-weightings). This makes for greater complexity than formulations involving the simple minimisation of elapsed time or the minimisation of costs in an atemporal context (e.g. Li and Kurt, 2000; Chen et al., 1999). In particular, under the present formulation (as in real life) the range of transport services available in any given leg of a journey––hence the cost of travel––depends on when the leg can be commenced, which depends in turn on when the journey itself can be commenced (i.e. the beginning of the time-window specified for the journey). These inter-relationships between cost and time would invalidate a direct application of conventional shortest-path techniques. For this reason the research described in this paper has entailed the development of a new journey-planning procedure, which is based on a branch and bound algorithm and is guaranteed to find an optimal solution if one exists (see Section 4.2 below). To reduce computational effort (e.g. for practicality in real-time applications), extensive use is made of specialised bounding and reduction techniques. The journey-planning and other procedures are currently embedded within a public transport modelling system called LITRES-2 (Horn, 2002). In summary, a request-broker receives travelrequests from the LITRES-2 simulation modules, and manages the evaluation of single-legged as well as multi-legged journeys to satisfy each incoming request. For multi-legged journeys, the request-broker invokes a journey-planner module, which plans a least-cost journey by reference to pre-defined timetables and information regarding the availability of demand-responsive services.

36

M.E.T. Horn / Transportation Research Part C 12 (2004) 33–55

For a journey-plan that includes any demand-responsive legs, the request-broker uses a fleetscheduler module to establish feasibility and to make bookings. Of the components just mentioned, the present paperÕs main concern is with the planning modules, namely the request-broker and journey-planner. Section 2 of this paper indicates how traveller requirements are specified and describes the distinguishing characteristics of the various transport modes, while Section 3 is concerned with the estimation of travel timing and costs for planning purposes. Section 4 describes the request-broker and journey-planning procedures, and Section 5 describes the bounding and reduction techniques that are used to reduce the scope of search in the journey-planning procedure. Section 6 discusses experience with the procedures in a modelling project and gives some examples of journeys planned in that context. The paper concludes in Section 7 with some remarks about prospects for further research and development. Supplementary technical material is provided in the Appendices and in another paper (Horn, 1999).

2. Travelling conditions 2.1. Traveller requirements A travel-request as considered in this paper specifies the places where a journey is to start and end, the time-range or ‘‘journey-envelope’’ within which travel is to take place, the number of persons wishing to travel together, a set of weighting factors for travel time, and a maximum walking time. These requirements are specified in the notation outlined below. The journeyplanning procedure can apply some additional conditions (e.g. a set of modes acceptable to the traveller and an upper limit on the number of vehicular legs in a journey), but for simplicity these are omitted from further discussion. O, D tOmin tDmax npass wtwalk wtOwait wtIwait wttravel ttmaxwalk

Origin and destination points for the journey. Earliest acceptable departure time from O. Latest acceptable arrival time at D. Number of persons travelling together as a group. Cost-weighting attributed to time walking. Cost-weighting attributed to time waiting at the origin. Cost-weighting attributed to time waiting at interchanges. Cost-weighting attributed to time travelling. Maximum walking time in any one journey-leg (e.g. from limits specified for the travellerÕs walking speed and walked-leg length).

2.2. Transport modes For journey-planning purposes, transport modes are distinguished by their operational patterns and fare structures rather than by the technologies employed. The PT modes are public transport services carrying passengers between pre-defined PT points (e.g. bus stops, railway stations, and

M.E.T. Horn / Transportation Research Part C 12 (2004) 33–55

37

Table 1 Classification of transport modes Mode type

Pickup and setdown

Advertised service

Routing

Booked?

FixedRoute SmartShuttle RovingBus Taxi

PT points PT points PT points Door to door

Timetabled Timetabled Free-range Free-range

Fixed Demand-responsive Demand-responsive Demand-responsive

No Yes Yes Yes

ferry wharves). The demand-responsive modes comprise taxis and hybrid services called SmartShuttle and RovingBus: it is assumed that travel on these modes can be booked (e.g. electronically) upon completion of a journey-plan. Additional terminology is outlined below and summarised in Table 1. (a) FixedRoute modes are conventional services plying between PT points, with routes and timings set out in pre-specified timetables. These modes include Bus, Train, LightRail and Ferry. (b) SmartShuttle is a timetabled service which is provided on demand between PT points, with variable vehicle routing; so for example the portions of the timetable realised by such a service are those for which demand has been notified. SmartShuttle timetables may specify zonebased as well as point-based service. (c) RovingBus is a multiple-hire ‘‘free-range’’ service, with pickups and setdowns restricted to PT points. (d) Taxis are door-to-door free-range services. TaxiSingle is a conventional single-hire taxi service. TaxiMulti can carry more than one group of travellers at once, and could represent a car pool or a dial-a-ride arrangement. Variants of the standard mode types (e.g. for different bus or taxi companies) can be differentiated in terms of fares and service quality standards. In studies conducted so far, the fare structure for timetabled modes is zone-based, while for free-range modes it is distance-based with provision for group concessions. 2.2.1. Inter-modal linkages Travel is envisaged as occurring in a Euclidean plane overlaid by a road network and a quasinetwork comprising public transport services connecting PT points. The PT points, the nodes of the road network, and the origin and destination of each journey, are located in the plane. Demand-responsive vehicles travel by shortest-time paths through the road network, with off-network detours to reach pickup and setdown points. Transfer between PT services is permitted at PT points called interchanges, which can be nominated explicitly or identified automatically by reference to timetables (Horn, 1999). 2.2.2. Specification of timetabled services Timetabled PT services are specified as PT routes, each route being operated by one or more PT runs. A route is a sequence of service locations called PT loci, and a PT run is a sequence of PT stops, each of which is a PT locus with a latest-arrival and earliest-departure time. The generalised

38

M.E.T. Horn / Transportation Research Part C 12 (2004) 33–55

term PT locus may refer to a PT point (e.g. a bus stop), or to a PT zone. PT zones are areal units used in specifying SmartShuttle services: the nomination of a PT zone as a PT locus in a SmartShuttle route implies service at any PT point lying within that zone. Timetabled services are specified as timings for stops, which are collated for planning purposes into time-ordered lists of stops. The variables involved are defined below. tarrr;i tdepr;i deplistp zdeplistz

Latest arrival time for stop i of run r of a PT route. Earliest departure time from stop i of run r of a PT route. List of PT stops at a PT point p, sorted by their departure times. List of SmartShuttle stops in PT zone z, sorted by their departure times.

Service timings are assumed to be conservatively specified; in particular, tarrr;i and tdepr;i represent respectively the earliest departure time and latest arrival time that can be safely used for journey-planning purposes. A SmartShuttle timetable must include some slack time to allow for variable routing (e.g. for multiple hiring or cross-zone travel); thus if locus i of a SmartShuttle route R is a zone, it can be expected that in each run r of R, tdepr;i < tarrr;i . 2.2.3. Specification of demand-responsive services The operation of the demand-responsive modes is constrained by fleet size, vehicle carrying capacities, and the ability of the fleet-scheduling module to optimise fleet deployment. In addition, these modes are subject to quasi-contractual conventions governing the levels of service which travellers may expect. In the case of SmartShuttle, the conventions are embodied in timetables, as outlined above. By contrast, service on free-range modes is subject to standards specified as upper limits on waiting time and on deviations from maximal promptness, as set out below, and with application as explained in the following sections. twmaxm kmaxm

Upper limit on waiting time in a journey-leg planned with mode m. Upper limit on ratio of travel time to fastest travel time by road, for mode m.

3. Planning conventions 3.1. Timing demand-responsive trips A journey-leg carried by a demand-responsive mode is called a trip, and entails special timing considerations. In particular, when attempting to schedule a trip, allowance must be made for the time it takes a vehicle to reach the pickup point, time spent picking up and setting down passengers, and (for multiple-hire travel) slack time to accommodate subsequently-booked trips involving pickup or setdown between the terminal points of the initial trip. These conditions are accommodated by treating the beginning and end of a demand-responsive trip as time-windows within the outer envelope of a journey, instead of the fixed timings applied to ordinary timetabled services. The time-windows serve as constraints applied by the fleet-scheduler; in addition, the end of a setdown time-window for a given trip represents the earliest time from which the journeyplanner can safely extend the journey beyond that trip: thus a trip whose setdown window ends

M.E.T. Horn / Transportation Research Part C 12 (2004) 33–55

39

after the end of the main journey-envelope can be deemed infeasible without reference to the scheduling module. The remainder of this section explains how time-windows are defined for a trip between two points p and q via mode m, given an earliest departure time from p which is determined in practice by the timings of previous legs in a currently-planned journey. The following notation is used. tstartp ttminpq PUminmp PUmaxmp SDmaxmq SDmaxmq

Earliest possible time of departure from p. Minimum possible travel time by road from p to q. Start of time-window for departure from p via mode m. End of time-window for departure from p via mode m. Start of time-window for arrival at q via mode m. End of time-window for arrival at q via mode m.

For a SmartShuttle trip, the time-windows are obtained by reference to the timetable, for the next SmartShuttle service run r leaving p after tstartp , with stops i at p and j at q. It is assumed that the trip occupies the whole of the period between the timetabled departure and arrival times tdepr;i and tarrr;j . Thus for a SmartShuttle mode m, PUminmi ¼ SDminmj ¼ tdepr;i

ð1Þ

PUmaxmi

ð2Þ

¼

SDmaxmj

¼ tarrr;j

For a trip by Taxi or RovingBus, time-windows are obtained from the least possible travel time ttminpq and from the modeÕs service-quality parameters, as indicated below (for the parameters see Section 2.2; in practice allowance is made also for the time taken to pick up and set down passengers at p and q, see Horn, 2002). ð3Þ PUminmp ¼ tstartp PUmaxmp ¼ PUminmp þ twmaxm

ð4Þ

SDminmq ¼ PUmaxmp þ ttminpq

ð5Þ

SDmaxmq ¼ PUmaxmp þ kmaxm  ttminpq

ð6Þ

With travel duration estimated in this way, the main question to be asked of the fleet-scheduling module is ‘‘could a booking be made for trip T without upsetting current scheduling commitments?’’, rather than ‘‘what would be the timing for trip T , given the current deployment and loading of the demand-responsive fleet?’’ This approach establishes a clear demarcation between the planning and fleet-scheduling functions, and by building in slack time it gives the fleetscheduler scope to optimise fleet deployment. 3.2. Estimating costs The generalised cost of a journey is defined as the sum of fares charged directly on each leg, plus traveller-specific components associated with a travellerÕs valuation of his or her own time. For a wait at the origin (or equivalently, at an initial PT pickup point) of duration tt, the traveller-specific cost is tt  wtOwait ; for a wait at an interchange point, the cost is tt  wtIwait . We now consider other cost components, for a leg carried by a mode m between points p and q, using the following notation.

40

M.E.T. Horn / Transportation Research Part C 12 (2004) 33–55

m ttpq zmpq farempq;n

Duration of travel from p to q via mode m. Cost of travel from p to q via mode m. Fare charged for travel by n passengers on mode m from p to q.

For a walked leg pq, the duration is estimated by Euclidean calculation and the travellerÕs walking speed (see Section 2.1); the generalised cost then is: walk ¼ wtwalk  ttpq  npass zwalk pq

ð7Þ

For a leg pq carried by a timetabled mode m, the duration is obtained from the timetable for mode m, and the cost is estimated as: m  npass þ farempq;npass zmpq ¼ wttravel  ttpq

ð8Þ

For a trip taken on a free-range mode m, the service standards prescribe both a maximum waiting m period twmaxm , and a maximum travel time (ttpq ¼ kmaxm  ttminpq , see Section 2.2). These are wait weighted separately, and the weighting factor wt applied to the waiting period is wtOwait if pq is the first vehicular leg of the journey, otherwise wtIwait . The composite cost for the trip is thus defined as follows. m  npass þ farempq;npass zmpq ¼ wtwait  twmaxm  npass þ wttravel  ttpq

ð9Þ

3.3. Journey structure The following notation defines spatial elements that are relevant to a journey between an origin O and destination D. O0 D0 O
D


Any PT point lying within walking time ttmaxwalk of O, known as an O-pickup. Any PT point lying within walking time ttmaxwalk of D, known as a D-setdown. The O-pickup nearest by walking to O. The D-setdown nearest by walking to D.

A journey can be realised as a single leg OD by means of walking or single- or multiple-hire taxi. A multiple-leg journey comprises at least three legs, the outer legs OO0 and D0 D being walked. Static PT modes can be used anywhere in the inner portion(s) of a journey, that is, for O0 D0 or for any legs fO0 p; . . . ; qD0 g, where p; . . . ; q are interchange points. In the present research, SmartShuttle or RovingBus are restricted to the first or last non-walked legs of a journey, so that the main role assigned to these modes is in effect that of a feeder service. It is assumed also that a RovingBus trip always connects with the PT point that is most convenient to the traveller (i.e. from O
in the first vehicular leg, or to D
in the last).

4. The request-broker and journey-planner As indicated in Section 1, the LITRES-2 request-broker module provides a high-level framework for generating and evaluating journey-plans, while the journey-planning module deals

M.E.T. Horn / Transportation Research Part C 12 (2004) 33–55

41

specifically with multi-leg journeys. These modules are described in the next two sections, omitting the details of travel timing and costs that have been explained already. The terminology used here is summarised for reference purposes in Appendix A.1. 4.1. The request-broker For each travel-request received by the system, the LITRES-2 request-broker coordinates the actions of the multi-leg journey-planner (see Section 4.2, below) with those of the demandresponsive fleet-scheduling module, to find the optimal feasible plan P
and its cost Z
. The main tasks here are to obtain the optimal plans ðpsingle ; pmulti Þ for single-legged and multi-legged travel respectively, and to choose the one with the lesser cost, while ensuring the feasibility of the journey if it involves any travel by demand-responsive modes. Procedure request-broker 1. Single-legged journeys. Define initially P
¼ £ and Z
¼ 1. Construct journey-plans involving door to door travel from O to D via walking, TaxiSingle or TaxiMulti, and use the fleet-scheduler to check the feasibility of any plan involving taxi travel. If any feasible single-leg plans are found in this way, let psingle be the one with least cost, and define P
¼ psingle , Z
¼ costðpsingle Þ. 2. Multi-legged journeys. (a) Use the journey-planner to construct (if possible) the optimal journey-plan pmulti with walking and one or more PT legs, such that costðpmulti Þ < Z
. (b) If a pmulti constructed in (a) includes any demand-responsive trips, use the fleet-scheduler to check their feasibility; then if any such trip is infeasible, mark it as unavailable to the current request and repeat (a). (c) If a pmulti was constructed in (a) and all its demand-responsive trips were found to be feasible in (b), define the optimal plan as P
¼ pmulti , Z
¼ costðpmulti Þ. 3. Journey implementation. If the least-cost feasible plan P
(if any) found in the preceding steps includes any demandresponsive trips, confirm bookings for those trips. 4.2. The journey-planner The solution space explored by the journey-planning procedure is envisaged as a tree of possible multi-leg journeys to satisfy a given travel request, extending from the origin O at the root, down to the destination D at each leaf-vertex (see Fig. 1). Associated with each vertex of the tree are an arrival time and the cumulative cost of travel from O. A leaf-vertex represents a complete plan for a journey, while other vertices represent partial plans. A set of vertices reached from O by a given number of journey-legs is called a tier of the search tree. The planning procedure builds and explores the search tree through a breadth-first, implicitlyexhaustive search strategy, which first traces one-legged, then two-legged journeys, and so on. The rationale is that the penalties on interchange (e.g. waiting time, and a minimum fare typically built into PT fare-structures) make it likely that ‘‘good’’ plans, including of course the optimal one,

42

M.E.T. Horn / Transportation Research Part C 12 (2004) 33–55

Fig. 1. Search tree for journey-planner.

have relatively few legs: in that case, breadth-first is likely to establish early on an effective upper bound on generalised cost. The exhaustiveness of the search strategy guarantees that the procedure will find an optimal plan, if any feasible plan exists; in particular, the search tree is combinatorially complete, and the only parts of it that are pruned (i.e. excluded from further search) are those partial plans that cannot lead to a feasible or optimal solution. The procedure is described below, using the following additional notation. k Vk v
z
zv , tv tracev zlop , tlop tdeplimp;v walk ttpq

Tier index, with initially k ¼ 1. k 0 th tier of the search tree. Leaf-vertex of the search tree representing the optimal plan, with initially v
¼ £. Cost (upper bound) associated with v
, with initially z
¼ Z
(see Section 4.1). Cumulative cost and arrival time at a vertex v. Indicates if v is a possible ancestor of the optimal plan, initially tracev ¼ true. Lower bounds on travel cost and duration for travel from p to D. Time-limit on departure of a next leg from a PT point p after a visit v. Duration of walk from point p to point q (see Section 3.2).

Procedure journey-planner 1. Identify points reachable by walking. O-pickup and D-setdown points are found by means of a spatial interpolation and clustering technique. If no O-pickups or no D-setdowns are found, the procedure terminates here. 2. Define lower bounds. Lower bounds ðzlop ; tlop Þ on the cost and time to reach the destination are estimated for each O-pickup and interchange point p (see Section 5.4). 3. Branch for initial timetabled pickups. At each O-pickup point O0 , a visit v is established with its earliest possible arrival time tv defined by the distance from O and the walking speed, and corresponding cost zv . Any possible PT boardings after tv are then found and recorded in V1 , as follows.

M.E.T. Horn / Transportation Research Part C 12 (2004) 33–55

43

(a) Locate tv by binary search in the time-ordered departure list deplistO0 , and establish a branch-limit tdeplimO0 ;v (see Section 5.2). (b) Examine boardings for each stop in deplistO0 , starting with the first departure from O0 no earlier than tv , and finishing with the last departure no later than tdeplimO0 ;v . A boarding on a given service run is added to V1 , provided that the run is currently available (see Section 4.1), and that overlap redundancies are avoided (see Section 5.1). (c) If O0 is the closest to O of the O-pickup points in the SmartShuttle zone z containing O0 , repeat step (b) for zone-based SmartShuttle pickups in zdeplistz . 4. Identify initial RovingBus pickups. For each RovingBus trip from O
to an interchange p0 that is feasible in terms of cost, timing and availability, the possible pickups on timetabled PT services at p0 are recorded immediately in tier V2 (as in step 5b). In addition, if the ‘‘all-RovingBus’’ trip (i.e. O
D
, with a walked leg at each end) is feasible and its cost is less than z
, this termination is recorded as ðz
; v
Þ. 5. Trace legs from current tier. PT runs are traced from the vertices of the current tier Vk , the vertices being traversed in the order in which they were composed (a traversal in increasing order of cumulative cost would allow termination upon reaching a vertex v0 with zv0 P z
, but this appears to yield no net improvement in performance). The following actions are taken for each vertex v in Vk for which tracev ¼ true and zv < z
. Vertex v represents a boarding at a stop s of a PT run r of a route R at a certain point p. Run r is traced forward from s to each subsequent stop of the route (where a stop occurs in a SmartShuttle zone, its location is defined as the PT point in that zone lying nearest to D). The tracing continues until the end of the route is reached, or a visit v0 is reached for which
0 0 tv0 > tDmax  ttDwalk
D or zv0 > z . At each visit v to a point p the following actions are considered. 0 (a) Direct termination of journey. If p is a D-setdown, calculate the total cost walk ; then if zD < z
, record this termination as ðz
; v
Þ. zD ¼ zv0 þ ttpwalk 0 D  wt (b) Branches to next-legs. If p0 is an interchange, it may be possible to transfer from route r to other PT services passing through p0 after tv0 (an adjustment is applied here to tv0 to allow for the time taken to walk through the interchange). Two types of transfer are considered. Firstly, it may be possible to terminate the journey by means of a RovingBus service from p0 to D
, followed by walking to D (as in (a) above). The second type of transfer involves boardings of timetabled services passing through p0 . This is handled in essentially the same way as initial boardings, with a branching-limit tdeplimp0 ;v0 (see step 3a). For each feasible transfer generated here, a new vertex is recorded in Vkþ1 . 6. Proceed to next tier. Set k ¼ k þ 1, then if Vk ¼ £, stop; otherwise repeat step 5.

5. Reduction techniques The following sections describe techniques that restrict the scope of search in the journeyplanning procedure, without compromising the quality of the outcome––that is, without excluding the optimal solution from the search. The techniques are listed in Table 2.

44

M.E.T. Horn / Transportation Research Part C 12 (2004) 33–55

Table 2 Reduction techniques Procedure

Section

Application in journey-planner

self-over others-over departure-limit d
eja-vu getbounds

5.1 5.1 5.2 5.3 5.4

Step 5b Steps 3b, 5b Steps 3a, 5b Step 5b Step 2

5.1. Avoiding route redundancies Although the journey-planning procedure is designed to find the best of all possible configurations of journey-legs, it is clearly unnecessary to examine explicitly every possible such configuration. For example, if a certain sequence of points p1 ; p2 ; p3 . . . of a timetabled route R has been traced with departure-time t from p1 , then no improvement in cost or time could be achieved by tracing the sequence via R with a departure time later than t. A similar situation arises when routes overlap, either in a forward or reverse sense. Described below is the scheme used to avoid redundant searching in such cases. The scheme is robust for linear routes (cyclic routes are discussed in Horn, 1999) and has a very positive impact on system performance when substantial numbers of route-overlaps are present. This is notably the case when advertised routes have variant forms at different times of day, each of which must be recorded as a distinct route for planning purposes. The scheme is based on the following definitions for a pair of routes ðR; R0 Þ operated by the same timetabled mode, under the assumption that vehicles of R and R0 do not overtake each other (if they do, the routes can be assigned to different modes, e.g. Bus and ExpressBus). A concurrency in R and R0 is a sequence of PT loci occurring in both R and R0 . A concurrency C in R and R0 is maximal if R and R0 have no larger concurrency that includes C. A reverse concurrency in R and R0 is a sequence of PT loci occurring in R and R0 in forward and reverse sequence respectively. A reverse concurrency C in R and R0 is maximal if R and R0 have no larger such concurrency that includes C. A forward-overlap of a route R is any route R0 such that R and R0 have a single maximal concurrency C, with the last locus in C the same as the last locus in R0 . A reverse-overlap of a route R is a route R0 such that R and R0 have a single maximal reverse concurrency C, with the first locus in C the same as the first locus in R0 . Two types of overlap-redundancy are relevant in the journey-planning context (see also Appendix A.2). Type 1: a traveller arriving at an interchange via a route R1 has no reason to continue via a forward-overlap or a reverse-overlap of R1 ; consequently branching to any run of such a route is unnecessary. Type 2: where a branch has been made from an O-pickup or interchange point p to a route R1 , a subsequent branch to a forward-overlap of R1 is generally unnecessary; the exception is when p is an O-pickup and wtOwait < wtIwait (see Appendix A.2). As a preliminary to detecting these redundancies, the overlap relationships among all routes are determined in advance of any journey-planning activity (Horn, 1999), and stored in a matrix, of which a member overR;R0 is a ternary variable indicating the relationship of route R0 to route R. Such a variable can have a value of Forward (R0 is a forward-overlap of R), Reverse (R0 is a

M.E.T. Horn / Transportation Research Part C 12 (2004) 33–55

45

reverse-overlap of R), or None (no overlap). We note that if overR;R0 ¼ Forward and overR0 ;R ¼ Forward, R and R0 have exactly the same locus-sequence. Now to detect the first type of redundancy identified above, a simple test is made before initiating a branch at an interchange from a current route R to another route R0 : Procedure self-over If overR;R0 6¼ None, return false (i.e. no branching is required). To detect the second type of redundancy, the following procedure is applied when branching to timetabled services from an O-pickup point (when wtOwait P wtIwait ) or interchange p. A list RFp records forward-overlaps at p, with RFp ¼ £ at the commencement of branching. The procedure determines whether a branch to a run of a route R0 is necessary. Procedure others-over For each route R 2 RFp , if overR;R0 ¼ Forward, return false (i.e. no branch). if overR0 ;R ¼ Forward, replace R0 with R in RFp , and return true. If this traversal reaches the end of RFp , add R0 to RFp and return true. 5.2. Time-limits for branching The journey-planner generates branches representing possible departures on transport services from each O-pickup or interchange point visited in the course of the search. The branches for a visit v to a PT point p are generated in time-increasing sequence, up to a time tdeplimp;v beyond which any further branching would lead only to infeasible or sub-optimal journeys. The calculation of tdeplimp;v for a visit v incorporates the following factors. (a) The cumulative cost of the journey upon reaching p, the cost of waiting at p, a lower bound on the cost of getting from p to the destination D, and the current upper bound on cost z
. (b) The time-limit for arrival at D and a lower bound on the time required to get from p to D. (c) If p is an interchange, the calculation also incorporates a time-limit tdeplimvp;v reflecting the extent of searching carried out in previous visits to p. The branching limit is determined as follows. The calculation of the lower bounds ðzlop ; tlop Þ and of tdeplimvp;v are explained in the following sections. Procedure departure-limit 1. Obtain latest departure with arrival-cost + wait-cost + min-subsequent-cost < z
: t1 ¼ tv þ ðz
 zv  zlop Þ=w; where w ¼ wtOwait if p is to be branched as an O-pickup, or w ¼ wtIwait if p is to be branched as an interchange.

46

M.E.T. Horn / Transportation Research Part C 12 (2004) 33–55

2. Obtain latest departure time to reach D by the end of the journey-envelope: t2 ¼ tDmax  tlop . 3. The effective limit is then the least: If p is an O-pickup: tdeplimp;v ¼ minðt1 ; t2 Þ. If p is an interchange: tdeplimp;v ¼ minðt1 ; t2 ; tdeplimvp;v Þ. 5.3. Avoiding redundant visitation The journey-planning procedure can visit an interchange point more than once; for example, a visit v to an interchange p may be preceded by another visit v0 . In that case it may be unnecessary to trace all the possible branches of the search tree from v, since in handling v0 the procedure has already branched to represent transport services boarded at or after tv0 . For example, if tv0 < tv and zv0 < zv , all services available to v must have been captured in the previous branching from v0 (since tv0 < tv Þ, and the cumulative costs of extending a journey from v via these services can be no less than the costs of the corresponding extensions from v0 (since zv0 < zv ) so that in this case there would be nothing to be gained by branching from v. The d
ej a-vu procedure described below establishes a ‘‘prospective’’ branching time-limit tdeplimvp;v , incorporating the costs and times of all previous visits to p. In the above example, defining tdeplimvp;v < tv will avoid further branching from p after tv . Suppose however that tv0 < tv and zv0 > zv , for example if v0 was reached by a ‘‘premium’’ express mode, and v by a slower service: in this case it would be premature to abandon the investigation of plans derived from the current visit, and we would expect to define tdeplimvp;v > tv . The situation is thus more complex than it would be if the objective were simply to arrive at the destination as soon as possible. The branch-limit is defined in a procedure called d
eja-vu, which also can effect ‘‘retrospective’’ reductions by marking as superfluous ðtracev ¼ falseÞ any previously-generated vertices of the search tree that are dominated by a current visit. These mechanisms yield significant gains in computational performance, although under the breadth-first search strategy they are not guaranteed to suppress all redundant branching associated with previous visits (Horn, 1999). The d
ej a-vu procedure accumulates significant visits to p in a time-ordered list VLp . Each element in VLp comprises fti ; zi ; ei g, of which ti and zi represent the time and cost upon arrival for visit i, while ei records the range of vertices generated from i in the next tier of the search tree. A central task of d
ej a-vu is to compare the current visit with previous visits, the costs of the latter being adjusted for this purpose by means of a function zshiftðv; v0 Þ. The idea is that so far as costs are concerned, the travellerÕs presence at p at time tv could be realised equivalently by waiting for a period tv  tv0 after an earlier visit v0 or (if tv < tv0 ) by waiting after the current visit; thus zshiftðv; v0 Þ ¼ zv0 þ ðtv  tv0 Þ. wtIwait . In Fig. 2 for example, the zshift adjustment is embodied in the lines connecting the visits i; j; k; l comprising VLp : these lines demarcate the upper edge of a region that encompasses the combinations of time and cost for which branching may be required. For a visit at the time marked t in Fig. 2, the branching requirements would depend on the associated cumulative cost z, as follows: z ¼ z1 : Add ðt; zÞ to VLp ; remove entries j and k from VLp ; define tdeplimv ¼ tl . z ¼ z2 : Add ðt; zÞ to VLp ; define tdeplimv ¼ tj . z ¼ z3 : No branching or change to VLp is required.

M.E.T. Horn / Transportation Research Part C 12 (2004) 33–55

47

Fig. 2. Previous visits.

The d
ej a-vu procedure provides a systematic implementation of the branching rules illustrated in Fig. 2. The procedure is outlined below for a visit v to location p, with zshiftðvjÞ, and VLp as defined earlier. Procedure de´ja`-vu 1. Insert the current visit if it is not dominated by its immediate predecessor (a) Find the latest visit vlo (if any) in VLp such that tvlo 6 tv . (b) If vlo 6¼ £ and zshiftðv; vloÞ 6 zv , exit with tdeplimvp;v ¼ tv  1 (i.e. do not branch). (c) Insert v in VLp . 2. Prune any superseded earlier vertices. For each vertex i 2 evlo with tdepi P tv , set tracei ¼ false. 3. Prune any superseded later vertices. (a) Define VL0p as the subset of vertices in VLp that are dominated by v; that is, VL0p ¼ fv0 g : v0 2 VLp , tv0 > tv , zshiftðv; v0 Þ P zv . (b) Define t00 as the time of the earliest visit vhi after VL0p , or t00 ¼ 1 if VL0p ¼ £ or vhi ¼ £. (c) For each visit v0 2 VL0p : Set tracei ¼ false for each vertex i : i 2 ev0 ; then remove v0 from VLp . 4. Exit with branch-limit. Exit with tdeplimvp;v ¼ t00 (see step 4b). 5.4. Estimation of lower bounds The lower bounds ðzlop ; tlop Þ are a priori estimates of the minimum cost and time to get from a point p to the destination D, regardless of the departure time from p. The idea is that further extension of a partial plan from a visit v to p would be futile if zv þ zlop P z
or tv þ tlop > tDmax. This pruning mechanism is evidently safe if the lower bounds are estimated conservatively, that is, if zlop > zlo
p and tlop P tlo
p , where the starred terms refer to the actual minimum possible cost

48

M.E.T. Horn / Transportation Research Part C 12 (2004) 33–55

and time to reach D from p. The estimation procedure described below typically involves tlop substantially greater than tlo
p and zlop substantially greater than zlo
p , and is therefore less effective than it might be in suppressing redundant branching (a stronger method is outlined in Appendix A.3). The following quantities are used. zminwalk p zminttable p zminrbus p

Lower bound on the cost of terminating a journey from a D-setdown p by walking walk ¼ wtwalk  ttpD . to the destination. Defined as zminwalk p Lower bound on the cost of terminating a journey via a timetabled service. Defined as walk ttable ¼ fminttable þ wtwalk  ttD
is the least fare on any timetabled zminttable p p D , where fminp service departing from p. Lower bound on the cost of terminating a journey via a RovingBus service. Defined walk rbus ¼ fminrbus þ wtwalk  ttD
is the least RovingBus fare from as zminrbus p p D , where fminp
p to D .

The lower bounds are then calculated as follows. Procedure getbounds walk 1. In every case, tlop ¼ ttD
D . 2. Initialise zlop ¼ 1; then: Þ: If p is a D-setdown, zlop ¼ minðzlop ; zminwalk p Þ: If any timetabled modes are available, zlop ¼ minðzlop ; zminttable p If any RovingBus modes are available, and p is an interchange or p ¼ O
, zlop ¼ minðzlop ; zminrbus p Þ:

6. Examples from a modelling application The procedures outlined in this paper have been exercised extensively in a recent simulation study of transport options for the Gold Coast, an urban region in Queensland, Australia (Horn, 2002). All the services mentioned in Section 2 were covered, including more than 120 bus, train and SmartShuttle routes. Travel-requests were obtained by applying disaggregation techniques to estimates of total demand for public transport services, the demand estimates being recorded typically as origin-destination matrices (or ‘‘demand models’’, see below) for each hour over a 24-h simulation period. Some examples from the Gold Coast project are given in Figs. 3–5. Each figure shows a travelrequest, followed by summary data for the optimal journey planned for that request, and then legby-leg details of the journey. The travel-request information includes references to the simulation context mentioned above. In summary, a market segment is a set of time-weighting and other parameters, a demand model specifies an aggregate distribution of demand during a given period, and a set of travel-requests is generated by associating a particular market segment with a particular demand model. Thus the attributes of a travel-request include a market segment (‘‘segment’’) and a demand model (‘‘dm’’), in addition to an origin and a destination point, a journey-envelope, and so on.

M.E.T. Horn / Transportation Research Part C 12 (2004) 33–55

Fig. 3. Journey-plan example with one taxi leg.

Fig. 4. Journey-planning example with one bus leg.

Fig. 5. Journey-planning example with two vehicular legs.

49

50

M.E.T. Horn / Transportation Research Part C 12 (2004) 33–55

Another travel-request detail is the time of issue. The amount of advance notice between this time and the commencement of the journey-envelope obviously affects the prospects of obtaining a suitable booking on a demand-responsive service. The costs for a journey and for each leg are reported as fares and as imputed user-costs (‘‘u-wait’’, ‘‘u-walk’’, etc.). For each leg carried by a demand-responsive service, the information shown includes the vehicle initially assigned to the leg by the fleet-scheduler, with a prefix indicating the fleet to which the vehicle belongs (e.g. ‘‘v1.4’’ of mode ‘‘f1.TaxiSingle’’ in Fig. 3). The reporting of walked legs embodies an assumption that a traveller will prefer to wait at the origin of a journey, rather than at the first boarding point (e.g. see the timing of the first walk in Fig. 4). In the scenarios studied for the Gold Coast project, the LITRES-2 system typically processed approximately 40,000 mixed-mode travel-requests in about 20 min of CPU time. It appears then that with the same hardware (a 200 MHz Sun Ultra workstation), and for similar transport infrastructure, the procedures described in this paper could handle a maximum real-time load in the order of 120,000 travel-requests per hour. A detailed study of the operation of the journeyplanning procedure generally confirmed the value of the strategies applied in the procedures and of the bounding techniques used. The number of search-tree vertices visited by the journeyplanner was on average less than 50, these vertices being heavily concentrated in the early tiers. Although no limit was set on the depth of the tree, the depth of search in practice never exceeded five tiers. In addition, the optimal plans generated were plausible; for example, the majority had one vehicular leg, and few had more than two.

7. Conclusions The planning procedures described in this paper are apparently unique in their coverage of both static and dynamic public transport services, and in their handling of inter-dependencies between temporal conditions and a planning criterion of generalised cost. Given the range of conditions with which they can deal, and their robustness in handling those conditions in scenarios tested so far, they appear to be well-suited for use within a real-time traveller information system. Any practical application will involve a variety of extensions and adaptations to local needs. In the first place, the implementation of a public transport information system of the kind discussed in the Introduction to this paper will raise substantial practical and commercial challenges, notably in the construction of the communications infrastructure and in establishing reliable electronic booking mechanisms. Secondly, a PTIS will require an effective user interface, with special attention to techniques for gathering request details and for displaying planning outcomes: the address-matching and map-display capabilities of a Geographic Information System are likely to be pertinent in these respects. Thirdly, when the journey-planning procedures are used in a realtime context, it will be desirable that they should have access to current locations and passenger loadings of vehicles operated both in fixed-route and demand-responsive modes. In addition, the framework of constraints and costs addressed in this paper could be elaborated in several ways. Alternative fare structures (e.g. with inter-modal transfer concessions) could be accommodated without difficulty, provided that the total fare for any given ride or sequence of rides does not decrease with increasing distance. The planning procedures could be adapted to

M.E.T. Horn / Transportation Research Part C 12 (2004) 33–55

51

include user-preference criteria of the kinds discussed by Li and Kurt (2000). It may be desirable also to adopt less restrictive conventions regarding the use of demand-responsive services (see Section 3.3). A further and more difficult challenge concerns the needs of a ‘‘deadline-seeker’’, that is, a traveller who aims for a low-cost journey arriving at the destination as close as possible to the end of the journey-envelope tDmax. This goes beyond the problem formulation discussed in the present paper; for example, setting wtOwait ¼ 0 will permit extended waiting at the origin, but cannot guarantee an optimal deadline-seeking arrival. To accommodate the deadline-seeking case, a new parameter wtDwait could be introduced to indicate the cost to the traveller of ‘‘waiting’’ at the destination, this cost being implicitly zero under the present formulation. Extensions of this kind, including provision for non-linear cost functions have been studied recently by the present author (Horn, 2003).

Appendix A A.1. Terminology Table 3 summarises the variables used in the descriptions of the request-broker and journeyplanner procedures, and indicates the parts of the paper where the variables are referred to.

A.2. Route-overlap redundancies This Appendix defends the assertions about route-overlaps made in Section 5.1. The redundancy types defined there are illustrated in Fig. 6. Cases 1a and 1b are concerned with possible transfers to another route after arrival at an interchange p via a run of a route R0 . In case 1a, a rational traveller would not break her journey at p to continue via a forward-overlap of R0 (e.g. via any run of Rþ or of R0 itself): such a continuation could not lead to any point other than points already accessible from p via R0 , and could involve an unnecessary time-delay, waiting cost and fare increment at p. In case 1b, transfer at p to a reverse-overlap of R0 such as R would involve the same overheads as those in case la. As to the combinatorial possibilities, the journey-leg terminated at p must have commenced at an O-pickup or interchange o on R0 : thus transferring to R at p could lead only to (a) points between p and o already traversed on R0 , or (b) points upstream of o on R0 that are accessible via R from o without the detour o ! p ! o. But the combinatorial scheme has already covered all possible branchings from o and from stops between o and p, at lower cost than could be achieved via p; therefore branching to the reverse-overlap route R could not improve upon these branchings. Case 2 is concerned with branching from a visit to a O-pickup or interchange point p, where p has been reached by walking from the origin or via any PT service. If a branch is made at p to any route R1 , a subsequent branch to a forward-overlap R2 of R1 cannot lead to any PT point not already accessible via R1 . Furthermore, because branching involves a chronological sequence of pickups, a branch via R2 must involve an additional waiting time compared with an earlier branch

52

M.E.T. Horn / Transportation Research Part C 12 (2004) 33–55

Table 3 Variables used in planning procedures Variable


P pmulti psingle D D0 D
deplistp kmaxm npass O O0 O
over RFp tarrr;i tdeplimp;v tdeplimvp;v tdepr;i tDmax tlop tOmin tracev ttmaxwalk walk ttpq tv twmaxm v
Vk VLp wtIwait wtOwait wttravel wtwalk z
zshiftðv; iÞ Z
zdeplistz zlop zv

Section

Definition

4.1 4.1 4.1 2.1 3.3 3.3 2.2 2.2 2.1 2.1 3.3 3.3 5.1 5.1 2.2 4.2, 5.2 5.2, 5.3 2.2 2.1 4.2, 5.4 2.1 4.2, 5.3 2.1,2.2 4.2 4.2 2.2 4.2 4.2 5.3 2.1 2.1 2.1 2.1 4.2 5.3 4.1 2.2 4.2, 5.4 4.2

Optimal plan, in request-broker Optimal multiple-leg plan, in request-broker (see also v
) Optimal single-leg plan (taxi or walk), in request-broker Destination point for a journey, specified in a travel-request A D-setdown: a PT point within walking time ttmaxwalk of D The D-setdown (see D0 ) nearest by walking to D PT stops at a PT point p, sorted by departure-times Limit on travel time as ratio of shortest time, for free-range mode m Size of travelling group, specified in a travel-request Origin point for a journey, specified in a travel-request An O-pickup: a PT point within walking time ttmaxwalk of O The O-pickup (see O0 ) nearest by walking to O Table of route-overlaps List of forward-overlap routes at an O-pickup or interchange point p Timetabled arrival time for stop i of run r of a PT route Time-limit on departure of a next leg from p after a visit v Time-limit on departure from p after visit v, based on previous visits Timetabled departure time for stop i of run r of a PT route Latest time to arrive at D, specified in a travel-request Lower bound on travel time from point p to D, in journey-planner Earliest time to depart from O, specified in a travel-request Indicates if vertex v is a possible ancestor of the optimal plan TravellerÕs upper limit on walking time in any one journey-leg Duration of walk from point p to point q Arrival time at vertex v, in journey-planner Limit on waiting time in a leg planned with free-range mode m The least-cost plan found so far by the journey-planner k 0 th tier of the journey-planner search tree List of dominant visits to a point p TravellerÕs cost-weighting for time waiting at interchanges TravellerÕs cost-weighting for time waiting at the origin TravellerÕs cost-weighting for time travelling TravellerÕs cost-weighting for time walking Cost of optimal plan v
, in journey-planner Cost-increment to compare visit i with another visit v at same place Cost of optimal plan P
, in request-broker SmartShuttle stops in a PT zone z, sorted by departure-times Lower bound on cost for travel from point p to D, in journey-planner Cumulative cost at vertex v, in journey-planner

via R1 ; consequently the cost of a journey-plan obtained by branching via R2 generally can be no less than the least cost obtainable via R1 . An exception occurs when p is an O-pickup and wtOwait < wtIwait , in which case the traveller would find it preferable to incur waiting cost at an Opickup (or O) rather than at a subsequent interchange q, as shown in Fig. 7.

M.E.T. Horn / Transportation Research Part C 12 (2004) 33–55

53

Fig. 6. Route redundancies.

Fig. 7. Waiting cost reduced by delayed branch from O-pickup.

A.3. Strong bounding scheme This Appendix outlines an alternative method to estimate lower bounds ðzlop ; tlop Þ for the journey-planning procedure (see also Horn, 1999). The scheme is superior in principle to that described in Section 5.4 above in that it obtains more effective values of ðzlop ; tlop Þ; that is, these values are smaller, but still no less than the actual values ðzlo
p ; tlo
p Þ. The possible ways of undertaking a journey are represented in a network form, as illustrated in Fig. 8, and the lower bounds for a given point p are determined by finding the least-cost and least-time paths from p to D. These tasks are addressed through a simple inversion of DjikstraÕs label-setting algorithm (Dijkstra, 1959), fanning out ‘‘backwards’’ from D instead of ‘‘forward’’ from O. The alternative bounds-calculation procedure is described below in a simplified account which omits mention of demand-responsive services. The procedure uses a bipartite scheme to relegate as much work as possible to a preparatory step, thus avoiding unnecessary repetition of calculations involving conditions common to all travel-requests.

54

M.E.T. Horn / Transportation Research Part C 12 (2004) 33–55

Fig. 8. Network representation for strong lower bounds.

Procedure getbounds-strong 1. The first step precedes any journey-planning activity. The task here is to set up a maximal network structure, covering all possible timetabled PT legs during the period when planning is to take place; that is, for any pair of PT points ði; jÞ, a link ij is recorded if there is at least one PT route comprising points f. . . i; . . . ; j . . .g For each such link, the minimum fare and time are obtained by examining all services traversing the link during the period when travel is to take place (typically 24 h). 2. The second step is applied to each travel-request, as part of the journey-planning procedure (see Section 4.2, step 2). (a) From the maximal set established in step 1, a selection is made of network components relevant to the current journey-planning problem: O-pickups, D-setdowns, interchanges, and links between them. These are configured with the origin and destination points and walkable legs, as illustrated in Fig. 8. (b) The inverted Dijkstra procedure is used to trace all shortest-time paths to D, subject to an upper limit ttmax on elapsed time ðttmax ¼ tDmax  tOminÞ. The procedure labels each visited point p with the estimated path duration tlop . Then if the ttmax constraint prevents the procedure from reaching the origin O, the request is clearly infeasible. (c) The inverted Dijkstra procedure is applied again, this time to trace all minimum-cost paths to D, subject to the upper bound on cost z
. Here the link-costs are obtained by the addition of fares (from step 1) and the travellerÕs time-weightings. Upon completion, every relevant point is labelled with zlop . Again, if O is unreached, the request is infeasible. Tests with the data mentioned in Section 6 have shown that the bounds obtained with getbounds-strong are very effective in restricting the scope of search in the journey-planning procedure. However the time required for path-tracing typically overshadows this combinatorial advantage, to such an extent that overall performance is about 50% slower than with the weaker bounds outlined in Section 5.4. A remedy to this performance problem might be obtained through

M.E.T. Horn / Transportation Research Part C 12 (2004) 33–55

55

attention to the Dijkstra priority queue (currently implemented as a heap, see Cormen et al., 1990, chapter 7).

References Abdel-Aty, M.A., 1999. A simplified approach for developing a multi-modal travel planner. ITS Journal 5, 195–215. Bander, J., White, C., 1991. A new route optimization algorithm for rapid decision support. In: Proceedings of VNIS Õ91 (Vehicle Navigation and Information Systems Conference), Society of Automotive Engineers, part 2, pp. 709–728. BT, 1999. Available from . Chen, C., Chen, J., Kitamura, R., 1999. Multimodal daily itinerary planner: interactive programming approach. Transportation Research Record (1676), 37–43. Cormen, T.H., Leiserson, C.E., Rivest, R.L., 1990. Introduction to algorithms. MIT Press, Cambridge, MA. Desrochers, M., Soumis, F., 1988. A generalized permanent labelling algorithm for the shortest path problem with time windows. INFOR 26 (3), 191–212. Dial, R.B., 1967. Transit pathfinder algorithm. Highway Research Record 205, 67-85. National Research Council (USA), Highway Research Board. di Febbraro, A., Sacone, S., 1997, On-line information services in urban integrated transportation networks. In: Proceedings, IEEE Conference on Intelligent Transportation Systems, Boston. Dijkstra, E.W., 1959. A note on two problems in connection with graphs. Numerische Mathematik 1, 269–271. Engels, D., 1994. Integration of demand responsive services in a vehicle scheduling control system. In: Proceedings of the First World Congress on Applications of Transport Telematics and Intelligent Vehicle-Highway Systems, Paris, v6, pp. 2864–2871. Han, A., Hwang, C.-H., 1992. Efficient search algorithms for route information services of direct and connecting transit trips. Transportation Research Record (1358), 1–5. Horn, M.E.T., 1999. Planning multi-leg urban journeys with fixed-schedule and demand-responsive public transport services. CSIRO Mathematical and Information Sciences Technical Report 99/62. Horn, M.E.T., 2002. Multi-modal and demand-responsive passenger transport systems: a modelling framework with embedded control systems. Transportation Research A 36 (2), 167–188. Horn, M.E.T., 2003. An extended model and procedural framework for planning multi-modal passenger journeys. Transportation Research B 37 (7), 641–660. Infopolis, 1999. Available from . ITN, 1999. Available from . Koncz, N., Greenfield, J., Mouskos, K., 1996. A strategy for solving static multiple-optimal-path transit network problems. Journal of Transportation Engineering 122 (3), 218–225. Li, Q., Kurt, C.E., 2000. GIS-based itinerary planning system for multimodal and fixed-route transit network. In: Proceedings of the Mid-Continent Transportation Symposium 2000, Iowa State University. Available from . London, 1999. Available from . Mehaffey, A., Lowe, D.J., 1997. Trials of a real-time bus information system. In: Proceedings of the Third International Conference of ITS Australia, Brisbane. Solomon, M., Desrosiers, J., 1988. Survey paper: time window constrainted routing and scheduling problems. Transportation Science 22 (1), 1–13. Tong, C.O., Richardson, A.J., 1984. A computer model for finding the time-dependent minimum path in a transit system with fixed schedules. Journal of Advanced Transportation v18.2, 145–161. TransPerth, 1999. Available from . Ventura, 1999. Available from .