Source of this image is linked here.
This is about three unrelated points from the Monday Town Council work session that, in hindsight, struck me as possibly worth writing up: The Town traffic simulation, the treatment of the Town strategic “plan”, and the end game 18 to 24 months from now.
Town traffic simulation.
Part of the Town’s “Multimodal” traffic study estimated the impact on traffic congestion from Maple Avenue development. I’ve spent a lot of time trying to figure out what the consultants did to arrive at their numbers. As of last night’s meeting, I have officially given up on that, because I can’t make head or tail out of it.
But I did take away one thing from trying to puzzle that out: There’s a lot of uncertainty (wiggle room) in that calculation. That’s worth noting, I think. See if you can follow this.
- Back in August, the contractor presented results showing 758 additional net new evening rush-hour trips from Maple Avenue redevelopment. They did not talk about it during that presentation, or during their next presentation. But it was on a slide that they skipped over (Post #358).
- One issue I had with that is their “baseline” traffic, i.e., the number of trips that they assumed occurs right now. Their graphic clearly showed that they assumed that (e.g.) currently-empty buildings were generating traffic on Maple.
- The single worst example of that was the assumption that the Suntrust Bank (east) currently gets 381 trips in the afternoon rush hour. As previously noted, that’s a ludicrous number — it amounts to one car going into or out of that bank parking lot every 10 seconds. Councilman Majdi called them out on that, but both the contractor and Town Manager strongly defended that as “science”. I was so ticked by that misuse of the term “science” that I sat in the bank parking lot and counted cars to demonstrate that the actual traffic to that building was about one-tenth of that (Post #465).
- When I want to look at the final report, I couldn’t find those 381 trips. As it turns out, at yesterday’s work session, it was revealed that the contractor removed those 381 existing trips from the baseline. Simply zeroed them out. That’s why they are no longer in the report. And so, presumably, we have no further cause for complaint.
- OK, fine, I can do arithmetic. If they remove 381 from the baseline, that should then add 381 to the net new trips. (Why? Because you net out the existing traffic, when calculating the net new traffic. If you reduce existing traffic by 381, then you should have increased the net new traffic from development by 381.
- And yet … in the final report, the net new trips from Maple Avenue actually decreased from 758 to 500.
So, without pondering how they justified that, just do the math. Focus on the simple arithmetic of how they had to have gotten from the prior estimate to the current estimate. Solve for X: 758 + 381 + X = 500. Turns out, X = -639. That is, they managed to extract a further 639 net new trips out of their analysis, to get from the original estimate that (presumably) netted out the Suntrust 381 in the baseline, to the final estimate that did not. Just as a matter of arithmetic.
This X factor of -639 trips is what economists call a structural uncertainty in the estimate (as opposed to a statistical uncertainty). It’s the uncertainty that arises from doing the numbers one plausible way versus another (as opposed to a more traditional statistical uncertainty, which arises from purely random factors, so to speak).
So this lower bound for the true stuctural uncertainty of the estimate — how much it changes based on choices made by the analyst — is larger than the estimate itself.
A lot of other things about the methods and results looked counterintuitive to me. For example, the net new traffic during the AM rush hour, to the extent that it left Vienna, flowed mostly westward (i.e., against the direction of morning rush hour traffic). About 2.5x as many additional cars exited Vienna at Nutley as at Follin. But put those issues aside. The simple arithmetic of getting from the draft to the final — the X above — is what convinced me that I would never have any real understanding of how they arrived at their numbers.
So this is truly a black box, and a black box it shall remain. There are open-source software packages that allows individuals to model transportation networks (e.g., here, here, or here.) All of them require considerable amounts of data as input (e.g., traffic light timings, traffic counts). I’m not going to put in the effort to try to gin up my own estimate. But my conclusion is that this is the only way to avoid having the results be a total black box.
Addendum: Traffic counts and the K-Q curve.
Addendum: I also have no clue what these traffic models do when actual traffic passes the peak of the “K-Q curve”. (Briefly, as you try to stuff more and more vehicles through a given roadway (increase the density of cars per square foot, traditionally represented by “K”), each individual car may move more slowly, but in aggregate, the total flow of cars (represented by the letter “Q”) increases. That is, at first, each car may move slower, but you get more total cars moving through the road segment. But as you continue to add cars, you reach a point where the reverse is true: You get so crowded that adding more cars actually reduces total traffic flow. Not only does each car move more slowly, but you actually get fewer total cars to pass through the road segment in a given amount of time. That point — where jamming more cars onto the road actually begins to reduce not just speed, but total traffic flow — that’s the peak of the K-Q curve, as in this diagram (k = density of cars, q = total flow of cars through the roadway, v = average car speed).
Source: Wikipedia.
As I understand it, this is the reason you will see (e.g.) metered on-ramps (ramps with traffic lights) at the on-ramps to the inside-the-beltway portion of I-66. They are trying to avoid passing the peak of the K-Q curve. Once you pass that peak, you are helping nobody by allowing more cars onto the roadway. Not only does every individual car move slower, but you actually get fewer total cars to pass down the highway in a given amount of time. All you do is increase the size of the backup.
It sure seems to me that we hit the peak of the K-Q curve during morning rush hour. At least sometimes. At the point where traffic from the Courthouse and Maple light backs up all the way to Nutley, it’s tough for me to imagine what we haven’t hit and passed the maximum possible through-put of the Maple-Courthouse intersection. Here we are, just before 9 AM, looking east and west on Maple, at the Nutley Street intersection.
But here’s the technical question. Look at the diagram above and think of the curved line as a hill. In terms of traffic counts, you get the same traffic count if you are halfway up the upslope of the hill (before the peak of the K-Q curve, where traffic is light and moving well) as you do halfway down the downslope side of the hill (past the peak, where traffic is packed and moving slowly).
I think this explains one oddity of the report, in that the consultants seem to think that we have one long rush hour period from about 8 AM to about noon. Because they are looking at the traffic counts, and the flow of cars is about the same throughout that period. Like so: The flow of traffic (cars/hour) is the same at 9 AM as it is at 11 AM.
Source: Vienna multimodal transit report, 12/20/2019 draft, page 3-13.
But as anyone who drives that road can tell you, there’s a stark difference in the level of traffic queues or waiting times between 9 AM and 11 AM. Just before 9, traffic routinely looks like the pictures above. Whereas around 11 AM, traffic flows far more freely. But you see no difference on the graph above, because the traffic counts, by themselves, are blind to the fact that Maple hits capacity during the rush hour. The count you get when you are on the downslope side of the K-Q curve (just before 9 AM, with huge backups as pictured above) is the same as the count you get when you’re still on the upslope of the curve (around 11 AM say, when traffic moves pretty well).
So that’s just an oddity that I noticed. Traffic counts (cars/hour) do not, by themselves, accurately measure traffic, because of the ambiguity caused by hitting the peak of the K-Q curve. Very light traffic and very heavy traffic can generate identical traffic counts. And the graph just above doesn’t show that we have one long rush hour. It just shows that the total traffic counts don’t change much between the absolute peak of the AM crunch (which I place at about 8:45 AM) and the must less crowded mid-morning period. I think that, as much as anything, demonstrates that we hit some measure of capacity on Maple during AM rush hour. Once you hit capacity on Maple — as I infer that we due during the AM rush — additional traffic does not result in additional traffic counts.
I’ll mention one other truly weird possibility. At this most recent meeting, Coucilman Noble made much out of the new traffic light system that Vienna is getting. (I have the vague notion that VDOT, not the TOV, is responsible for that, but that doesn’t matter). If that traffic light system actually increases throughput during the periods when Maple is at capacity (something that I doubt will happen, per discussion of capacity above, but is possible), then, by traffic counts alone, it will make it look as if traffic has gotten worse during rush hour. That’s just another example of the way in which traffic counts, alone, can provide a misleading indicator of traffic when a road is at capacity. If there’s a fundamental change in the roadway (in this case, new light timing), traffic (counts) going up can mean that traffic (wait times) is going down.
And as a final, final note on that, if the Town of Vienna wants Vienna citizens to be aware of some profound benefit they are going to get from new traffic signals, I suggest that they actually provide at least some sort of description of what they intend to do. Near as I can tell, the entirety of what Vienna has to say about this project is a total of 23 words on this page on the Town of Vienna website. Normally, as you may realize, I will do my homework to understand what the Town is about. But from the description, I can’t even find the words to Google up what this is.
Town Strategic “Plan”
In theory (and by law), anything the Town of Vienna government does needs to comply with the Town’s strategic plan. But if you look back at when the Town developed MAC zoning, they developed MAC zoning (2014), then rewrote the strategic plan (“mixed use development) to match it (2015-2016).
This more-than-begs the question of what you mean by “plan”, if you rewrite the plan to match what you subsequently decided to do. I have a vague idea that it isn’t even remotely legal to do that.
That said, based on the last work session, that’s the plan going forward. When Councilman Majdi brought up the idea of addressing the comprehensive plan first, that was (of course) immediately shot down. The agreed-upon sequence is now to rewrite the zoning (with apparently no restrictions whatsoever), and then once again rewrite the comprehensive plan to match whatever comes out of the zoning rewrite, if necessary.
Just in passing, and to underscore how loosey-goosey this is, Town staff have now set it up so that this Town Council is actually providing less guidance to this process than occurred during the original development of MAC zoning. At least, under MAC, Town Council somehow arrived at a firm limit on building height. Here … near as I can tell, anything goes. Town Council has not publicly agreed on even one single thing that they want to see in a revised MAC zoning. It’s all up to the Department of Planning and Zoning. That’s no surprise, given that Planning and Zoning appears to be controlling this process.
Looking 18 months down the road.
Fundamentally, the limit on the density of development on Maple Avenue appears to be a political limit. It’s really about what the median Vienna voter wants. There’s no technical barrier to filling Maple Avenue with Chick-fil-A-car-washes. It’s just that the people who live here do not, on average, seem very fond of that idea, and they will vote for people who say they won’t do that.
This is all the more true if you purposefully ignore any other possible limits to growth. E.g., if you will not discuss development in the context of the capacity of Maple to move traffic, or in the context of impacts on nearby residential neighborhoods. Barring all that — if you acknowledge no other limits — then the only limit on the density of Maple Avenue development is a political limit.
This is a point that Councilman Majdi brought up at that work session. And either his fellow Council members didn’t get it, or they just shot it down as sort of knee-jerk reaction.
So I need to point out the following: Town staff have structured this process so that our elected officials have no say in shaping the new MAC. They will have no formal input in what happens to MAC zoning until the very end of the process. The process will be controlled by the Department of Planning and Zoning, with input from the Planning Commission (still largely staffed by holdovers from prior Town Council.) Only at the very end of the process will Town Council be presented with the finished products.
Councilmember Patel tried to reverse that — to get Town Council to have first say over the shape of the revised MAC zoning — and got quashed by the pro-MAC members of Town Council.
So I’m just pointing out the disconnect here. The only functional limit on MAC density is a political limit. And our political body is (formally, at least) completely shut out of the process of shaping the new MAC, until the very end.
The only logical conclusion is that this is likely to end (or, at least, risks ending) in some sort of train wreck. The people actually structuring the new MAC are not subject to any political constraint — they are not elected. And the people who are elected are not part of the MAC-rewrite process. That’s exactly what the response to Councilmember Patel established. But in the end, the constraint on what can and can’t be done is a political one. So this is a fundamental mis-alignment of incentives, and poor overlap between scope of authority and scope of responsibility. Town Council is going to be responsible for what comes out of this process, but they have been stripped of all authority to shape it.
What guarantees that Town Council will be handed a new MAC that is politically acceptable? Nothing. The process is literally and purposefully structured that way. Any notion that Town Council would offer overall guidance (by having first crack at proposals) was firmly snuffed out at this past Town Council work session.
And that’s the scenario that I reckon as a train wreck. Suppose the very-pro-development Department of Planning and Zoning, working in a political vacuum, comes up with a zoning proposal that appears unacceptable to the median Vienna voter. Then what happens?
I believe that Town staff are actually counting on that possibility of train wreck. That is, they are counting on being able to cram this down Town Council’s throats, at the end of the process, one way or the other. They think that those who oppose larger buildings and higher-density development will blink, in order to avoid that train wreck. (E.g., to avoid vetoing a proposal that too two years and a quarter-million-dollar contract to develop, and that includes a bunch of purely technical and non-controverial fixes to Town Code in addition to a rewritten MAC.) By refusing to separate out the non-controversial “clean up” portion of this work, from the more controversial changes to Town zoning, they can given Town Council a one-vote take-it-or-leave it choice (as I have already noted, per Post #483 and others).
Or, possibly, they are hoping that this next election will lead to a change in the fortunes of the pro-MAC portion of Town Council. So that by the time this comes to a vote, they’ll have the votes for a higher-density MAC zoning. That’s certainly possible. From what I can tell, the anti-MAC forces seem totally disorganized at this point. I guess we’ll have to wait and see.
