using cube for public transport planning an overview andreas köglmaier regional director
TRANSCRIPT
Using Cube for Public Transport Planning
An Overview
Andreas KöglmaierRegional Director
Reasons for modelling public transport
Public transport data availability Considerations regarding network
representation Representing passenger behaviour
(mode choice and route choice) Public transport model development
in Cube Specific considerations (fare, park
and ride, crowding) Examples of Cube public transport
models
Content
Forecast public transport demand and revenue Analyse PT projects (economic analysis) Optimise the routing of PT lines Testing different ticket systems Revenue allocation for integrated ticket systems with multi
operators Estimate future run times
Reasons for building a public transport model
System data (Supply)• Network data (line routing, stopping pattern, timetable)• Observed vehicle speeds (delays)• Reliability (delays, cancelations, accessibility of vehicle) • Quality of vehicles and station infrastructure (comfort)• Ticket and tariff System
Public transport data availability
Passenger data (Demand)• Boarder and alighter information• Vehicle loadings (crowding information)• Passenger origin and destination information• Demographic Information (age group, car ownership, …)• Usage of different ticket types• Mode choice and route choice behaviour (stated and revealed
preference surveys)
Public transport data availability
WalkTime = ~1 min
Streets Bus stop node
Rail Platform Rail
Physical infrastructure (roads, tracks, stations)• Stick network or shape network• Station single node or detailed modelling of interchanges• Speeds taken from network or from service definition
Representing the public transport system
Service definition and routing• Decision on which services to include (special school runs)• Consider simplification of network• Coding of services as one or two way lines (one way streets)
Organisation of the system (operators, modes, fares)• Understand which parameters influence route and mode choice• Level of representation depends on set up of demand model
Representing the public transport system
Cube represents complexity of PT Systems The route, where it stops (boarding and alighting:
both, only boarding, only alighting), and its variations (sub-routes) by period of the day. Details such as boarding delays at selected stops..
The type of vehicle providing the service (bus, light rail, heavy rail, ferry…etc.) and its capacity (seated and crush). (capacity restraint is provided in PT)
Information about multiple PT operators and their operating/fare policies
Full representation of circular routes Uses function of roadway speed, set travel times via
time points, used fixed time.
Highway network
System data
Transit line
Understanding route and mode choice behaviour• Choosing between bus and rail (mode or route choice?)
Considerations for mode choice model• Group passengers in homogenous groups with similar route
choice behaviour• Consider ticket choice model
Considerations for route choice• Value of different trip components
Representing the passenger behaviour
AUTO
DRIVE ALONE
SHARED RIDE
SHARED RIDE 2
SHARED RIDE 2+
TRANSIT
WALK
BUS LIGHT RAILCOMMUTER
RAILCIRCULATO
R
DRIVE
BUS LIGHT RAILCOMMUTER
RAILCIRCULATO
R`
Representing the passenger behaviour
Home
WorkTollParking
TransferBus Stop
Rail Platform
Transit path
Auto path
Representing the passenger behaviour
PT Methodology
Compiles Data and Simplifies Network (Produces NET file)
Enumerates “Acceptable” Discrete Routes for every O-D (RTE file)• Finds least cost route• Enumerates all other routes within defined limits
Evaluates Routes and Performs Analysis:• Decisions on access and assignment to individual lines through a
series of logit choice models.• Route evaluation through a hierarchical logit choice model.
Route EnumerationEnumeration finds a traveler's reasonable public transport routes from origin to destination Identifies full discrete routes
• The route should move progressively from the origin to the destination
• Travelers tend to select journeys that are simpler – that are direct or involve few interchanges
• Travelers are unwilling to walk very long distances These principals are used to constrain the potentially huge
computational task of identifying all reasonable routes The process can be considered analogous to a traveler using a
map to reject routes which are very long relative to more direct alternatives
Creates a dataset of the ‘reasonable’ routes between each origin and destination by user class
Route EvaluationEvaluation ‘qualitatively judges’ the routes calculated in the route enumeration stage of PT The elements that can be used in this process
• Limit on the number of transfers• The difference (actual & percentage) difference
between the minimum cost route and the evaluated route
• Limit on non-transit cost (walk/drive access)• Limit on waiting and transfer times• Limit on In-vehicle costs
Specified by user class – or – market segment Provides attractive and reasonable routes along with
their probability of being used and the costs of each of the routes.
Calculates the % probability of using each path using choice models at each decision point
Reports Graphics Record Processing
Report and Visualize PT Results & Inputs
Fare System RepresentationAll sorts of complex fare systems can be
modeled by user class
FREE – No cost incurred FLAT – One fixed cost per use DISTANCE – Possible boarding cost + unit cost
per distance or cost lookup table FROMTO –Fare zone matrix based on the
start/end zones COUNT –Counts number of fare zones crossed,
sum number of zones crossed ACCUMULATE – Each fare zone has a fare and
when crossed adds to cost
Input Car & PT cost matrices Define Catchment Area, City zone & Station zone Calculate Car cost: Catchment to Station & opposite Calculate PT cost: Station to City & opposite Combine to calculate Catchment to City via station cost &
opposite Consider cost penalty for parking time. Where there is more than one station in a catchment, the
process is repeated for each station to determine the station with the minimum cost for each zone in the catchment.
Output a Park and Ride cost matrix
Representing Park and Ride
18
Representing Park and Ride
PNR lot–stop access connector
Driveway link
Escalator link
Buses
Streets
Rail Station Rail
Bus Stop
PNR Lot
Rail Platform
Vehicle capacity required as input Understand changes in comfort
• Seating capacity and crush capacity• Define crowding curve
Penalties• In-vehicle penalty• Boarding penalty
Iterative process: Loaded demand from an iteration is used to update the following for the next iteration• Link travel times • The probability of boarding a line at a particular stop
Representing crowding
4. Exemplos internacionais de utilização do CUBE – Europa
Passengers: Cars, Railways, Airplanes
Freights: Highways and Railways
Multimodal model Spain
De Lijn Public Transport Model (North Belgium)
4. Exemplos internacionais de utilização do CUBE – Europa
Master Plan Budapest, Hungary
Multimodal Model Lisboa, Portugal
1
13
1415161718
2425
42
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
6869
70
71
72
73 74
7576
79
80
83
85
86
97
4. Exemplos internacionais de utilização do CUBE – Ásia
Calcutta Light Rail Model Calcutta, India
4. Exemplos internacionais de utilização do CUBE – Ásia
Modelos urbanosUrban Master Plans
• Bangkok• Khisanulok
Thailand Multimodal Model
Multimodal Model Hong Kong
Transport Model Beijing, China
Multimodal Model Jakarta
Jakarta-CikampekToll Road
JagorawiToll Road
JORR S Toll Road
SerpongToll Road
Jakarta-TangerangToll Road
Airport Toll Road
Cawang IC
Urban Toll Road
JORR E1 (part) Toll Road
Jakarta-CikampekToll Road
JagorawiToll Road
JORR S Toll Road
SerpongToll Road
Jakarta-TangerangToll Road
Airport Toll Road
Cawang IC
Urban Toll Road
Jakarta-CikampekToll Road
JagorawiToll Road
JORR S Toll Road
SerpongToll Road
Jakarta-TangerangToll Road
Airport Toll Road
Cawang IC
Urban Toll Road
JORR E1 (part) Toll Road
Multimodal Model Hanoi, Vietnam
Multimodal Model - Melbourne
Highspeed Rail model, California USA
32
Four inter-related elements…▪ Data collection program▪ Model design/structure▪ Validation/testing procedures▪ Training
…where each element is developed with the other three elements in mind▪ Data collection program captures sufficient information for
validation/testing▪ Validation/testing procedures correspond with the model
design/structure▪ Training is sufficient to allow for proper execution or maintenance
of the model design/structure▪ Etc.
Thoughts on ideal modelling program
