TModel Corporation participates in consulting projects in order to keep abreast of the needs of our clients and also to continually advance the state of the art of TMODEL2 software. We recently had the opportunity to work on a truly innovative project to evaluate the impacts of increased railroad operation on the existing and forecast street network. This article briefly discusses the approach that was used and the new tools that were developed that can now be used by all TMODEL2 maintenance users.

The problem was to forecast the travel patterns and vehicular volumes expected to occur with the addition of periodic obstructions due to railroad crossing closures. The blockages are expected to occur for up to 8 minutes at a time and with the total obstructions taking up to 25% of the peak hour.

TMODEL2 software was used in two ways for this analysis. The first use was to project the traffic volumes, speeds, and delay times on all streets in the model area. This includes areas in and around the railroad at-grade crossings. The second use was to report the impacts.

The forecasting model is usually used to forecast a peak hour or peak period of travel. The impacts of the closure of the rail crossings are assumed to occur during the period being modeled, but the conditions change during this period. That is, we have some time when there is no obstruction and other times where there is a total obstruction. Dealing with this special problem in a way to properly model travel demand as well as traffic operation is a challenge.

There are several network modeling issues that must be considered. These considerations are system capacity, [perceived] delay to the vehicles, and queue propagation.

Capacity - In the simplest approach, the capacity can be decreased by the ratio of the amount of time the crossing is closed over the period being modeled. For example, if the crossing is closed for 10 minutes every hour, the capacity can be reduced by 10 minutes/60 minutes or by 1/6.

In addition, there is some startup, lost time, and queue clearance time that has an impact on the capacity that must be removed. This would be relative to the number of times the crossing is closed per hour and the amount of queue buildup. If, for example, 10 minutes was spread across 5 closures of 2 minutes each, the impact on capacity may be different than if there were 2 closures of 5 minutes each. Although we considered this, we ended up only using the capacity reduction above. In the calibration stages, it appeared as though the drivers did not perceive the reduction in capacity as significant enough to impact the change in routes due to a higher v/c ratio.

Delay - Delay was computed for the weighted average delay per vehicle impeded at the crossing. For example, if the total blockage time was 10 minutes per hour, the average vehicle delay during this closure time (assuming they did not detour elsewhere and arrived at a uniform rate) would be 5 minutes. However, because this delay time was only applicable for 10/60 of the hour, the weighted average delay time was computed to be (5 minutes * 10/60 + 0 minutes * 50/60) = 0.83 minutes per vehicle. This was established as one of the calibration rules. Several of the crossings currently have little or no train traffic in the calibration year. However, the forecasted train traffic represents a significant increase, and we wanted a method for showing this impact.

If you are applying this in another area, use caution in applying these rules. Reducing the capacity and adding delay may have a greater cumulative impact than anticipated. These values should be tested in the model calibration and verification stage to insure that the problem is not being over or understated.

Keep in mind that this is a situation that is very different from that of a traffic signal or stop sign, especially if all of the delay that occurs in the hour is due to one blocking incident. It is as if the network allows normal operation for 50 minutes out of 60 and then has a very different operation for 10 minutes out of the 60.

Different model "run" strategies can be tested. One strategy is to implement the capacity restrictions and delays as discussed above. Another strategy is to run the model with no railroad crossing impediments and also run it with complete closures. After both of these runs a weighted average traffic assignment could be derived. A blend of the completely open versus completely closed strategy could be combined with the capacity and delay restrictions was also considered. This can be done if all the railroad crossing impedance times are the same. However, for this case, each crossing impedance time was different.

Upstream Queuing Propagation Impacts - A feature that has been added to the TM3DNA Beta test module is to incorporate the impacts of delays or queuing on upstream operation. This occurs when one intersection is blocked, causing approach traffic to back up and block other intersections. Although TMODEL2 normally incorporates delay at each intersection based upon the entering volume and capacity of the intersection, this delay in TMODEL2 (and other transportation planning software) does not impact the upstream intersection.

With the implementation of Upstream Queuing Propagation (UQP), during the assignment processing, each node is checked for volume/capacity ratios. This will be particularly important for all railroad crossing nodes, whether blocked by a train or not. It could be argued that travelers will not wait at a blocked railroad crossing and these may not be where the queues are. After the residents are aware of the situation they may divert and attempt to use the crossings that are not blocked, and this is where impacts could be greatest.

Any node with a v/c ratio greater than or equal to 1 is selected for "on-the-fly" queuing impacts. This queue is propagated to impact upstream traffic flow as follows:

1) The queue length, in vehicles, will computed as the entering volume minus capacity.

2) The queue will be distributed to the node or intersection approaches based upon the volume entering on each link. Queue lengths, in feet, will be determined by the (number of vehicles * length per vehicle) / (number of lanes). Queuing parameters including the length per vehicle is set in section 1.6.2.8.

3) Nodes upstream of the impacted node will be tested to see if the queue has extended to them, and caused an impact. If the node is impacted:

a) the speed on the link leading to this node will be set to one (1);

b) the number of vehicles that exceed the available queue length on that link will be saved (called the excess queue);

c) the excess queue vehicles will be apportioned based upon the volume entering each link.

d) the analysis process will be repeated until no new nodes are found to be impacted.

This procedure is incorporated in the model run traffic assignment process to dynamically adjust the traffic volume assignments. The outputs of the run will be analyzed as described in the section on reporting.

Reporting - Reporting was performed with standard TMODEL2 features. LOS - level of service was displayed with a combination of color and vehicle operating speed. Average operating speed is compared with TRB Special Report 209, 1994 Highway Capacity Manual for level of service determinations on arterial streets.

Summary statistics were used for a subset of the model area for the following measures: VHT - Vehicle Hours of Travel, VMT - Vehicle Miles of Travel, AVS - Average Vehicle Speed, CVMT - Congested Vehicle Miles of Travel - VMT on links with v/c ratio greater than a specified value, and Relative Vehicle Carbon Monoxide Emissions. In addition, these summary statistics were summarized by LOS category. That is, the VMT and VHT were totaled for LOS A, LOS B, etc. for each alternative analyzed.

To analyze the maximum queue lengths during the railroad crossing obstructions, a period of 8 minutes was taken to be the longest total obstruction time. The capacities from the hourly model were factored to 8/60 of the hour using new section 1.7.1.16. The assigned volumes were factored to 8/60 divided by the peak hour factor (to account for peaking characteristics within the hour) using this same section. Then, the model was run again using this adjusted link file as the input file and using a dummy trip table containing just one zone. This enabled the TM3DNA module with UQP to re-compute all of the queue lengths, without reassigning all of the traffic. This enabled the analysis to be conducted to reflect conditions if traffic did not completely reroute due to the obstructions. One output of the TM3DNA with UQP is the queue lengths are saved in the SZ1 and SZ2 fields. SZ1 contains the number of vehicles that are completely occupying a link. SZ2 contains the number of vehicles that are in a queue on any one link. These can be plotted to show the links that are totally obstructed (SZ1) and those that have any queue (SZ2). Keep in mind that these are average peak hour numbers. Due to traffic signal operation and other features that cause changes in traffic flow throughout the period being modeled, the queue length may be periodically longer or shorter.

Based upon the results of this study, we are still making some modifications to the UQP section to improve its modeling ability. However, this new feature has proven to be very useful in comparing improvement alternatives in this unique study. As always, we welcome your comments and suggestions.