November 30, 2012

GTFS-realtime for WMATA buses


Dragging #WMATA‘s #opendata into the 21st century, kicking and screaming: #GTFSrealtime for bus arrivals, alerts http://t.co/VqrFMR9E
November 17, 2012 5:55 pm via TweetDeckReplyRetweetFavorite
@kurtraschke
Kurt Raschke

I’ve posted many times about the considerable value of open standards for real-time transit data. While it’s always best if a transit authority offers its own feeds using open standards like GTFS-realtime or SIRI, converting available real-time data from a proprietary API into an open format still gets the job done. After a few months of kicking the problem around, I’ve finally written a tool to produce GTFS-realtime StopTimeUpdate, VehiclePosition, and Alert messages for Metrobus, as well as GTFS-realtime Alert messages for Metrorail.

The tool, wmata-gtfsrealtime, isn’t nearly as straightforward as it might be, because while the WMATA API appears to provide all of the information you’d need to create a GTFS-realtime feed, you’ll quickly discover that the route, stop, and trip identifiers returned by the API bear no relation to those used in WMATA’s GTFS feed.

One of the basic tenets of GTFS-realtime is that it is designed to directly integrate with GTFS, and for that reason identifiers must be shared across GTFS and GTFS-realtime feeds.

In WMATA’s case, this means that it is necessary to first map routes in the API to their counterparts in the GTFS feed, and then, for each vehicle, map its trip to the corresponding trip in the GTFS feed. This is done by querying a OneBusAway TransitDataService (via Hessian remoting) for active trips for the mapped route, then finding the active trip which most closely matches the vehicle’s trip.

Matching is done by constructing a metric space in which the distance between a stoptime in the API data and its counterpart in the GTFS feed is defined as an (x, y, t) tuple—that is, our notion of “distance” becomes distance in both space and time. The distances fed into the metric are actually halved, in order to bias the scores towards matching based on time, while allowing some leeway for stops which are wrongly located in either the GTFS or real-time data.

The resulting algorithm will map all but one or two of the 900-odd vehicles on the road during peak hours. Spot-checking arrivals for stops in OneBusAway against arrivals for the same stop in NextBus shows relatively good agreement; of course, considering that NextBus is a “black box”, unexplained variances in NextBus arrival times are to be expected.

You may wonder why we can’t provide better data for Metrorail; the answer is simple: the API is deficient. As I’ve previously discussed, the rail API only provides the same data you get from looking at the PIDS in stations. Unfortunately, that’s not what we need to produce a GTFS-realtime feed. At a minimum, we would need to be able to get a list of all revenue trains in the system, including their current schedule deviation, and a trip ID which would either match a trip ID in the GTFS feed, or be something we could easily map to a trip ID in the GTFS feed.

This isn’t how it’s supposed to be. Look at this diagram, then, for a reality check, look at this one (both are from a presentation by Jamey Harvey, WMATA’s former Enterprise Architect). WMATA’s data management practices are, to say the least, sorely lacking. For most data, there’s no single source of truth. The problem is particularly acute for bus stops; one database might have the stop in one location and identified with one ID, while another database might have the same physical stop identified with a different number, and coordinates that place it in an entirely different location.

Better data management practices would make it easier for developers to develop innovative applications which increase the usability of transit services, and, ultimately improve mobility for the entire region. Isn’t that what it’s supposed to be about, at the end of the day?

Comments Off

Filed under Articles

Tagged as , , , , , ,

September 11, 2012

Wireless for WMATA: what’s at stake?

Since late 2008, the Washington Metropolitan Area Transit Authority has been working to deliver modern wireless service throughout the underground portions of the Metrorail system. Unlike some mass transit systems, however, WMATA did not undertake this project simply out of a desire to improve passenger experience; they did so because of a few short sentences in the Passenger Rail Investment and Improvement Act of 2008 (hereinafter PRIIA), enacted on October 16, 2008:

No amounts may be provided to the Transit Authority pursuant to the authorization under this section unless the Transit Authority ensures that customers of the rail service of the Transit Authority have access within the rail system to services provided by any licensed wireless provider that notifies the Transit Authority (in accordance with such procedures as the Transit Authority may adopt) of its intent to offer service to the public, in accordance with the following timetable:
(A) Not later than 1 year after the date of the enactment of this Act, in the 20 underground rail station platforms with the highest volume of passenger traffic.
(B) Not later than 4 years after such date, throughout the rail system.

WMATA met the first deadline, turning up a new distributed antenna system and signing on the four major carriers (AT&T, Sprint, T-Mobile, and Verizon). But the second deadline has proved thornier. A recent Washington Examiner article described the contractor installing the system as being in “dire financial straits”. Anecdotal reports from riders have shown that cellular service has been spotty, even at stations which initially had good coverage.

With October 16 just over a month away, you might think that WMATA would be forthcoming with status updates. Unfortunately, WMATA has responded to the situation with its usual opacity:

@ Wish I could give you more but everyone is mum. Here's the latest on what I know: http://t.co/BunIqCjX
September 10, 2012 4:07 pm via webReplyRetweetFavorite
@kytja
kytja weir

So, what does WMATA stand to lose if they miss the deadline? As PRIIA states, “[no] amounts may be provided…”, and the amounts authorized under the Act are considerable:

There are authorized to be appropriated to the Secretary of Transportation for grants under this section an aggregate amount not to exceed $1,500,000,000 to be available in increments over 10 fiscal years beginning in fiscal year 2009, or until expended.

Clearly, this is not a deadline that WMATA should take lightly.

The Massachusetts Bay Transportation Authority, like WMATA, is in the midst of wiring its rail system for wireless service, and they, too, have experienced delays. However, they’ve been more upfront about the situation; an article published earlier this year distinguished between delays attributable to the MBTA’s contractor and those attributable to the cellular carriers.

Even if WMATA and their contractor manage to pull through and meet PRIIA’s October 16 deadline, there are still best practices they can and should adopt. In New York City, the contractor deploying wireless service on the subway, aptly named Transit Wireless, has established their own presence, rather than lurking in the shadows like the contractors deploying systems in DC and Boston. Through their Web site and Twitter account, Transit Wireless reaches out directly to riders, taking questions and helping them understand what services are available, and where.

By contrast, WMATA refers questions to the carriers, who tend to either deny knowledge of service in the Metro, or refer questions back to WMATA. After WMATA’s initial announcement of service at underground stations, updates have been spotty at best—and there’s no list of covered stations or timetable for future service rollouts.

Comments Off

Filed under News

Tagged as , , , ,

July 5, 2012

When you travel, think intermodal!

Tonight’s episode of On The Fly featured a group of twelve passengers bound for Milwaukee who misconnected and ended up stranded in…well, airports all start to look alike after a while. Anyway, the best option they were given was a flight to Chicago Midway, whereupon all of the stranded passengers began to groan about rental cars and arranging to get picked up at the airport and things like that.

Next time you find yourself in that situation, think intermodal (because it might just save your trip)! Amtrak offers fast, frequent service from Chicago Union Station to Milwaukee—not just the intermodal station in downtown Milwaukee, but the airport, too! So, even if you’d parked your car at the airport in Milwaukee, Amtrak will get you right back where you started. A quick trip on the CTA Orange Line from Midway to Quincy, three blocks west to Union Station, hop on the Hiawatha Service, and you’re set! No car to rent, no traffic to get stuck in, and no friends to badger for a ride. Best of all, it’s probably cheaper than renting a car.

I’ve seen many people characterize cars as freedom and transit as some sort of straitjacket on rails—but here again transit is the fast, easy, inexpensive, and stress-free option. So, next time you travel, think out of the box, and think intermodal!

3 Comments

Filed under Articles

Tagged as ,

June 25, 2012

OneBusAway might be coming to Ride On, maybe?

Today on GitHub I came across this commit. I don’t quite know what’s going on, but it sure looks to me like someone at Greenhorne & O’Mara or Ride On has been experimenting with OneBusAway and Ride On’s data.

This is something in which I am keenly interested. But unlike in other cities, here there seems to be almost no interest in connecting transit agencies with each other and with local developers. There’s great value in doing both—connecting transit agencies together helps reduce duplicated effort and provide riders with harmonized, federated services. But even more importantly, connecting transit agencies with interested developers can provide transit riders with services that might have been cost-prohibitive or otherwise infeasible to for those agencies to develop in-house or through conventional procurement methods.

There are a lot of innovative developers out there, with lots of great ideas. It’s unreasonable to expect transit authorities to shoulder the risk of incubating all of those ideas, some of which might fail spectacularly, but it’s quite another thing for transit authorities to, on a best-effort basis, provide those developers with the data they need to bring their ideas to fruition.

I’d have thought that this would fall within the remit of the Mobility Lab, but more than a year after the launch of the Mobility Lab, that still hasn’t happened.

So, while there’s plenty going on, there’s not a whole lot of coordination, whether between agencies or between agencies and the community. Thus we have nearly a half-dozen real-time sign projects going on in the region—and who knows how much more duplicated work is being done, with everyone toiling behind closed doors!

Contrast that to New York City, where the MTA has been working—transparently—to develop MTA Bus Time, based on OneBusAway. When the agency began work on a GTFS-realtime feed for real-time subway arrivals from the IRT ATS system, once again, they turned to the community to get comments on the proposed specification. MTA developers are active on the agency’s mailing list to respond to questions and bug reports from developers.

In Portland, TriMet worked with OpenPlans to develop OpenTripPlanner, transparently, in full view of the community. OpenTripPlanner has proven to be a huge success, powering an first-of-its-kind regional, intermodal trip planner

Transit in the Washington, D.C. area isn’t all that different than in Portland or New York. Sure, the modes vary from city to city, and the Lexington Avenue Line by itself carries more passengers in one day than the Metrorail and Metrobus systems combined, but at its core, transit is transit. If it worked in New York, if it worked in Portland, it can work here.

This doesn’t have to be hard; in all seriousness, it takes about a minute to create a new Google Group.

When everyone works together, we can all help make transit better.

Comments Off

Filed under Articles

Tagged as , , , , ,

June 25, 2012

Bike sharing and bike rental should cooperate, not compete, on tourism

While in Boston recently, I came across the following advertisement for Urban AdvenTours, a bike shop in Boston, stuck to a Hubway station.

Aside from the unseemly nature of having public property (the Hubway station) subverted as advertising for a private company, I take issue with the general tone of the advertisement: that Hubway is “not cost effective for hassle free exploration”, that bike rental and Hubway are “recreation vs. transportation”, etc.

At the core of this is a simple question: can bike sharing services, like Hubway, be used effectively by tourists? Or are they indeed better served by full-service bike rental firms? I would argue that there isn’t a precise, clear-cut answer, but it’s not as one-sided as Urban AdvenTours makes it out to be.
Continue reading →

Comments Off

Filed under Commentary

Tagged as

June 6, 2012

Statement to the June 2012 WMATA RAC meeting

Earlier this evening, I delivered the following statement to the WMATA Riders’ Advisory Council during the public comment period of its June 2012 meeting:

As I hope you are aware, last week the NTSB released three reports into incidents on the Metrorail system, one of which resulted in the deaths of track workers Jeff Garrard and Sung Oh. I would hope that the RAC would request a presentation from WMATA on steps taken to improve safety in the wake of these accidents. Even more importantly, though, I would hope that the RAC would ask WMATA to publicly release documents to permit independent verification and oversight of the Authority’s claims on safety.

I understand that the RAC is not accustomed to conducting investigations, but for Jeff Garrard, Sung Oh, their colleagues, and the 1.5 million individuals who use Metro ever day, I ask you to consider the vital importance of holding WMATA accountable on such a serious issue as safety.

For reference, the NTSB reports mentioned above are the following:

  • RAB1205 (derailment in Farragut North pocket track)
  • RAB1204 (rear-end collision in West Falls Church yard)
  • RAR1204 (two track workers struck and killed by hi-rail vehicle outside Rockville)

Comments Off

Filed under News

Tagged as , , , ,

June 4, 2012

Bringing OpenTripPlanner and OneBusAway to DC to improve rider experience

I want to bring OpenTripPlanner and OneBusAway to DC. Why? Simply put, because they’re a lot better than what we’ve got now.

WMATA’s trip planner has no API for developers, returns illogical and nonsensical results for some trips (which can be due in part to data quality problems), is based on a costly, proprietary product, and has a clunky, outdated-looking interface. As for leading-edge features like real-time and intermodal trip planning (including bicycling and bike sharing)? Dream on.
Continue reading →

2 Comments

Filed under Commentary

Tagged as , , , ,

May 29, 2012

An object lesson in developer relations

Last week, I posted about some issues with Montgomery County Ride On’s new API.

A few days ago, I tried to re-start my test OneBusAway instance, including the translator I’d written to generate a proper GTFS-realtime feed for Ride On. To my surprise, I found that something had changed with the Ride On API, and my translator no longer worked properly. When I investigated, I found that the API endpoint for GTFS-realtime now correctly returned the binary Protocol Buffers format, one of the issues I’d mentioned in my earlier post.

So, I decided to review the API documentation and see what had happened. Since G&O (the contractor that built the system for Montgomery County) keeps the API documentation in a MediaWiki wiki, we can look at the recent changes quite easily.

Aside from a bit of Wiki-spam, we see a flurry of activity on May 22 and 23, documenting the following changes:

  • Release of source code: The code which powers the Ride On API has been released as open source, under the GPLv3.
  • Documentation on use of access token: As documented here, the supplied access token is intended to be included in API calls as the auth_token parameter.
  • GTFS-realtime endpoint fixed: Perhaps most importantly, the GTFS-realtime endpoint now offers a choice between the binary Protocol Buffers format (the default), and the text-based debugging output. As a result, the feed can now be used out-of-the-box with GTFS-realtime tools.

I am, of course, glad to see that these changes have been made. But where was the developer outreach? I’ve written before about the vital role that effective developer outreach plays in the success of open transit data initiatives, and this is a perfect example.

A quick email to a developer mailing list outlining the changes that had been made would have kept developers in the loop. More importantly, a developer mailing list also provides an excellent feedback mechanism, allowing developers to share their observations in working with the API, and distinguish genuine problems from transient failures or problems with their own code.

For example, right now it seems like the latitude and longitude in vehicle positions are being transposed. This appears to affect both the vehicle_positions and gtfs_realtime API methods, so I suspect it’s an issue with the underlying data, rather than any particular API method, or the clients I’m using.

It’s not clear how best to report this issue, so I’m blogging about it. It’s probably a quick fix—in working with geodata I’ve certainly transposed latitude and longitude fields many times before—but it is still something that needs to be examined. Better developer outreach would make it easier for developers to report these types of issues and get updates on their resolution.

Having said all of that, in case I’ve not adequately emphasized this point, let me be perfectly clear: in the span of a few months, Ride On has gone from providing no real-time data to providing some of the best real-time data in the region. Ride On currently has the only standards-compliant real-time feed in the region, and the only one that properly correlates static and real-time data, by using the same trip IDs across the GTFS schedule data and the GTFS-realtime feed. When it comes to providing data that can be used with existing passenger information systems, trip planners, and other tools, this is huge.

1 Comment

Filed under News

Tagged as , , ,