Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
input table for the demand that is to be simulated for the network. To develop the Vista network data from the Atlanta regional model data, the link and node tables were trans- formed directly into the format required by Vista by reordering the data fields and converting some of the units. For the demand data, the regional model demand matrices were first exported to test files using the Citi - labs Cube (see citilabs.com) software with which they were created, and those text files were then manipulated to produce the required Vista demand table. The trip matrices from the regional model were developed by using typical aggregate model methodologies. The result- ing matrices defined flow rates of vehicles per 4-h demand period by vehicle class (sov, hov, truck). The flow rate from an origin zone to a destination zone could in general be a noninteger number and often was some fraction of a trip. The Vista demand table required a record for every discrete vehicle, so the conversion process included converting flow rates to discrete vehi- cles while conserving the total number of vehicles and included assigning departure times, in seconds from the start of the simulation period. The departure time profile from the regional model, which specified the proportion of vehicles departing during each hour of the 4-h period, was used to control the departure time assignments. DTA model requirements for network data are some- times purer than is typical for aggregate travel demand model networks. Specifically, where an aggregate model might define the speed field to be free- flow speed as observed or as an expected value, including the influence of traffic signals, a DTA model will require posted speed for links and should be allowed to simulate the relation- ship among traffic, traffic control, and speed. Similarly, where an aggregate model might have network capaci- ties defined to ensure that congestion effects are ade- quately represented in assigned network travel times and flows, a DTA model requires that network saturation flow rates on surface streets and service flow rates on uninterrupted flow facilities be defined so that the cor- rect aggregate fundamental traffic flow relationships can be represented. Because the movement of vehicles through the net- work is represented by a traffic simulation model to determine network characteristics for the dynamic user- equilibrium route choice procedure, it is necessary to represent the traffic control system. The traffic simula- tion will simply move vehicles along network links on predetermined paths over time at their free speed as long as there is room for them to move. When more vehicles want to move on a link than the link has room for, con- gestion will develop, and vehicles will need to progress according to some rules, usually some kind of first-in, first-out rule. In line with this general way of moving vehicles along their paths, the simulation model must follow simple rules of the road with regard to traffic sig- nals; a vehicle encountering a red light at a traffic signal (or the end of a queue waiting at a traffic signal) waits and moves forward after the signal changes to green (or the queue moves forward). In Vista, traffic signals are defined as simple preset signals. It is possible to include permitted, protected, and permittedâprotected combina- tion phasing. In the implementation described here, per- mitted left- turn phases were defined if left- turn flows warranted a separate phase, and permitted phases were defined for through and right- turn movements. Traffic control settings for signalized intersections were determined by applying a straightforward green time allocation methodology to the approaches at sig- nalized intersections. A custom- written program was used to read movement flows from an initial Vista model run and to calculate cycle length, number of phases, phase lengths, and order of phasing. From this informa- tion, the tables required by Vista to represent traffic con- trol were written. One further note about traffic control might be rele- vant. One might be tempted to believe that preset signal timing parameters are a limitation given that in reality many intersections have traffic- actuated traffic control. This would clearly be the case in a microscopic context where traffic patterns are more or less fixed and the microscopic model is used to evaluate the impact of details such as geometry, capacity reductions, traffic con- trol, and traffic merging and weaving. In the mesoscopic DTA model, however, traffic is simulated to produce dynamic user- equilibrium route assignment for the vehi- cles in the demand table. Simulating traffic control that varies as traffic varies is problematic for the dynamic network equilibrium methodology, and the use of preset traffic control makes the problem much more tenable. SOLVING FOR THE DYNAMIC NETWORK EQUILIBRIUM The dynamic user- equilibrium solution procedure involves a sequence of steps that include simulating the movement of vehicles along predetermined routes, calcu- lating those routes between originâdestination zone pairs by time interval, and allocating vehicles to one of a set of competing routes. When the routes used by vehicles between origin and destination by departing assignment interval are equal for all origins, destinations, and assign- ment intervals, and no additional lower travel- time routes exist, the dynamic user- equilibrium solution has been determined. The vehicle simulation is based on the propagation of vehicles according to the cell transmission model (CTM) (1). Network links are divided into cells, and vehicles are moved from cell to cell along links and between links as 103DYNAMIC TRAFFIC ASSIGNMENT MODEL BREAKDOWN