Prompted by Brendon’s recent post (and a Twitter conversation with Ethan and Janne), I got interested in some of the traffic counts and engineering on Washington Avenue. I looked at the Washington Avenue Traffic Operation Analysis by Alliant Engineering for Hennepin County. On p.11 of this document are traffic “counts” the report said were collected in Spring of 2011. The traffic added up perfectly, and with some experience looking at traffic counts in a previous life (some people’s previous lives were as Cleopatra or the King of England, like Bill Gates I was a traffic counter), I had to believe some massaging was going on, data never comes out that clean, especially when it is collected on multiple dates. For instance, there is conservation of flow in traffic, every car that enters and intersection must leave it (unless it is raptured). A traffic count at one site on one date will ensure this. Similarly every car that leaves an upstream intersection must arrive at the downstream intersection, after controlling for driveways. A traffic count on one date is likely inconsistent with another date. Other reasons for massaging include inconsistent peak periods (the peak time at intersection A may differ from downstream intersection B).
In one of the great blessings of open data, Minneapolis makes its raw traffic counts available online. So I went to their website and looked for myself, under turning movement counts [TMC] on Washington Avenue South. These counts are summarized in Table 1 for Eastbound traffic (and the first 5 columns of Table 2 for Westbound traffic), along with the numbers from Alliant’s report. As you can see Alliant’s numbers (data column 3) are 10 to 35% higher than the counts in the City of Minneapolis database for the same period (data columns 1 and 2) (and I assume these are the source of Alliant’s resulting numbers, though the report is vague on the traffic count details). The ratios are given in data column 4.
Why does this matter? By being “conservative” and adjusting traffic counts up, they are over-estimating the need for roadway capacity, that is, they are being “liberal” with the number of lanes required to ensure a particular level of service.
Table 1: Eastbound AM flows on Washington from Hennepin to 11th Avenue
Cross-street | Count Inflow | Count Outflow | Alliant Inflow (Fig 5) | Alliant/Count | ||
Hennepin | 1061 | 906 | 1172 | 1.10 | ||
Nicollet | 880 | 887 | 972 | 1.10 | ||
Marquette | 831 | 860 | 988 | 1.19 | ||
2nd Ave | 812 | 773 | 1044 | 1.29 | ||
3rd Ave | 753 | 890 | 952 | 1.26 | ||
4th Ave | 923 | 561 | 1130 | 1.22 | ||
5th Ave | 537 | 642 | 620 | 1.15 | ||
Portland | 640 | 462 | 744 | 1.16 | ||
Park Ave | 474 | 578 | 532 | 1.12 | ||
Chicago | 702 | 666 | 724 | 1.03 | ||
11th Ave | 593 | 776 | 656 | 1.11 |
Table 2: Westbound AM flows on Washington from 11th Avenue to Hennepin
Cross-street | Count Inflow | Count Outflow | Alliant Inflow | Alliant/Count | Dominant Dir. | WB/EB | WB/ln w/ Rev. | EB/ln w/ Rev. | Lane Split | ||
11th Ave | 1046 | 1107 | 1268 | 1.21 | W | 1.764 | 349 | 593 | 3/1 | ||
Chicago | 1120 | 870 | 1262 | 1.13 | W | 1.595 | 373 | 702 | 3/1 | ||
Park Ave | 875 | 998 | 1040 | 1.19 | W | 1.846 | 292 | 474 | 3/1 | ||
Portland | 875 | 874 | 1184 | 1.35 | W | 1.367 | 437.5 | 320 | 2/2 | ||
5th Ave | 921 | 1131 | 1068 | 1.16 | W | 1.715 | 460.5 | 268.5 | 2/2 | ||
4th Ave | 1155 | 783 | 1356 | 1.17 | W | 1.251 | 577.5 | 461.5 | 2/2 | ||
3rd Ave | 786 | 667 | 928 | 1.18 | W | 1.044 | 393 | 376.5 | 2/2 | ||
2nd Ave | 607 | 522 | 756 | 1.25 | E | 0.748 | 303.5 | 406 | 2/2 | ||
Marquette | 595 | 612 | 662 | 1.11 | E | 0.716 | 595 | 277 | 1/3 | ||
Nicollet | 555 | 535 | 702 | 1.26 | E | 0.631 | 555 | 293 | 1/3 | ||
Hennepin | 594 | 573 | 686 | 1.15 | E | 0.560 | 594 | 354 | 1/3 |
Reversible Lanes
I was also interested in some other aspect of traffic. Ethan said the traffic was balanced on Washington after I posited that it was unbalanced, and we could consider reversible lanes. In fact it is both, depending on where you are looking. The final columns of Table 2 identify the dominant direction, the directional ratio (WB/EB flow), and what flows would be with the lane split given in the final column. At 3rd Avenue, traffic is balanced, to the East there is much higher westbound traffic in the morning, to the West there is much higher eastbound traffic in the morning. Along Washington Avenue, the midpoint of downtown traffic is 3rd Avenue (not Nicollet as I would have supposed before looking at the numbers).
Is the imbalance sufficient to justify reversible lanes? The case is marginal. In general, with two lanes in each direction, left turn lanes, and good signal timing, I think a 2/2 split should work well enough. Near I-35W a 3/1 split (3 lanes westbound, 1 lane eastbound in the AM) is plausible. Similarly on the westside of downtown, a 1/3 split is also plausible in the reverse direction.
I am leaving the PM analysis as an exercise for the reader.
The Minneapolis Turning Movement Counts can be found here: WashAveAMFlows.pdf and WashAvePMFlows.pdf.
Very interesting. This is crazy. How normal is it to adjust numbers up like this? Is this a problem all over?
Adjusting the numbers to balance is standard practice. We could just as easily be griping about a traffic report where cars were disappearing into thin air because of unbalanced counts. As David mentioned, if you’re trying to model multiple intersections along a corridor, you rarely if ever have counts from the same day that would balance exactly. You’re always trying to cobble together counts from different days/seasons/years to arrive at what you can call the “baseline existing” counts. In terms of adjustments, it’s common practice to identify the intersection with the highest counts and adjust the rest up to match. That’s the “safe” and “conservative” way to make sure you don’t undermodel, which is what most clients are looking for. I don’t know what counts or methodology Alliant used, but for example, in the EB AM peak, it’s feasible that they identified the Chicago Intersection as the highest volumes and adjusted the rest up to match.
I’ve done it both ways, however. I’ve worked on projects where the counts from one intersection are much higher than all the rest and we ended up adjusting that intersection down to match, but that raises red flags as well… Assuming the count is accurate, what were the conditions that caused the counts to be much higher on that particular day, how often does that occur, and is that an event you should be designing for? I’ve also just sort of massaged them all out without using any intersection to control.
Following on Ethan’s question — do the changes in this report strike those who have done this as well within bounds of normal practice?
In my experience, this would be some substantial factoring up. However, I do want to point out that we don’t actually know that any factoring up has occurred, since we don’t really know exactly what base counts they were using in the first place. We do not know that the counts David has shown above were the basis for the traffic study. Clearly the counts have been balanced along the corridor, but we do not know what the starting point was.
We should also point out that traffic along a corridor can fluctuate substantially day to day or week to week. We could count 1000 cars today, 1100 tomorrow, and 900 the following day. This is also why engineers tend to round up, and why engineers are generally uncomfortable with a solution that seems to offer just barely acceptable level of service. If we assume we’ve collected data on an average day, that means 50% of the time, we would expect traffic to be heavier than the data we collected.
See Mike Spack’s blog today: Checklist for Developing Traffic Forecasts, he says:
Given a general planning-level capacity of 500 vehicles per lane per hour for a signalized urban arterial, your idea of reversible lanes would require some serious detailed reviewing. At the planning level, the “off-peak” direction would be overloaded on several segments. Too many assumptions/”generalities” in the planning level estimate, hence why more detailed review would be in order.