Human Transit

san francisco: winning speed and reliability battles

Major San Francisco transit lines take longer than they did a century ago, as they have been obstructed by traffic and slowed by heavy passenger loads using (until recently) inefficient pay-as-you-board methods. A New York Times piece by Zusha Elinson lays out the statistics.  

(It's important to clarify, right away, that this has nothing to do with streetcars as a technology.  You could easily be misled by this subtle bit of anti-bus bias:

In 1920, the F-Stockton streetcar carried passengers from the Financial District at Market and Stockton Streets all the way to the Marina at Chestnut and Scott Streets in a zippy 17 minutes. Today a very similar trip on the 30-Stockton, the successor to the F-Stockton, takes a half-hour if the stars are properly aligned.

In general, streetcars replaced by buses have slowed down more, over the last century, than those that remained streetcars, but that's an expression of how much more was invested in streetcars than in buses.  The main lines that use the Market Street Subway -- J through N -- have picked up or shed just a couple of minutes from their 1920 times, even though back then they ran on the surface along Market St (about 3 miles) while now they're in a subway, effectively functioning as rapid transit.  No such improvements were made for streetcars that became bus lines, so of course their performance deteriorated more.  In fact, the 30-Stockton relies heavily on maneuverability in unpredictable Chinatown traffic; a streetcar in exactly the same traffic, unable to move around obstacles, would be even slower and less reliable.)

The real message of this story, though, is the need to have a conscious intention about the speed and reliability of transit.  Highway planners ruled the late 20th century with their clearly defined notion of "Level of Service" or cars, which mowed down opposition through its simplistic A-F letter-grades.  Just after 2000, the Transit Capacity and Quality of Service Manual sought, at first, to claim this same authority-through-simplification for transit.  But while the TCQOS is a spectacular reference guide, few in the business believe that a single A-F score can capture the many important ways that transit succeeds and fails.

My own work in this area has always advocated a stronger, more transit-specific approach that begins not with the single delayed line, but rather with the functioning of an entire network.  Don't just ask "how fast should this line be?" which tends to degenerate into "What can we do to make those forlorn buses move a little faster without upsetting anyone?"  Instead, ask "What travel time outcomes do we need across this network?"  Or turn it around: How much of the city needs to be within 30 minutes of most people?  -- a question that leads to those compelling Walkscore travel time maps, which are literally maps of individual freedom.

A network speed standard would identify necessary speed standards for each service type, but especially for the Frequent Network, because high frequency means greater impact of delay -- both on passenger freedom and the agency's bottom line.  We* used this approach in a Seattle Transit Plan study about 7 years ago:

1.  Define the Frequent Network (every 15 min or better, all day, every day), including any segments that are "Rapid" (faster with fewer stops)

2.  Define the policy operating speed standard for each product (frequent local vs rapid)

3.  Map the existing scheduled speeds on each segment against this standard, creating a map with screaming red segments meaning "deficient."

4.  Prioritize interventions to improve transit speed based on those deficiencies.  

This is quite different from a classic cost-benefit approach in which we count the riders currently on a segment and assign value based on their total travel time saved, because it acknowledges that (a) a dysfunctional segment is probably driving away customers regardless of how many are on it now and (b) the outcome is the network, not just a single line.

We had a lot of success with this in Seattle at the time.  Once the deficiency map was drawn, engineers noticed segments that they hadn't identified as problems before, and went to work on fixing them.  Note too that the method cleanly separates problem from solution.  Don't start with what you think is possible.  Start with what you need.  Define the absence of what you need as a citywide problem that affects the whole network.  Then fix those deficiencies.  If you're going to go to war with three businesses over "their" strip of on-street parking, you're more likely to break through the "big agency attacks struggling small business" frame if you're defending the entire city's transit system.  

Remember: a line is only as reliable as its least reliable point, and a journey through a network is only as reliable as the least reliable of its lines involved.  So one localized problem affecting speed and reliability (such as stops too close together) actually affects a vast area, and drags down public expectations for an entire network product.  If it costs the agency money (as slower service always does) then it's also a direct detriment to the overall abundance of transit service.  That's the frame in which you win battles over three on-street parking spaces, a signal phase, or even an entire tranist lane.

San Francisco's Transit Effectiveness Project is, to a great extent, the culimination of exactly this thought process.  I remember in the 1980s or early 90s a time when Muni proposed to eliminate just one consequential bus stop;  17th & Mission.  The story became: "Big, bad transit agency launches personal attack on the people and businesses at 17th & Mission."  The TEP has worked to change that conversation, emphasizing that on high-frequency services, the speed of every segment is part of the whole city's transit outcomes.  The same process has made it easier to do a range of other locally-hated citywide goods such as removing parallel routes that were too close together.  

Does your city's transit system have a similar project underway, one that moves beyond route-by-route analysis and looks at how every speed/reliabilit deficiency harms the whole city's transit system?

 

*I was with Nelson\Nygaard at the time.  The project was the City of Seattle "Urban Village Transit Network" study of 2004, which became a foundation of the Seattle Transit Plan.

san francisco: cameras will enforce transit lanes

Lanes that protect transit's speed and reliability are only as good as their enforcement.  San Francisco, like many cities, has long had a few lanes whose enforcement was so spotty as to render them advisory.  Now, the city is getting serious, with camera enforcement and significant fines. 

I think another feature will eventually be necessary:  Full painting of bus lanes in the same way that we usually paint bike lanes, along with signage on approaching intersecting streets, so that there is no "I didn't know" excuse.  Sydney, for example, paints its bus lanes deep red, with gaps at the points where cars can cross for turns.

In addition, if you approach as a motorist on an intersecting street, you will see a sign with a lane diagram of the street you're approaching, so that there's no excluse for turning into a bus lane.  Fines (stiff) are often advertised prominently.

 

basics: finding your pulse

Quiz: When is service every 20 minutes worse than service every 30 minutes?

Answer: When it relies on a pulse, or what Americans usually call timed transfer, with routes that run every 30.

A pulse is a regularly scheduled event, usually happening at the same time each hour, in which transit vehicles from a range of routes -- usually running every 30 or 60 minutes -- are scheduled to all meet together.  A group of hourly local routes, for example, might all come to the pulse point between :22 and :25 after the hour and leave at :30. That way, nobody has to wait more than 8 minutes for a connection even though the services in question are hourly.  Here's a rough diagram of a half-hourly pulse pattern, by Ross Maxwell.¹  (The original, slightly sharper, is on p129 here.)

Often, pulses are organized around a main transit line, such as a trunk bus or rail line that takes you to a nearby larger city.  In these cases, the main line vehicle usually doesn't dwell as the local buses do, since it's the most crowded service and hence the most speed-sensitive.   Instead, the locals arrive a few minutes before the trunk passes through, and leave a couple of minutes after.

Pulses are the only way to provide connection wait times that are much, much better than the frequency of the services involved.  A pure pulse is also equally convenient for connections between any pair of lines, and thus for travel in any direction. 

For this reason they are used universally, in North America, in small-city networks where frequencies are low, and often also in suburban areas of large cities.  If you're in a North American suburb or small city and see a large number of buses hanging out together on a streetcorner, you're probably watching a pulse.  The sight can vaguely humanizing; for a moment it looks as though these big obtrusive vehicles are people too, with human needs for social interaction every hour or so.

In Australia, by contrast, the prevailing operating habit is to scrupulously separate operating time from driver break time.  Drivers often dislike having their time at a pulse point counted as their personal break time, because throughout the pulse event they are mixing with customers, being asked questions, etc.  So in Australia, it's more common for buses to arrive at the pulse point at, say, :22, drive onward to a separate layover point where the drivers can take their breaks away from customers, then drive back through the pulse point at, say, :30. 

But frankly, Australian public transport authorites, especially those responsible for small cities and outer suburbs, seem reluctant to embrace pulses for reasons I don't entirely understand.  And even in North America, agencies that rely on pulse scheduling prefer not to advertise it.  You may have to explore several timetables and compare them to each other in order to discover that pulse scheduling is in place.

I was introduced to pulse scheduling in Portland at a tender age.  I was a teenage transit geek, and then an undergraduate working part time at TriMet, the transit agency.  This happened to be the period (1979-85) when the lattice of suburban pulse networks was being constructed. 

We spent a lot of time thinking about how the pulses interact with each other.  For example, if you have a pulse of buses at Beaverton Transit Center at :05 and :35 past the hour, and one route goes from Beaverton to Sunset Transit Center in 12-14 minutes, how do you schedule the Sunset pulse?  Do you set it at :20 and :40, so that this connecting route can serve both pulses but with just a few minutes to spare?  When this route is late, a lot of connections will be missed, and a lot of people stranded.  Or do we just set the Sunset pulse at :05 and :35, so that the bus linking the two transit centers has lots of spare time but now has too much time to kill and will tend to arrive inconveniently early for one pulse or the other.  Or do we just accept that this line isn't going to hit one or the other of the pulses precisely?

To do pulse scheduling, we have to plan the pulse schedule as we're designing the network.  In the two-pulse problem I outlined above, we will think hard about the line connecting the two pulses and to ask if we can either make it a little shorter (so that it will get there more reliably in 15 minutes) or a little longer (so that it will get there in 30 minutes without so much time to spare).  I have designed some large networks with multiple pulse points, all designed to work harmoniously.  To do that, I've always designed lines between pulse points with the specific goal of making them a certain length.

Pulse scheduling can often affect the schedules of a trunk line too, especially when that trunk line isn't extremely frequent.  Even a 15-minute frequency on the trunk line (which is the all-day standard for most North American light rail, for example) may require adjusting the trunk schedule to better fit the pulse.  In particular, if a pulse that happens between :20 and :30 after the hour is partway along a trunk rather than at the end, and if the intention is all-way connectivity, that means that both directions of the trunk need to pass through the pulse point at around :25; in other words, a complete pulse requires that oncoming trunk-line vehicles be at the pulse point at or near the same time.  This is why pulsing is especially hard if the trunk line and local services are run by different agencies or operators. 

In any case, pulse scheduling requires an intimate two-way conversation between the planning and scheduling tasks.  In agencies where the drivers' union is legally entitled to sign off on scheduled running times, they have to be involved as well, because a disagreement over 4 minutes of running time can determine whether the whole structure works or fails. 

Transit agencies that are not set up to have this conversation, or that locate planning and scheduling too far apart organizationally, become structurally incapable of noticing and exploiting pulse opportunities.  In other cases, pulses may simply not be the prevailing habit, and there may be nobody around who is in the position to suggest them.

The organizational challenge presented by pulsing is, to me, a positive feature of the concept.  Better integration of planning, scheduling, and operations management has many benefits, and if the pulse challenge helps motivate an agency to get there, so much the better. 

But pulse scheduling does have some practical limitations.  In particular, it struggles in any environment where the running times are prone to vary a great deal. 

Pulses are about managing a low-frequency network, so they aren't generally needed in inner cities  Pulses are almost universal in small-city design in North America, because most such cities have little traffic congestion and can therefore run a pulse reliably.  The best big-city agencies also do some kind of pulse late at night, when their services are very infrequent.  For example, this map of all night service by San Francisco MTA uses little black circles to highlight points where the lines make timed connections with each other, even though they're running only every 30 minutes.  Note the complexity of the scheduling task implied by multiple timed connections along the same line; it's an impressive commtiment.

But in the suburban areas of big cities, running times vary due to traffic congestion, and pulse operations struggle.  I vividly recall the moment in about 1983 when Tri-Met decided to let its pattern of half-hourly Beaverton-area pulses slip to a 40-minute pattern during peak hours, because they simply could not guarantee travel times in peak traffic.  TriMet continues to attempt pulse operations because there is simply no other way to serve the multi-directional demand pattern of the modern suburbs, especially where many people work in widely scattered business parks.  I suspect that the difficulty of guaranteeing pulses in these settings is the main reason that big suburban agencies are reluctant to advertise their pulsing too much.  Small-city agencies, which don't deal with such severe congestion, are more likely to emphasise that at the heart of their network, they have a pulse.

A lattice of interconnected pulse points, all beating as planned in unison or alternation in a pattern that repeats each hour, is a thing of beauty if you can visualize it, especially because if the motion of pulsing suggests the movement of blood through the heart.  It's like watching the inner life a large multi-hearted organism, and this can be a nice metaphor for other kinds of thinking about your city.

Illustrators!  Can you think of how to do better black-and-white illustrations of the ideas in this post, as part of this challenge?  If so, go for it!

¹ Ross R. Maxwell, "Converting a Large Region to a Pulsed-Hub Public Transport Network."  Transportation Research Record, paper 03-4020, p 128.  Original paper here.  

beyond "on-time performance"

A San Francisco reporter emailed me yesterday with this question, regarding the city's main transit system, Muni:

As you know, Muni set a goal in 1999 when the [San Francisco Municipal Transportation Agency] board was formed, to have a 85 percent on-time performance standard. That was voted on in 1999 (Prop. E). Since then ... the agency has yet to the meet goal or even gotten close to it. The highest it's been was 75 percent a few months ago.  ... I wanted to ask if you if there is any danger for Muni to be so focused on this one standard? Are performance metrics evolving and why are they evolving? What else should Muni to be looking at as far as improving reliability?

I have a great deal of sympathy for transit executives trying to deal with on-time performance, because many of the causes of delay are outside a transit agency's control.  Still, there are two problems with the measures of "on-time performance" that prevail in the industry.  (Note:  San Francisco's transit agency does understand these issues, but your transit agency may not.)

1.  They are not customer-centered.  A standard on-time perormance measure shows percentage of services that were on-time, not the percentage of riders who were.  Because crowded services are more likely to be delayed, the percentage of customers who were served on-time is probably lower than the announced on-time performance figure.  An on-time performance figure weighted by ridership would give a clearer impression of the actual customer experience.  For more on this problem, see here.

2.  For high-frequency, high-volume services, actual frequency matters more.  Suppose that a transit line is supposed to run every 10 minutes, but every trip on the line is exactly 10 minutes late.  A typical on-time performance metric (e.g. the percentage of trips that are 0-5 minutes late) will declare this situation to be total failure, 0% on-time performance.  But to the customer, this situation is perfection. 

For this reason, some big-city transit agencies use a "headway-maintenance" system, in which a transit operator's job is not to run on time, but rather to run a specified number of minutes after the preceding vehicle on the line.  What should be reported in this case is not the time a bus came, but the actual elapsed time between consecutive trips.   GPS based real-time location systems, which are becoming common, provide the information needed to do this.  More on this here.

It's worth noting that these two objections to standard on-time performance probably push the reported rate in opposite directions.  An on-time performance measure weighted by ridership (responding to my point #1) would almost certainly yield a lower score.  But on high-frequency services (my point #2) I suspect that many services now being counted as late don't seem that way to the passenger.  If the trip ahead was late as well, then the actual gap between trips -- which is all that a customer notices on high-frequency service -- may be more or less fine.  So a shift to headway maintenance might yield numbers that tell a more positive story about the actual customer experience.  In any case, once the transit agency is clearly doing what it can to optimize reliability, the case for other improvements -- such as stronger transit priorities -- will be far stronger.

Changing these metrics is hard.  There's a lot of room for debate about exactly how to calculate a revised measure, and that's the easy part.  Headway maintenance, in particular, means changing job expectations and management practices.  It can affect how drivers are judged, so the unions may have a role.  All this takes a lot of courage and persistence, so it's understandable that many agencies aren't ready to do it.  Some agencies are thinking about the issue but are not ready to act. 

The hardest part may be explaining to the public that the previous measures weren't so good, because someone will ask: "If that's true, why have you used the imperfect measure for so long?"  Fortunately, there's a good answer to that:  the quality of data.  GPS vehicle location systems have become routine in big North American systems only in the past decade, while new "smart card" ticketing technologies -- which can pinpoint ridership by time and location -- are  just now coming on.  Once their bugs are worked out, these systems will provide robust data that was never there before.  Transit managers can say, truthfully, that they've always understood the problem with on-time performance but never had the tools to monitor a more nuanced and accurate indicator.  But now they do, or they will soon. 

So perhaps now is the time to update the idea of "on-time performance," and the ways that agencies pursue it, to achieve a better focus on what matters to the customer.

the perils of succeeding "on average"

Two recent comments on different topics got me thinking about averages, and why people like to talk about them more than they like hearing about them.

Toronto transit expert Steve Munro made this comment on the familiar perils of transit operations in that city:

In Toronto, the TTC reports that routes have average loads on vehicles, and that these fit within standards, without disclosing the range of values, or even attempting any estimate of the latent demand the route is not handling because of undependable service.  Service actually has been cut on routes where the "averages" look just fine, but the quality of service on the street is terrible.  Some of the planning staff understand that extra capacity can be provided by running properly spaced and managed service, but a cultural divide between planning and operations gets in the way.

When it comes to on-time performance, everyone understands that the average isn't a useful concept.  If your buses are ten minutes early half the time and ten minutes late the other half, then you could say that on average they're right on time.  We're all smart enough not to fall for that.

But it's still common to hear reporting of average load, as Steve mentions.  Average load is the total number of passengers through a point divided by the number of buses/trains that carried them.  It has some uses in transit planning as a way of talking about ridership patterns, but it's not a good way of describing the customer experience.  To do that, you'd have to look at how often you have incidents that the customer will hate, such as crush-loading and worse yet, passing customers at stops for lack of room.  That's how we talk about on-time performance: percentage of trips that are more than 5 minutes late.  So you should also be reporting the percentage of trips that are crush-loaded or begin passing up customers.  (How do you count passed-up customers?  A good question for another post.)

Now obviously, if you want to describe how your system looks to your customers, you should also weigh those measurements of overloading by the number of people who experience them, just as one might expect agencies to do for lateness. If your statistics aren't weighted that way, then again: you may be describing your operations but you're not describing your customer experience. 

Recently, commenter Calwatch mentioned a similar scourge, the bizarre but commonplace notion of "average frequency," which sometimes undermines the urgent work of frequent network mapping:

[Los Angeles County MTA]'s "12 minute map" is better described as a "5 buses an hour on this street" map, as the current map now has a disclaimer stating that Rapid and local service frequencies are combined to show frequencies. So you may have a Rapid bus running every 20 minutes and a local bus running every half hour, but since it's five buses an hour, it can be shown on the 12 minute map.

I'm not sure Calwatch is right about this.  Here's the exact disclaimer from the Los Angeles MTA map:

The bus routes on this map run at least every 12 minutes on weekdays throughout the day.  Where Metro Rapid and Metro Local lines run together, service is available every 12 minutes or better at Metro Rapid stops. At intermediate local stops, service may operate less frequently.

I can understand that as meaning "The Metro Rapid really does run every 12 minutes, and if there are underlying locals, those locals may be less frequent."  That would be fair, though it raises the question: So why are the less-frequent locals shown on the map?

But Calwatch claims that when they say "every 12 minutes" they merely mean "five buses per hour."  If that's true, and I haven't verified it, then they would be guilty of implicit averaging.  Five buses an hour could mean five buses bunched at the same time each hour, with hour-long gaps between them.  And yes, you could say that on average, that's a bus every 12 minutes! 

So remember:

Nobody cares about average frequency, any more than they care about average lateness or average crowding!

The question customers ask is "what is the worst case I'll typically experience?"  And when an agency says the buses come "every 12 minutes" this customer is going to hear "OK.  I'll never wait longer than 12 minutes."  Is that customer going to get burned by trusting the 12-minute map?  I'm sure Los Angeles commenters will fill us in.  A comment from someone at the agency would be even more helpful.

I've had this conversation with transit agency staffs when doing jobs that required me to map the frequency of the existing system.  More than once, I've asked for frequency data and been given data on "scheduled trips per hour."  I've had to go back and say:  Frequency is about maximum waiting time.  By its very nature, it's a maximum, not an average!  So tell me the maximum, worst-case scheduled gap between consecutive trips!  

So when you hear the word "average" in an agency's statements, or even if you see an implicit average like "five trips per hour," ask yourself:  Is the average what I care about as a customer?

if on-time performance is 96%, why am I always late?

A New York Times article today highlights the perennial misunderstanding embedded in how transit agencies typically measure on-time performance. 

By official accounts, 2009 was a banner year for the commuter railroads that serve New York City. Of all the trains that ran last year, the railroads said, nearly 96 percent were on time — one of the best performances since they began keeping records.

But the reality, as nearly any rider would tell you, can be considerably different, and vastly more frustrating.

On weekday mornings, 1 in 10 trains entering Pennsylvania Station arrived late, two-thirds by 10 minutes or more. At the peak of the rush, from 8:30 to 9:30 a.m., about 25 percent of New Jersey Transit trains entering Manhattan arrived late; about 2 in 5 of the late trains were tardy by at least 15 minutes.

The explanation, of course, is that peak hour commuter trains are most likely to be late, because they run when the system has the least margin for error.  And since most riders of commuter rail are on the peak, most riders experience the system at its least reliable. 

In short, 96% on-time performance doesn't mean that 96% of customers get where they're going on time -- only that 96% of trains did, counting nearly empty trains at 10:00 PM when there's plenty of spare capacity on the rails, and a lot fewer causes of delay.

It would not be hard, of course, to calcuate and publicize the actual on-time performance for customers.  Just multiply each train's performance by its ridership.  The result, of course, would be a much lower number, but one that would give you a better indication of the odds that you'll be delayed when you use a service.

now, anyone can monitor reliability

Can you think of a better way to measure service reliability than the ones your transit agencies use?  Can you develop ways to analyze the system's performance that will reveal more precisely where and why things go wrong?  Now, any transit geek with a head for statistics can try out these ideas, and share what they discover, for any transit agency that publishes a real-time information feed.

San Francisco's Muni was one of the first transit agencies to make all of its realtime information public.  NextBus uses this data to drive its real-time information displays in shelters, and on its website.  But these systems also have a terrific by-product: they generate a historical record of where every bus and train was, at every minute, on every day.  The sheer mass of information makes it possible to aggregate many days' data so that the noise of random disruptions falls away and you can see the pervasive, routine ways in which the system may be failing (or succeeding!)

Prompted by an earlier post of mine, reader Tung Way Yip took a shot (temporary link).  Here, he assesses a basic metric that he calls "average arrival."  As I understand this, he's assessing the likelihood that you will actually wait a given number of minutes.  The Y-axis is the percentage of cases in which each x-value as observed. 

For a high-frequency route, this analysis is far, far more relevant to customer experience than the on-time performance metrics that most transit agencies use.  On-time performance -- the difference between a trip's scheduled arrival time and its actual time -- is easy to measure.  But once a line is running better than every 10 minutes, no customer is waiting specifically for the 5:32 as opposed to the 5:35 trip, so the on-time performance of that trip doesn't matter.  What matters to the customer is the actual waiting time.  That's what Mr. Tung is measuring here, and it's an analysis that others could take a lot further. 

For a simple model of why this matters, imagine that you have a bus line running every 10 minutes, and every single bus is exactly 10 minutes late.  From the standpoint of a classic on-time performance measure (which typically counts the percentage of trips that are more than five minutes late) this situation would be described as 100% failure, because 100% of all trips are late.  From the customer's standpoint, on the other hand, this would be perfection: buses are coming every 10 minutes, exactly as promised.  Much more about this conundrum, and the choices it requires us to confront, here.

Meanwhile, I encourage other transit geeks to dig into real-time performance data, and especially to aggregate the data for many non-holiday weekdays to smooth out the random accidents and see the more pervasive patterns.  Forget whether some lines are more on time than others.  For frequent service, the interesting question is how long the actual gaps between consecutive buses are.  Perhaps agencies (or failing that, local transit blogs) should publish line-by-line data about the reliability of waiting times.  A statistician would describe the result as the standard deviation of headway, but you could put it in more user-friendly terms:  For a particular line, at a particular stop, you could present the probability that you will wait, say, 10% longer than the ideal average wait.  (The universe of data points would be made up of all the minutes of a day, or other analysis period, and the observed actual waiting time for someone who arrived at the stop at that minute.) 

For example, if a line runs every 10 minutes, that means your wait should be an average of 5 min and a maximum of 10.  So what percentage of the time will you actually wait more than 10?  What percentage of the time will you actually wait more than 15?  20?  These simple curves could help people know which transit lines, or parts of lines, they can really count on.  This could be really useful information if you want to make a decision on whether to live on this line, or to buy a vehicle if you do.

For wider appeal, you could also make a map of the data, perhaps in the Eric Fischer style.  Before long, you'd know as much about your transit system's operations as its operators do, and be able to make really focused, quantitative comments based on incontrovertible data.  Your transit agency may initially react defensively if you do this, but in the end, you'll be doing them a favor. 

transit advertising and transit self-esteem

This Air New Zealand ad, on a bus shelter in Sydney, raises the issue of transit self-esteem.   "$100 says the bus won't be late," it says, then, in much smaller print: "Looks like you win."  

Should transit agencies accept advertising that demeans their service? 

Advertisers are often tempted to do exactly that, especially when selling vacations or other forms of escape from the everyday.  The bus is both a profitable site of advertising and an irresistible metaphor for the tedious life.  If you imagine your transport mode as a romantic partner, the bus in mixed traffic is the worst of both worlds: neither sexy nor capable of commitment.  When advertising on a bus, it's not surprising that advertisers find ways to play on that.

But why should a transit agency conspire in putting out this message?  When was the last time you opened an airline magazine and saw an advertisement referring to hijackings or plane crashes, or even to chronic delays?  It doesn't happen.  Private companies who advertise other companies don't accept advertising that's demeaning to themselves, or that counters their own marketing message.  Why should transit agencies do it?

There are of course many legal and procedural reasons why these ads exist.  Often, the decisions about what ads to accept are outsourced.  In the case of shelters, the transit agency may not control the advertising contract.  And there are often laws about discrimination in accepting advertising that make it hard to make these calls.  Yet these can certainly look like an expression of low self-esteem on the part of the transit system.  What would it really cost, in advertising revenue, for transit systems to show the same self-respect that airlines do?

UPDATE:  Todd Edelman has a Flickr page devoted to similar "self-harming" transit advertisements from around the world.

if your bus is late, should the agency pay?

An engineering professor in Montréal got his transit agency to pay for his taxi fare because his bus didn't show up.  Unfortunately, it look many days of his time in small-claims litigation, so his trophy, a $40 check from the agency, should probably be framed rather than cashed.

Now and then a transit agency tries some kind of "on time or we pay" guarantee.  In the Montréal suburb of Laval, for example, the buses are equipped with Global Positioning System (GPS) technology, and the deal is that if your bus is more than five minutes late (a fact that the agency can verify via GPS), you can demand a free bus ticket, which is nice but not much of an incentive for the agency.  It seems to me the same GPS-driven approach could be used to implement a policy if "when we're more than x minutes late, we stop collecting fares."  That would actually help a late bus get back on time, because fare transactions are so time consuming.

There are excellent reasons not to do this, of course, or to do something more subtle.  For one thing, lateness has so many causes beyond the agency's control that it could cause substantial unavoidable payouts that would ultimately come at the cost of service. 

For very frequent urban routes, a better GPS-driven scheme would be based on actual headway (time between consecutive trips, i.e. maximum wait time) rather than timetable, for reasons I discussed here.  You could stop collecting fares on any bus that is more than __ minutes behind the one ahead of it.  I'd suggest x be something like 3 times the published headway or ten minutes, whichever is less.

Still, we'd have to remember that the lost revenue, if substantial, would come out of service, sooner or later.

I'm curious if any readers have encountered an effective one.  By effective I mean one that actually helps motivate good system performance, rather than just shifting scarce funds from service into claims.

(From Montréal Gazette via Montréalités Urbaines)

mundane things that really matter: defining "on time"

A great piece by Michael Perkins in Greater Greater Washington highlights a perennial problem with on-time performance measures for urban buses.  He cites the policy of the Washington area transit agency, WMATA, which says that a bus is considered on-time if it's no more than two minutes early and no more than seven minutes late.  Perkins explains, with diagrams, that under this policy you could wait 19 minutes for a bus that supposedly ran every ten minutes, and yet the bus (and the one 19 minutes in front of it) would both be considered on-time.

(By the way, the WMATA standard sounds lax to me, though I haven't done a survey.   Few agencies I've worked with accept anything more than five minutes late, or one minute early.)