Tuesday, November 3, 2009

Transit performance and frequent lines

Last week, the Times' Clyde Haberman described how New York City Transit had revised its performance metrics, so that they measure "absolute on-time performance" as well as "controllable on-time performance." The last measure excluded "situations deemed beyond their control — sick customers, police investigations, repairs, vandalism and so on," in Haberman's words.

Ben at Second Avenue Sagas says that the change is an improvement, but not really sufficient, and I agree with him. He observes that for frequent lines (roughly, less than twelve minutes between trains or buses), adhering to the schedule isn't the most important thing:
New Yorkers don’t really expect subway trains to run "on time" because the schedules, while available, are rarely used and aren’t considered gospel. The better indication of on-time performance involves train wait times. If I just miss a B train during the day, I expect to wait 8-10 minutes for the next one. If I’m waiting longer than that — no matter what time the schedule comes — I consider the next train to be late.

Let's go back to our goals for transit. First, it should work towards access for all; this is pretty much achieved by offering frequent, safe service. Then, it should get people out of their cars. If the train or bus is slower or less reliable than driving, people are going to drive instead. speed and reliability (and sometimes comfort) are where good management can make a difference, and that's how performance should be measured.

On-time performance has something to do with speed and reliability, but not enough. Let's imagine a bus route, the Q200, that runs every five minutes. The most popular trip, from the Statelee Apartments to the Hitek Office Center, is scheduled to take thirty minutes. The intended customer experience is to wait no more than five minutes for a bus and spend no more than forty minutes door to door.

In practice, the passenger crush at Statelee Apartments means that by the time everyone gets on, the next bus is right behind. This leads to the all-too-familiar bus bunching phenomenon, where Bus A is late - and packed - and Bus B is early and empty. So some passengers wait up to ten minutes for a bus, and then it can take 50 minutes door to door.

In terms of our goals, bus bunching is awful, because it reduces not only speed, reliability and comfort, but frequency - which means we're no longer providing access for all. But in terms of on-time performance it's not so bad: the leading bus may be late but the following bus is on time.

Now let's imagine that the bus operator institutes some kind of pre-boarding payment collection at the Statelee Apartments, reducing dwell time and eliminating the bunching. That's a major coup, improving frequency, reliability, speed and comfort. But they won't get that much credit for it, because in on-time estimates it's just a small improvement.

In the years before computers were everywhere, it may have made some sense to use on-time performance as a metric, but now that anyone can plug some numbers into a spreadsheet it's really lazy. So what could we use for a better metric?
  1. Average wait: The MTA calculates its subway wait assessment as "percent of instances that the time between trains does not exceed schedule by more than 2 minutes (peak) or 4 minutes (off-peak)." I would instead say, "If someone arrives at the bus stop (or train station) a minute after the last bus leaves, how long do they wait for the next available bus?" I would also make sure not to count buses that were too full to pick up people as available. Note that this has nothing to do with any schedule.
  2. Average trip time: Pick a popular trip. How long does it take, on average, door to door?
  3. Practical frequency: How often do available buses come? Bunches of buses (less than one minute apart) count as a single bus.
  4. Crowding: How many buses have one of the single seats available? This may not be cost-efficient, but it's still good to know.
By the way: if, as Haberman reports, Jay Walder is being hailed as "the Dumbledore of transportation wizardry," then who is its Cornelius Fudge? Dale Hemmerdinger? And if, as Gene Russianoff puts it, this new era of transparency at the MTA is not quite "the coming of the Paris Commune," should we be glad that we don't have to deal with Shelly Silver as Thiers and Pedro Espada as Mac Mahon?

7 comments:

Alon Levy said...

First: Sheldon Silver is the guy who got the state to fund Second Avenue Subway. Cut him some slack.

Second: the best way of measuring bus bunching is to measure frequency, weighted by time it took since the last bus came. If half the buses come eight minutes apart and half come two minutes apart, the expected wait isn't really five minutes, because 80% of the time you'll be in an 8-minute interval.

On top of it, there needs to be a rule saying something like, "A bus/train is late if it follows the previous bus/train by more than X minutes" where X is the stated frequency. No ifs, no buts, no 2-minute grace periods, and no special measures for controllable delays. Trains in Japan and Germany are capable of running within a minute of a schedule, without uncontrollable delay copouts.

For buses, OTP isn't that bad of a metric, when it is actually calculated correctly, i.e. without the 2-minute grace period or excuses for uncontrollable delays. If buses bunch, then OTP will drop below 50%.

Adirondacker12800 said...

...or they flip the sign on the first bus to Q200 Express Hitek and everyone boards the express before or at Statelee Apartments and gets to Hitek Offices 5 minutes faster. In the mean time the bus that would have been "bunched" after Statelee isn't because it started it's run at Statelee and picks up passengers between there and Hitek. Have a look at the 25 Springfield Ave in Newark, Irvington and Maplewood sometime. Does have the advantage of having Irvington Center with all it's bus routes more or less at the place where the expresses begin to run. . . I see they have stopped originating/terminating some buses at Irvington Center...

Cap'n Transit said...

Alon, I suppose those would work, but I would like to see something that corresponds more to what really matters to bus passengers.

Adirondacker, I agree with you that running express is a good way to deal with bunching on the fly, and that's what NYC Transit does on the subways. The problem is that it halves the frequency for all those people between Statelee and Hitek. Instead of getting buses every five minutes, they get them every ten - and they get to watch the express buses go sailing by. Now, if you just added express runs, that would be different.

Jarrett at HumanTransit.org said...

I've found the easiest way to critique OTP is to imagine a case where every bus on your frequent line is exactly 15 minutes late. By any OTP standard, that's total failure. But for the customer, it's total success.

Adirondacker12800 said...

The problem is that it halves the frequency for all those people between Statelee and Hitek.

Not if you begin running a local between the apartments and the office. You get three buses of service for two and half buses or four buses worth of service for three buses, roughly... It's been my experience that almost everybody gets faster service that way.

SSSSSSSSSSSSSSSS
SS------SSSSSSSSSS
SSSSSSSSS

You can vary it too

SSSSSSSSSSSSSSSSS
SS--------SSSS
SS--S--S--S--SSSS

Alon Levy said...

The whole point is that no bus is going to be exactly 15 minutes late for the entire run. More likely, it starts its run on time, but then deteriorates to a 15-minute lateness by the time it pulls in to the terminal. The spacing may be even to the customer, but the schedule is worthless unless you're near the terminals, and the ride just took 15 minutes longer than it should have.

Cap'n Transit said...

Alon, my main point was that there's no point in measuring adherence to a schedule that nobody pays attention to. Think about jitneys: they make a profit and they don't even have schedules.

Of course trip length is important; it's actually masked by the on-time performance metrics, but it's a separate metric in my proposal.