At some point, I might get off my high horse regarding bicycle counts on the Longfellow Bridge. But for now, I’m staying on. Why? Because I did my bike count on a Wednesday morning in June, to get a “typical” commute count (although, to be fair, with colleges out for summer it may have been a bit less traffic than some of the year). And I think I’m collecting better data than the established counts. Going through this process, I’ve found out more information about the National Bicycle and Pedestrian Documentation project, which is used as a basis for counting by local transportation agencies across the country, including the CTPS locally.
And I have not been particularly pleased with what I’ve found.
I think I originally buried the lede here, so I’ll add a bit here that I reiterate in the final paragraph: the bicycle and pedestrian count methodology treats bicyclists and pedestrians more as leisure users rather than treating them as using viable modes of transportation. We don’t take typical auto counts during vacation periods, and we shouldn’t do this for bicyclists, either. We should count bicyclists and pedestrians during normal use times, and design facilities based on this usage, especially in urban areas where bicycling and walking are important not only as transportation modes but as congestion mitigation resources
So what’s wrong with the national bike counting standards? First of all, the survey methods seem to come from about 15 years ago. From the directions:
Each counter should bring counting sheets, two writing utensils, a watch or cell phone for keeping time, and a clipboard or other device to write on. Counts are conducted in 15-minute intervals, and comprise the total volume of pedestrians and bicyclists traveling in both directions passing a given point.
Here we are, in 2013, when everyone has an iPad and an iPhone and a laptop, and we’re taking counts with paper and pencil, and then admonishing people to make sure they don’t lose the paper because it is irreplaceable until it has been entered in to the database. Great. When I went to do my count, I didn’t even consider using paper and pencil, because it just didn’t make sense. I thought about writing a python script, but settled on Excel because it was easier to write and easier to test. But for a national program, how hard would it be to have an iPad app? Nothing fancy, just something where you tap a button every time you see a pedestrian or cyclist (it would be easy to have these buttons be customizable) and then directly upload the time-stamped data.
Is there an up-front cost? Yes. Although my only overhead was the power to charge my computer’s battery and about 30 minutes on Google to figure out how to set up the Excel spreadsheet.
Second, why on earth would you survey typical use on July 4 weekend? I can not get over this. Their explanation is that it is selected because “The 4th of July period … will afford both a typical summer weekday and what is typically the busiest holiday period and activity period for recreational facilities and activities.” Three points. First, July 4 is not a typical holiday. You are likely to wind up counting a lot of people walking or bicycling to parades and fireworks. Are there a lot of parades on Columbus Day? So with one of the four annual counts, you’re collecting data which is unusable every other day of the year. Second, and excuse the italics, but in what universe is July 5, the Friday after July 4, is going to be a typical weekday? Half of my office is taking it off. Half of the country has vacation bounce messages on their emails this week. Third, while it is a busy time, so many people are traveling that it is not representative of many other weekends. I would contend that you’d get much more useful data by surveying a typical weekend in July rather than focusing on July 4. We’re spending all of this time and money to sample bicycle use, and we’re collecting just bad data.
Third, while uniformity is sometimes good, bicycle and pedestrian use is highly localized, so what works in one city may not work in another. In other words, there’s not a very good argument for standardizing bicycle count dates across the country other than to increase awareness. Awareness is a good thing. But it shouldn’t trump good data.
You’d think that the NBPDP would at least be consistent in their data collection documentation, but this is not the case at all. This current survey is planned for a Thursday, Friday and Saturday. Their instructions document (available here) states that “Weekday counts should always be done Tuesday through Thursday, and never on a holiday.” Now, I understand that this is in relation to the national count in September, but, uh, guys? July 4-6 is a Holiday, Friday and Saturday. You’re 1-for-3. That might work in baseball, but it’s not a passing grade elsewhere.
Finally, in Boston this is an especially fraught issue. Why? Because on July 4, many of the city’s highest-use bicycle facilities are being closed. The Esplanade will be closed to bicyclists all day. The Longfellow and Harvard bridges are closing at 4 p.m. So any bicyclists after that point wishing to travel from Cambridge to Boston will have to either cycle across the Charles River Dam, or go up to the BU Bridge. Does it make any sense to take bicycle counts on this day?
I’m not saying that my methodology was perfect, but it’s hard to comprehend how the current counts make much sense. If we go around collecting shoddy data and wind up undercounting bicyclists, we have only ourselves to blame when we get underdesigned facilities. It seems like high time to assess both the overall efficacy of the NBPDP, and especially whether Boston should participate in the program.
And a larger, and perhaps more important point: by prioritizing non-commuting periods, we are treating bicyclists as recreational users, not as a viable mode of transportation. Would we count cars during July 4 week? Of course not. AASHTO even says that such periods are “atypical” and would not have valid data. By counting traffic at these times, we are doing a severe disservice to bicycle advocacy.