Using Cube for Public
Transport Planning
An Overview
Andreas Köglmaier
Regional Director
Content
 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
Reasons for building a public transport model





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
Public transport data availability
 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)
Representing the public transport system
 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
Rail
Rail Platform
WalkTime = ~1 min
Streets
Bus stop node
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
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
Transit line
System data
Representing the passenger behaviour
 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
AUTO
TRANSIT
DRIVE
ALONE
SHARED
RIDE
SHARED
RIDE 2
SHARED
RIDE 2+
WALK
BUS
LIGHT RAIL
DRIVE
COMMUTER
RAIL
CIRCULATOR
BUS
LIGHT RAIL
COMMUTER
RAIL
CIRCULATOR`
Representing the passenger behaviour
Representing the passenger behaviour
Home
Rail Platform
Transfer
Bus Stop
Transit path
Auto path
Toll
Parking
Work
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 Enumeration
Enumeration 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 Evaluation
Evaluation ‘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
Report and Visualize PT Results & Inputs
 Reports
 Graphics
 Record Processing
Fare System Representation
All 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
Representing Park and Ride





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
Rail
Rail Station
Bus Stop
Escalator link
PNR lot–stop access
connector
PNR Lot
Rail Platform
Buses
Streets
Driveway link
18
Representing crowding
 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
4. Exemplos internacionais de utilização do CUBE – Europa
Multimodal model Spain
Passengers: Cars, Railways, Airplanes
Freights: Highways and Railways
De Lijn Public Transport Model (North Belgium)
4. Exemplos internacionais de utilização do CUBE – Europa
Master Plan Budapest, Hungary
Multimodal Model Lisboa, Portugal
13
25
18
42
17
24
16 15
14
72
1
76
75
71
52
73
74
64
55
63
56
53
68
97
69
60
70
65
80
54
58
62
66
59
57
67
61
83
79
85
86
4. Exemplos internacionais de utilização do CUBE – Ásia
Calcutta Light Rail Model Calcutta, India
4. Exemplos internacionais de utilização do CUBE – Ásia
Thailand Multimodal Model
Urban Master
Modelos
urbanosPlans
• Bangkok
• Khisanulok
Multimodal Model Hong Kong
Transport Model Beijing, China
Multimodal Model Jakarta
Airport
Toll Road
Urban Toll
Road
JakartaTangerang
Toll Road
JORR E1
(part) Toll
Road
Cawang IC
JakartaCikampek
Toll Road
Serpong
Toll Road
JORR S
Toll Road
Jagorawi
Toll Road
Multimodal Model Hanoi, Vietnam
Multimodal Model - Melbourne
Highspeed Rail model, California USA
Thoughts on ideal modelling program
 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.
32
Thank you!
Andreas Köglmaier
Regional Director
akoeglmaier@citilabs.com