Traffic Volume Balancing
From Traffic Analysis and Microsimulation
Contents 
Introduction
This document discusses a procedure for balancing traffic volume data along an accesscontrolled facility such as a freeway. If directional data is available, balancing can also be applied to arterials or other nonaccesscontrolled facilities, provided that traffic generators such as side streets and major driveways are treated in a manner similar to "ramps" in the discussion that follows.
Fieldcollected traffic volumes for the Wisconsin freeway system almost always contain mathematical inconsistencies. For example, if we start with the observed volume at an Automatic Traffic Recorder (ATR) station and proceed in the direction of travel, adding the onramp volumes and subtracting the offramp volumes, the running total almost never matches the observed volume at the next ATR.
These inconsistencies arise primarily from the fact that currently it is not possible to count the entire network simultaneously. Instead, data must be assembled from multiple dates and sources. The sources include continuous freeway mainline counts from ATRs, supplemental 48hour mainline counts collected using portable radar units, 48hour ramp counts collected using portable pneumatic tube counters, and perhaps intersection turning movement counts. Because this data is collected at different times and with different technologies, it must be adjusted or "balanced" to obtain a mathematically consistent data set.
Benefits of Balancing
When implemented judiciously, the balancing process helps "clean" the traffic volume data. It tempers the effects of outliers (such as counts collected on nonrepresentative days) and counting errors (such as counts affected by equipment problems). To a limited degree it also allows imputation of missing volumes, for example using last year's data as a preliminary estimate of the volume at a site where a detector has recently failed.
Balancing the data also results in faster convergence of OD matrix estimation. This is because when matrix estimation is applied to unbalanced count data, the software can oscillate between different solutions as it attempts to match conflicting numerical targets.
The Balancing Process
Manually balancing a large freeway network is an extremely laborintensive and frustrating task, with no unique mathematical solution. Freewaytofreeway interchanges pose a particular challenge for manual balancing, since each ramp affects three or more computations. An automated mathematical balancing solution was developed to overcome these issues. The main steps in this process are as follows:
 Importing the raw traffic data from TRADAS, VSPOC, and other sources such as intersection turning movement counts.
 Computing the imbalance in the imported data set by means of running totals. Generally speaking, trusted ATR sites are used as reference points for this computation.
 Adjusting the counts using mathematical optimization, subject to the constraint that the imbalance must be zero. The objective function for the optimization is to minimize the difference between the adjusted and unadjusted volume sets, as measured by the GEH formula. More specifically the G_{H} formula is applied to hourly data (such as the AM peak hour) and the G_{D} formula is applied to daily data.
Setting Up A Volume Balancer
Volume balancing can be implemented using purposebuilt software or in a spreadsheet. In either case an optimization algorithm needs to be available. If the corridor consists only of service interchanges and ordinary freeway segments, each travel direction can be balanced separately. If the study area includes freewaytofreeway interchanges, the entire study area must be balanced simultaneously. Special care must be taken when coding freewaytofreeway movements to assure that the adjusted volumes are consistent for all routes involving that movement.
The sequence of counts along a corridor is important to the balancing process. The most straightforward process is to begin at a mainline location where the numerical value of the count is known and trusted. Next, compute running totals by proceeding in the direction of travel, adding the entrance ramp volumes and subtracting the exit ramp volumes. In this way, volumes usually can be computed for all (or nearly all) ramps and freeway segments.
In many cases this sequential procedure allows computation of volumes for segments where count data is missing. For example, most Wisconsin freeways have counts on ramps and basic freeway segments, but not on the short segments between ramps at an interchange. This commonly occurs at diamond interchanges, but the volume on the short segment between ramps can be estimated as the upstream mainline volume minus the exit ramp volume (or if necessary, as the downstream mainline volume minus the entrance ramp volume).
In some instances balancing is thwarted by incomplete data. For example, if an exit splits into two downstream ramps and only one of them has been counted, the missing ramp's volume will need to be collected in order to determine the total volume (without this data the balancing process can produce misleading results or fail entirely). Collectordistributor roads are another situation where the data set may be incomplete; such areas should be reviewed before starting to set up the balancing process.
Setting up the balancing process will generate a data matrix that includes each ramp and each freeway segment. In some cases a location will have both observed and computed volumes, while in other cases only a computed volume will be available. The balancing process involves developing adjusted volumes for each ramp and segment, keeping the adjusted volumes as close as possible to the observed volumes while zeroing out the difference between the running totals and the volume at the last station in the sequence. By "as close as possible" we mean that wherever possible we compute the GEH between the adjusted volume and the original observation, and within the optimization algorithm we keep trying different adjustments until we find the one that minimizes the sum of the GEH values along the entire corridor.
Worked Example
Table 1 shows an example of the balancing process. In this table, station type "A" means an ATR, "B" means a basic freeway segment, "M" means a short segment between ramps at an interchange, "0" means an exit ramp, and "1" means an entrance ramp.
Suppose we begin at station 990001, where the observed volume was 66206 vehicles per day. Let's assume that this is a trusted ATR station known to be in good working order. We then deduct the 5440 vehicles exiting at Bravo Blvd, for a running total of 60766 on the short freeway segment inside the Bravo Blvd interchange. Next we add the Bravo Blvd entrance ramp volume of 8141, bringing the running total to 68907. But this contradicts the field count at station 991918, which was 75381. Something is wrong! If we continue to compute running totals, by the time we get to the end of this corridor at Delta Road the running total will be 77356, which is 861 more than the observed volume at the final ATR station.
In this case the imbalance is a positive number, so to balance the volume set it will be necessary to reduce the entrance ramp volumes and/or increase the exit ramp volumes. In addition, the mainline count between Bravo Blvd and Charlie Parkway appears to be much too high. That is a type "B" site, which means it's a shortduration count and probably not as trustworthy as the ATR data (perhaps it was taken when there was a special event that pushed up the volumes). Through the optimization process the software adjusts the ramp volumes to resolve the imbalance. The process also reestimates the mainline volume at site 991918; in essence the software concludes that the field count at that site was inconsistent with the rest of the data set and adjusts it sharply downward.
Station ID  Type  Location  Observed Volume  Adjusted Volume  Change  G_{D}

990001  A  I999 NB between Alpha Ave and Bravo Blvd  66206  66206  0  0.0 
993173  0  Bravo Blvd exit ramp  5440  5440  0  0.0 
M  Between ramps at Bravo Blvd interchange  (no data)  60766  
993174  1  Bravo Blvd entrance ramp  8141  8137  4  0.0 
991918  B  I999 NB between Bravo Blvd and Charlie Parkway  75381  68903  6474  7.6 
993178  0  Charlie Parkway eastbound exit ramp  20826  20826  0  0.0 
M  Between ramps at Charlie Parkway interchange  (no data)  48077  
993178  0  Charlie Parkway westbound exit ramp  12957  13018  +43  0.2 
M  Between ramps at Charlie Parkway interchange  (no data)  35059  
993371  1  Charlie Parkway westbound entrance ramp  16990  16237  753  1.8 
M  Between ramps at Charlie Parkway interchange  (no data)  51297  
993677  1  Charlie Parkway eastbound entrance ramp  25242  25203  45  0.1 
990002  A  I999 NB between Charlie Parkway and Delta Road  76495  76495  0  0.0 