The additional options auto assignment, introduced in Release 3.0, has proven itself to be a very powerful tool. During this past year, it has helped to solve many special situations which, at first sight, seemed impossible to solve with an off-the-shell software.

When looking at these and other potential applications for the additional options, it become clear that, in its initial implementation, there was one type of problem which could not be handled. Since all selection decisions are taken at the level of an entire path, the resulting origin-destination matrix is always based on the OD-pairs as they appear in the original assignment. Thus, it is not possible to use this approach to alter the structure of the OD relations.

Consider the example of extracting a subarea out of a regional network. Figure 1 shows the auto volumes in the regional network for a window which contains the subarea.

**Figure 1:** Figure 1: Total auto volumes inside and outside subarea

With the additional options assignment of Release 3.0 it is possible to extract only those trips of the regional trip matrix which actually pass through the considered subarea. However, the so selected trips are still based on the origins and destinations of the regional network, i.e. the corresponding volumes still span the entire regional network in order to connect to the regional zones. Figure 2 shows the volumes resulting only from those trips which pass through the subarea.

**Figure 2:** Figure 2: Volumes generated by trips passing through subarea

It would now be of great interest to compute a new trip matrix with new origin and destination zones at the border of the subarea, which would replace all the zones of the regional network that are outside of the study area, such as shown in Figure 3.

The step leading to Figure 3 changes the structure of the trip matrix, i.e. involves changes to the trip ends. Hence, it cannot be implemented with the additional options of Release 3.0.

In Release 4.0, the additional options auto assignment has been extended in order to also provide a solution to this type of problem. Let us first look at the new concept and introduce the terminology:

A **gate**
is a network link which is to become a new trip end.
An **in-gate**
corresponds to the beginning of a new trip (i.e. the origin), while a
**out-gate**
corresponds to the end of a new trip (i.e. the destination).
Any part of a trip which lies between an in-gate and the next
out-gate is called a
**traversal**.
Since, within the EMME/2 framework matrices, are always zone-to-zone,
we need to relate each gate link to a zone. With this, the
**traversal matrix**
is defined as the matrix corresponding to the gate-to-gate traversals
occurring in the assigned trips.

Next, we outline how the new traversal matrix feature is implemented in the framework of the already existing additional options assignment:

A special
*path operator*,
named "traversal" is used to trigger this new
feature. The
*additional link attribute*
is used to distinguish gate links
from ordinary links: gate links contain the node number of the zone they
correspond to, while non-gate links assume the values zero.
Optionally, the sign of the link attribute may be used to enforce that
a link is only used in-gate (+) or out-gate (-), but not both.
The
*additional attribute matrix*
is used to store the traversal matrix generated by the assigned trips
of the
*additional demand matrix.*
The numerical
*path attribute*
associated with each path, and to which the
*path threshold*
is applied, corresponds to the number of traversals detected in the the path.
The
*additional volumes*,
finally, correspond, as usual, to the volumes of those trips in the additional
demand matrix for which the path threshold condition is satisfied.

**Figure 3:** Figure 3: Volumes in subarea data base (note new centroids at boundaries)

Coming back to the initial example, here is how we can use this approach to compute the subarea trip matrix used in Figure 3 above: New centroids are associated with all streets entering or leaving the subarea. The links corresponding to these streets are defined as gate links and a link user data, say UL1, is prepared containing the corresponding new zone numbers. Also, all connector links within the subarea are defined as gate links, using the centroid they connect to as value for UL1. For all non-gate links UL1 is set to zero. An additional options assignment can now be performed using UL1 as additional link attribute and the special path operator "traversal". The resulting traversal matrix can then be punched and later to read into the data base containing the subarea project.

The concept explained here is very general. Apart from extracting subarea matrices, it can also be used in many other situations. Let us just name a few here:

- Analyze aggregate flow patterns within a region. Note here that it is well possible to have several gate links (such as all links within a certain region) point to the same zone. The resulting traversal matrix then no longer corresponds to a link-to-link matrix, but may be on a more aggregate district to district level.
- Generate ramp-to-ramp matrices on a freeway corridor and compute fares on a toll-gate to toll-gate basis, if applicable. Obviously, the link gates here correspond directly to the ramps and the toll gates.
- Compute local traffic patterns as input data for signal setting programs such as TRANSYT7. With a judicious use of the correspondence between gate links and zones, it is possible to compute with a single assignment the traffic pattern matrices for all signal coordinated subsystems within an entire city.
- Generation of intermediate matrices for combined-mode trips, such as park-and-ride. This is a tricky problem, as we all know. The traversal matrix is not the ultimate solution, but offers at least a systematic way to assign transfer nodes and to split the trip into its two components.

Watch for more detailed information in the EMME/2 User's Manual and in upcoming issues of EMME/2 NEWS.