Posts by Matt Caywood

A transit screen layout on an iPad.

I've organized a Transit Screens Hack Day on Saturday, November 10. Bring your computer, and everyone who participates will go home with a personal transit screen.

You can run it on any web browser. If you have a tablet, either Android or iPad, bring it and we'll help you get it running on your tablet too.

After your screen is set up, join us in hacking to make it better meet your needs. What about adding Car2Go support? A bus arrival notifier? Weather information? More transit agencies? Improved support for individual users? A mobile version? If you're a web designer, what about adding more flexibility to the interface? Improving the display and layout of the screen? I've put some suggestions on a bug tracker, but we want your ideas too.

If you can code in PHP, you can check out the code now. If you know Python or web design, you'll have a chance to put those skills to work too. If you mostly code in other languages, like I do, it's not a problem—we'll help you get started. And if you can't code yet, you can help us debug, design and document.

The Hack Day will run from 11 am to 5 pm on Saturday, November 10 at 1501 Wilson Boulevard, Suite 1100, in Rosslyn. It's 2 blocks up from the Rosslyn Metro and just across the bridge from Georgetown. Please register here.

The fundamental problem is that quality bus shelters are not cheap. Standard shelters cost approximately $7,000, and a lighted shelter with an electrical connection can run $60,000 or more. Compliance with the guidelines of the Americans with Disabilities Act can have the perverse effect of pricing improvements out of reach. Sometimes, compliance is physically impossible as many bus stop sites lack the required space for improvements that are ADA-compliant. In a bind, governments often opt to provide no seating at all.

Comfortable seats on the cheap

A solution to this seating problem has emerged at 10 bus stops along major thoroughfares in Arlington and Falls Church. A local resident and his helpers have been adding simple, comfortable chairs to previously bare bus stops. Taking photos, they have documented the use of these seats over time, confirming a latent need for dignified seating at the region's bus stops.

These guerrilla do-gooders scavenged on trash nights for durable and comfortable plastic lawn chairs. They modified the chairs with a drill to include holes in the seat for improved rain drainage, and a leg mounting point for a security chain.

Based on the number of bus riders they observed waiting and the availability of suitable space on the sidewalk or grass strip, this cadre identified optimal locations for the ad-hoc seating.

With used bike chains (also scavenged) and a chain tool, they secured chairs to bus stop poles within the public right of way, largely safe from tampering or vandalism.

Searching for "appropriate technology"

Ironically, in our industrialized, high-tech nation, these locals have followed an approach that harkens to strategies applied in developing countries. The principle of "appropriate technology" is characterized by grassroots, sustainable, lower-cost, lower-tech solutions to basic human needs—technology such as these chairs.

Still, Americans may yet find applications for the same lower-cost, lower-tech principles. Decades of underinvestment in public space and infrastructure have left a backlog of needs. Inflexible regulations and funding mechanisms sometimes discourage immediate solutions in favor of waiting for rare moments when large infrastructure investments can be made at once.

At a time when many House Republicans urge an end to all federal support of transit, it's unlikely we'll see large infusions of funds to support this old strategy. Our governments and our communities need to start making small, incremental improvements, with more appropriate technologies that can be adequately maintained.

Saving on seating

For many older riders, or those with disabilities, standing can be a significant enough imposition to drive them away from using the bus. If bus stops are more comfortable to wait at, some of these neighbors might be able to use convenient buses more often, and others might be able to choose buses over more costly paratransit vans.

Arlington has already begun an "adopt-a-stop" program to maintain public bus stops. Perhaps other residents there (or elsewhere) will be inspired to provide the low-cost "appropriate technology" seating solutions that government currently cannot.

After all, in just a few months, a group of engaged residents was able to provide a public accommodation useful to hundreds of people. All it cost them was their time and a few dollars of gas money.

Currently, Capital Bikeshare's stations and kiosks serve the following functions:

1. Unlock in response to member keys and credit cards
   
2. Provide a secure locking point to deter theft
   
3. Transmit usage and billing information
   
4. Identify a known place to find bikes (by users or the bike sharing agency)
   
5. Advertise for the system (and other commercial sponsors)
   
6. Less commonly used functions, such as reporting malfunctions and extending reservations when dockblocked
   

Instead of putting these features in the station kiosks, they could all become part of the bikes themselves. The SoBi (Social Bicycles) system pictured above shows how this could work. A box attached to the bicycle contains a lock, a GPS, and wireless communication with a central computer. It unlocks in response to a rider's mobile phone or PIN code. When a rider reaches a destination, he or she locks the bike, and the station notifies the central computer.

It's easy to envision other potential features, such as a credit card reader for tourist use, or a button for reporting malfunctions. The box is solar-powered, like Capital Bikeshare stations, but could also be pedal powered.

The first system to use smart shared bikes like this is Call a Bike, still widely used in German cities, including Berlin, Frankfurt, and Munich. As its name implies, a user must phone before each trip for a bike's unlocking code, then after each trip, phone again with the bike's cross street to confirm return.

However, without designated stations or accurate location information, it can be inconvenient to find a bike, and the system does not encourage use by tourists. The weBike system at the University of Maryland uses text messaging instead of phoning, but also requires bikes to be returned to fixed docks.

Currently, two "next generation" bike sharing systems in the US are going further by putting all the intelligence in the bike. These systems are viaCycle, currently operating at a small scale at Georgia Tech in Atlanta, and Social Bicycles, a startup in New York.

In each of these systems, vehicles themselves communicate their locations to a central server, and users can find them using a website or mobile apps. A user unlocks a bike using his or her mobile phone and can then lock it anywhere.

These systems are analogous to the car2go car sharing system, in which cars don't have designated spaces and can be parked in any legal street location.

Smart bike systems promise a significant cost savings versus current generation systems with docks and kiosks. Adding 12 docks to an existing station costs about $13,000, while a new 12-dock station with a kiosk costs about $36,000. This cost difference is leading DDOT to expand many stations instead of adding new ones in between, where they'd be more useful but also more costly.

Social Bicycles founder Ryan Rzepecki claims that 2-4 times more smart bikes could be deployed for the same cost as current generation kiosk systems. Bike racks could also go almost anywhere, without the linear space and solar requirements of current docks.

Flexibility has advantages and disadvantages

Smart bike systems largely solve the dockblocking problem at full stations because users can lock their bike at any safe location, not just at docks.

But is it really a good idea to be able to dock bikes anywhere? It would be difficult to prevent some people from abusing the privilege, such as locking bikes in inaccessible locations (e.g., garages, courtyards, and behind security barriers). Additionally, bikes might accumulate in remote or infrequently used locations, as some have reported happening with car2go. Theft and vandalism could also become a problem; Capital Bikeshare has relatively low loss rates, thanks in part to its sturdy docks in well-traveled locations.

In addition, smart bikes do not solve the problem of empty stations, and can even add difficulty to the process of finding a bike. Bike sharing members often plan around expecting to find a certain number of bikes at a station because it makes for a convenient routine, or because they need several bikes at once for a group trip. A more flexible system would create more uncertainty and make users more reliant on smartphones, which are not available to everyone.

In fact, DDOT officials have cited predictability as a major reason they are enlarging stations: users find it particularly frustrating to find an empty or full station, so they would rather have fewer stations that are more often usable than more conveniently located, closely-spaced stations.

To make bike locations more predictable, Social Bicycles has proposed a "virtual station" concept, in which a station is just a geographic area on a map. Bikes could incur higher fees depending on how far riders park them from a virtual station. This solution gives users the flexibility to park anywhere, but ensures that most bikes will return to designated stations.

Would we use this here?

Several jurisdictions in our region are considering their own bike sharing systems. Some, fairly distant from DC and Arlington, primarily expect users to take short trips inside their systems instead of trips to and from the core.

There are many reasons for jurisdictions to join the current Capital Bikeshare network, like savings from economies of scale, and the convenience for users being able to get a bike anywhere within the network. However, systems less reliant on docks could be more cost-effective in lower-density suburban areas, where stations will be smaller and the cost of station kiosks will be a large fraction of the total budget.

Meanwhile, Capital Bikeshare is a huge success with its current, proven technology. Already, its stations are far cheaper to install and move than its predecessor system, SmartBike. Capital Bikeshare shouldn't change just as it's hitting its stride. In time, we might even see it transition toward technologies that further reduce the burden of stations.

25 trips around downtown DC

The analysis

I picked 25 random station pairs in downtown DC (1 mile radius around Metro Center, shown above) for this study. For each origin-destination pair, the Capital Bikeshare trip data gave me a large number of bicycle trip time measurements, but I needed to know how long the trip would take by other modes like car, transit or walking.

Since no data sets exist for those modes, I used Google Maps' time estimates as a proxy. A comparison of Google's bike trip time predictions with real data from Capital Bikeshare riders returned a strong correlation (r = 0.93), confirming that Google's estimates are probably a sufficiently accurate replacement.

For Capital Bikeshare trip data, I started with the data set cleaned up by Corey Holman. The data set contains over 1.3 million trips over a period of about 14 months.

But one major issue remained. I needed to make sure the data measured the direct trip time between a pair of stations. While most Capital Bikeshare trips are frequent riders going directly from one station to another, some trips are tourists taking a long leisure ride that just happens to start and end at these stations. Since I was only interested in direct trips, I only considered trips taken by registered users.

The graph below illustrates a sample station pair. You can see that registered users (in red) have a very different pattern of trip times than casual users (in purple). Registered users take trips of slightly different durations depending on their speed and exact route, but they seem to be going fairly directly from point to point, as their trip times follow a normal distribution with a long right tail. Casual users' trip durations are wildly different and don't follow as clear a pattern.

Histogram showing the distribution of all trip times from 19th & Constitution to 19th & L.

In the diagram above, the black tire track shows driving time while the green line shows bike time from Google. The stacked bars show Capital Bikeshare trip times for registered (red) and casual (purple) users. The peaked distribution between 6-12 minutes reflects direct trips, and the longer trips reflect leisure rides. The pink dot shows the trip time of the fastest 10% rider; the red dot shows the median rider.

The results

The final results are shown in the figure below. The fastest 10% of riders, traveling at 10 miles per hour, were faster than a car trip with parking time added in every trip studied—100%.

While an average rider on a bike, traveling nearly 8 miles per hour, will rarely beat a direct car trip without traffic or parking over the same distance, the fastest riders have a decent shot. When bike trips are compared to a direct car trip (like being chauffeured), the median rider was faster in 4% of trips studied. The fastest 10% of riders were still faster in 24% of trips. But in the real world, where cars have to find parking, bicyclists win big, whether they're fast riders or average ones.

Percentage of trips where biking is faster, depending on a Bikeshare user's speed. The graph on the left assumes direct car trips, the graph on the right assumes 5 minutes of parking time.

To be sure, these comparisons are not perfect. Both driving and cycling times have caveats.

For driving times, Google Maps no longer considers traffic delays in their trip time calculations, but rush hour gridlock in downtown DC will add huge delays to car trips, when bikes can zip through. In the bike trip data, I could help compensate for daily variation in weather and traffic by randomly selecting only one of several trips per day between a pair of stations, but this was not possible for driving times.

Second, even assuming 5 minutes of parking time is charitable to drivers. Donald Shoup reports (PDF) an average of 8 minutes of time spent cruising for parking, in multiple studies from multiple cities. That doesn't even include the time spent paying a meter or getting out of a garage.

These travel times only count trips from one Capital Bikeshare station to another station, not the walking times to and from Capital Bikeshare stations. Therefore, they most closely reflect the times for people bicycling on their own bikes. Trips using Capital Bikeshare take a few extra minutes. While some people are lucky enough to be located very close to a CaBi station, most of us have to walk a couple of minutes to the nearest station.

A more sophisticated study could use arbitrary trips on the downtown grid to estimate the extra walking time for Capital Bikeshare trips, and better estimate the time Washington drivers actually spend in traffic and parking.

Despite these caveats, my results are not anomalous. A related study in Lyon, France, agrees that shared bikes were faster than cars in the central city.

That study used precise trip distance information from a "counter on the bike," which unfortunately isn't possible with Capital Bikeshare. They also inferred that bicyclists were taking unapproved shortcuts through the city center, but our data shows that even in downtown DC, with few shortcuts, shared bikes are still highly efficient.

I would have liked to study every single pair of Capital Bikeshare stations, but was limited by the tedious task of getting trip times from Google Transit. Since I was primarily interested in testing the effectiveness of bicycling around the city's downtown core, where it has the best potential to overcome traffic, that was where I focused.

It would not be surprising if bicycling were equally effective in other dense neighborhoods such as Dupont, Logan, Shaw, Adams Morgan, or Capitol Hill, but I have not tested this. Some trips, like Anacostia to Arlington, may not be very efficient by bicycling because routes are lacking, though bikes often perform well in commuter competitions like last year's in Reston.

If you're interested in another set of trips or cluster of stations, we could set up a collaborative spreadsheet with instructions for collecting the numbers needed. Let me know in comments below, or send me an email. And if you're interested in working with Capital Bikeshare data or software, please join us at the new developer forum.

In the DC region, travelers often can choose among many transit routes and modes. To help travelers, maps and apps display a variety of information, like the routes in a geographically accurate or diagram form, vehicle arrival times or positions, and more.

It would be extremely useful to transit users, transit agencies, and app designers to understand exactly what displayed information is really helping travelers make better choices. Fortunately, Hartwig Hochmair, now a professor at the University of Florida, designed a clever web experiment (PDF) that helps answer this very question.

For simplicity, let's assume that travelers want to find the fastest route. Not all do; some prefer a trip where they can get a seat, or prefer the smooth ride of rails over a bus. But many do want to minimize overall travel time.

However, it's not always simple to figure out the fastest route. Maps can't contain all the information to decide this perfectly, and the rider usually has limited time to make a choice. So travelers quickly pick a subset of information, one of several "proxy variables," and use it to choose a route, such as:

• Shortest total distance
  
• Fewest number of stops traveled
  
• Most linear route, heading straight toward the destination
  
• Fewest transfers, for less total waiting time
  
• Most transfer options at each station, allowing a switch to the first train in the direction of the destination

Do people choose different proxy criteria depending on how a map displays the information? Hochmair asked experiment participants to plan trips on the metro system in Vienna, Austria. That system has many interconnected lines, giving riders many choices among complex routes.

The geographic map of the Vienna U- and S-Bahn used in the experiment.

Hochmair's participants saw 5 different displays:

• A geographically accurate map
  
• A diagrammatic map based on the official map
  
• A map showing the real-time positions of vehicles
  
• A map with service frequencies, showing the time between arrivals per line
  
• A map showing the next departure time for all lines from the starting point

He tested 35 people with varying levels of Vienna metro experience by giving them 40 route-finding problems apiece. Based on the routes chosen, he was able to use a statistical model to conclude that while people used distance information in every map, the different maps also caused people to use different proxy criteria for planning their route:

• The geographically accurate map led people to pay attention to the number of stops traveled.
  
• The diagrammatic map, and the map showing next departures, led people to pay more attention to the total number of transfers.
  
• The map showing service frequencies caused people to pay more attention to the number of transfer options at each stop.

Which of these maps is the best to help people minimize travel time? For the complex trips in Hochmair's study, inexperienced users benefited most from having service frequencies. Meanwhile, for experienced users, service frequencies also turned out to be best, with vehicle positions second.

The study still concludes that a map with real-time information is better than a plain map. But the usefulness of real-time information decreases as the number of transfers increases, because a traveler doesn't know exactly when they will arrive at each transfer point. For trips with more transfers, most travelers would be better off following a route where service is most frequent.

Most transit maps do not contain this information. Bus maps like WMATA's standard map (PDF), for instance, show every line the same size and weight whether it runs once an hour or every 3-5 minutes. WMATA's planning department did put together a map of routes with buses more frequent than 4 times per hour, and the agency should actively promote this clear and helpful tool.

Central DC section of 15-minute Metrobus map. Click for full map. Image from WMATA.

A final lesson of this study is that, between different traveler preferences and the different ways travelers use information, agencies and app designers must keep the needs of different users in mind. But all can take fairly low-cost steps to help riders by making service frequency information more prominent.