O-D estimation

I found a paper on O-D estimation called:

'Statistical inference for time-varying origin-destination matrices'

by Martin Hazelton, which is currently in press in Transportation Research Part B. The paper investigates the estimation method of "day-to-day" OD matrix using link count data (different Kwon and Varaiya's approach which used 'fastrak tagging data'). The O-D matrix is parameterized and determined using a Bayesian appraoch. The core idea of their underlying Bayesian appraoch is quite similar to the 'matching alogrithm' (the 'f' and 'g' things ..) that Pravin presented last Friday.

Although we are more interested in 'within-day' O-D, it may still be useful to see what we may learn from their work.

You can download the paper from the journal website or I can send you a copy if you are interested.

Aurora RNM - trip assignment

Hi all,

I have spent some time studying implementing trip assignment module to Aurora. I have also studied the current software architecture of Aurora for this purpose. I have summarized some notes, including the modifications (see Part C) that I would suggest to do.

Please comment and let me know if there is anything you would like me to elaborate...

I will also upload some numerical calculations to the Aurora Blog later ...

A. Use of trip assignment in Aurora:

1. Interaction between travel demand and traffic condition

-E.g. choice between freeway and arterial

- No congestion -> everyone goes for freeway

- Freeway congested -> Someone may choose to take arterial

- Question: what is the proportion of flow on freeway/arterial?

- Some numerical calculations will be given later …

2. Estimate demand changes with respect to control policies (e.g. ramp metering, toll, traffic information provision etc..)

B. Assignment principles (travel demand model):

1. ‘ad-hoc’

- e.g. assign traffic to the shortest path at the current time interval

2. Deterministic user equilibrium (DUE)

- Ideal (actual)

- Instantaneous

3. Stochastic user equilibrium (SUE)

4. Stochastic ‘learning’ process / Dynamic game

- Evolution of drivers’ behavior as a result of ‘learning’

- system gradually would converge to some steady state (a Nash equilibrium) if there is no ‘disruption’ to the system …

Methods 1, 2, and 3 have been studied and used in the literature.

Personally I would buy Method 4. It seems to be more ‘statistically’ oriented. PeMS should be useful for calibrating or validating this.

C. Things need to be added to current Aurora RNM:

1. Split ratio profile over time

- the split ratios also supposed to be ‘state-dependent’

2. Data storage for

- flow on different paths;

- flow heading to different destination;

- different kind of vehicles (e.g. HOV vs LOV; Trucks vs autos).

3. Path travel time calculation

The path travel time in Aurora is currently calculated in an ‘instantaneous’ fashion: In other words, it is assumed that the travel time along the whole path does not vary after the driver enters the path. This doesn’t seem to be realistic ..

TransModeler

Hi all,

TransModeler is a network simulation and operation tool equipped with GIS interface. TransModeler's a very impressive software package overall and it covers almost everything. I try to make a summary based on my understanding:

1. It can simulate a netork with different degrees of fidelity: microscopic, mesoscopic, and macroscopic:

a. Microscopic model captures the movements of each individual vehicle using kinematics (like the one in Paramics) ;

b. Mesocopic model uses speed-density relationship to describe the traffic state (like DynaSmart which we discussed before);

c. Marcoscopic model adopts the volume-delay relationship (like the one in the so-called 'static' model).


2. TransModel can be used for:

a. Intersection control (including pretimed, actuated, and actuated coordination. For the actuated controller, I believe that they are using a 'microcopic' appraoch (similar to Paramics) with detectors defined on the network);

b. Freeway traffic management (the design and simulation of HOV and HOT lane. TransModeler can also simualte the 'lane-changing effect);

c. Traffic demand analysis (O-D estimation, static and dynamic traffic assignments. The traffic assignments can be calculated according to different principles: shortest path assignment, stochastic shortest path assignment; user equilibrium assignment, stochastic user equilibrium assignment based on multinomial logic discrete choice model);

d. Transit simulation.


3. The software, of course, is equipped with easy-to-use GUI.

I wish the information will be useful to our future discussion and development.

Dynamic traffic assignment

Hi Alex,

I have started building an assignment solver for Aurora RNM. At this preliminary stage, I constructed a simple network with two parallel links (as attached in the email):

Link 1001: origin link
Link 1002: one of the parallel links connecting nodes 1 and 2
Link 1003: one of the parallel links connecting nodes 1 and 2
Link 1004: destination link

The demand profile can be seen in the xml file.

The network is uncongested, which can be verified by seeing no delay on any link in it after simulation. I have the following problems:

1. Since the network is uncongested, I don't understand why the inflow to link 1002 from the origin link 1001 is distorted.

2. How can I split some flow from the origin to route 2 (i.e. via Link 1003). Currently all the flow from the origin is flowing on route 1 (i.e. Link 1002).

Please advise. Please let me know if you want more information from me.

Andy

P.S. For other people, please let me know if you want to have the config file of the 2-link network that we discussed above...

TOD signal plan - Lomita network

Hi all,

I have updated the Lomita network config file (lomita_network.xml) for the Time-of-Day (TOD) signal controller. The file was put in the "config" folder. What I have done includes:

1. The simulation horizon was extended to 24 hours;

2. There are three timing plans used in the network, which are scheduled as follows:
00:00 - 06:00: Plan 1
06:00 - 10:00: Plan 2
10:00 - 16:00: Plan 3
16:00 - 20:00: Plan 2
20:00 - 24:00: Plan 1

The timing plan is set based on real signal data. Please let me know if you want to have the details of the timing plan.


3. The demand profile is
00:00 - 03:00: 0 vph
03:00 - 04:00: 100 vph
04:00 - 05:00: 200 vph
05:00 - 06:00: 250 vph
06:00 - 07:00: 500 vph
07:00 - 08:00: 1000 vph
08:00 - 10:00: 500 vph
10:00 - 12:00: 250 vph
12:00 - 15:00: 200 vph
15:00 - 16:00: 500 vph
16:00 - 17:00: 1000 vph
17:00 - 18:00: 500 vph
18:00 - 20:00: 200 vph
20:00 - 21:00: 100 vph
21:00 - 24:00: 0 vph

Please feel free to try and comment.

Aurora RNM - Actuated signal controller

Andy's proposed actuated signal controller:
http://path.berkeley.edu/topl/docs.html


Gabriel's comment:

On the detector model, I dont think that headway = 1/flow is the right macroscopic variable for generating stochastic vehicle actuations. This is because a small flow could generate large headways, in freeflow, or small headways in congestion. It is argued in the attached note that the"smeared occupancy" lambda is what we want.

See http://path.berkeley.edu/topl/docs.html for Gabriel's detector model.


Andy's comment on Gabriel's idea:

1. I am still trying to understand 'lamda'. One quick observation is that the 'dimension' doesn't match: 'lamda' is dimensionless, while it is supposed to be the expect number of vehicles (instead of occupancy).

2. When it's congested and there are a lot of vehicles on the road, you will get a small spacing between successive vehicles since spacing is the reciprocal of density (Equation 2 in my note).

However, it appears to me that it doesn't necessarily imply you are going to have frequent actuations by detectors installed on the road.

It is because the headway of vehicles (and hence actuations) is going to be pretty long as well since the vehicles are moving slowly (speed is low in congested state..) and it takes longer time for them to reach the detector..

Next Phase of Aurora Development

The Aurora research and development in the next phase of TOPL will address the following issues.

1. Support for complex link state.
Currently the state of the link is defined by the vehicle density, it is a scalar value. We would like to define the state as a vector of densities marked by vehicle types. The types of vehicles may be HOV-enabled, trucks, or ordinary vehicles. Vector-state will also allow us to approach the DTA problem, as in the DTA setting vehicles are characterized by the OD pairs.

2. Analysis module of Aurora.
Properly organized database that stores the simulation results is a key factor in the effective performance analysis of road networks. This module may include

• actual travel time computation for the specified routes;
• bottleneck identification;
• analysis of stochastic demands and capacities.
  

3. New control algorithms for the ramps and arterials.
These include

• system-wide ramp metering algorithms such as SWARM 1;
• signal control with adaptive rate and coordinated signals on arterials; and
• coordinated arterial signals and ramp metering.
  

4. Road network configuration management.
Proper organization and maintenance of configuration files will separate the network geometry from the event scenarios and demand profiles. This will allow to keep rarely updated and frequently updated configuration portions apart. The other goal is to simplify the process of building complex networks using the existing configuration files for their sub-networks.