Comments on What's up with NextBus, part 2: A pile of APIs - Greater Greater Washington

Comment by alurin

Tue, 22 Jan 2013 13:57:57 EDT

So, does any of this explain why the RideOn "Real Time" data are so unreliable?

Comment by RC

Mon, 21 Jan 2013 18:35:08 EDT

The NextBus feed is good, but it's vendor specific. If WMATA chose to replace nextbus, all the apps would break, thus it created it's own. That and Nextbus deals with bus predictions. Last time i checked there were a good real of riders who depended on the rail side of things.
SIRI v2 (whatever nyc is using) is a good suggestion for WMATA to move to. A good way to entice app developers to move and ask for a standard is the fact they can resell their apps for other areas across the country by re-pointing the data source instead of having to develop a whole new interface.
If you back off the WMATA focus for a second and do a cross comparison on what transit agencies around the country are doing, you'll see that it's a complete mix of non standardization.
NYC - SIRI (for bus) and GTFS-realtime (for rail)
LA - internally developed API and Nextbus API
CTA - Clever Devices BusTime API, separate rail API by QuicTrak
SEPTA - internally developed API
Muni - nextbus API
WMATA - internally developed API that includes bus and rail
comparatively they're not better or worse off. Since no one has a standard that's universal they went with a solution that works. Is it the best one? hard to say, but it's in line with the rest of the country.

Comment by Joshua Cranmer

Mon, 21 Jan 2013 15:37:40 EDT

@Ski:

Pray tell, how would you access "open data" without an API? APIs in this sense are basically just a way to tell you where to find the open data and how to read it. Without a standard to do that, you basically focus every developer to start from scratch to read data from every provider, and you have fixed absolutely nothing.

Comment by @OneAPI4SMS

Mon, 21 Jan 2013 14:38:40 EDT

If a standard is not a standard, another approach is to use a gateway that exposes one API to consumers (of the API) but connects to other APIs in the background.

Comment by Ski

Mon, 21 Jan 2013 12:24:36 EDT

Unifying on a single standard is a hopeless idea. As RC stated, NYC MTA rightfully found the SIRI "standard" to be completely lacking and therefore modified it creating yet another "standard". Plus SIRI is managed by a committee, which is not the most effective way to deal with rapidly evolving technologies.

And GTFS-real time, as mentioned by Matt Caywood, is for large data consumers like Google, not for smartphone apps. Google created the format specifically for their own internal needs. And look how few users there are in the US.
The NextBus API is used by far more end users than GTFS-real time.

And it does seem rather ironic that WMATA is breaking apps now by not allowing other feeds, such as the NextBus feed, because they are worried about possibly breaking them in the future. Really quite short sighted.

But there is a simple solution. Promote open data, not specific APIs. And then see which APIs the app developers gravitate towards. Then emphasize those few APIs.

Comment by Steve

Mon, 21 Jan 2013 07:32:28 EDT

Our Nextbus feed is working fine. Why isnt DCs?

Comment by Phil LaCombe

Sat, 19 Jan 2013 16:57:03 EDT

@Matthew
I highly recommend DC Metro Transit for Android. It's an excellent app. The paid version is well worth the price at $2.99. JazzMoon Studio developed it.

Comment by Transport.

Fri, 18 Jan 2013 17:49:34 EDT

Us Fairfax Connector riders are lucky... we don't have any of these API data feed issues since there is no real time arrival information .

Comment by Matt Caywood

Fri, 18 Jan 2013 17:44:57 EDT

@MLD - I wish I remebered the explanation but it was something to do with Arlington being a county and a city.

Comment by MLD

Fri, 18 Jan 2013 16:45:09 EDT

GTFS-realtime would be great since it can integrate into Google Maps, but as RC says it works in a fundamentally different way.

As for the concern about breaking apps, it's only a concern if you change APIs all the time. You could introduce the new API, and keep the old one for 6 months while spamming your development list saying the old API is going away on a certain date. Then just turn it off. People can move on to other apps.

If this NextBus "crisis" has taught anything it's that transit agencies should:
1. Have an app gallery PROMINENTLY on their website
2. Go out there and actually look for apps that exist and put them on your gallery
3. Have a convenient way for app developers to submit their apps for consideration

WMATA fails on all three, they do have an app gallery but I bet you can't find it!

Comment by RC

Fri, 18 Jan 2013 15:50:05 EDT

I'm pretty sure at #Transpo camp the fellow from ART mentioned that "we're lucky that our real time prediction provider decided to support GTFS-Realtime". While i think it's great that they support it, it's more or less by luck.
Here's the scoop. There are two standards. SIRI and GTFS-Realtime. Both are fairly new (the folks at nyc told us they modified SIRI by "Breaking" it to provide more functionality, which is what a lot of the early adopters in europe were looking to do).
GTFS-Realtime is geared towards a complete snapshot model. Developers would subscribe to the snapshot and individual requests would go to the developers.
SIRI is more of the standard API model. Query on each stop just like the WMATA or Nextbus API works.
Honestly, providing both standards and letting the developers decide which one works for them with the same data source would be a bit more work, but will pay off in the long run.
Just realize that the standards have been in the works for years, but when the WMATA Api came out, there was no clear standard and GTFS-Realtime was just a twinkle in a researcher's eye at the time.

Comment by MLD

Fri, 18 Jan 2013 13:53:35 EDT

@Matt Caywood
The reason is that Google requires indemnification in their contract to accept the data, but Arlington is prohibited by the state from doing so. A statewide change is in the works but it is currently stuck in AG Ken Cuccinelli's office.

Interesting, but there are tons of Virginia transit agencies on Google Transit so it seems weird that they would need some immunity from the state to participate.

Comment by Matt Caywood

Fri, 18 Jan 2013 13:28:18 EDT

@Zach - ART has made their data widely available in open formats -- see the Mobility Lab list of local transit open data.

As I understand it, ART has made every effort to be in Google Transit but cannot be at present. The reason is that Google requires indemnification in their contract to accept the data, but Arlington is prohibited by the state from doing so. A statewide change is in the works but it is currently stuck in AG Ken Cuccinelli's office.

I hope he makes it a priority :/

Comment by Matthew

Fri, 18 Jan 2013 13:25:35 EDT

What's really annoying is that the NextBusDC app for iPhone works PERFECTLY for all the services in the area (that use the technology) *AND* it's feature-rich with stop locations, bus locations, maps, etc. But now that I'm on Android the two best NextBus apps I could find, both suck pretty hardcore. You can't search based on stop, stop number, route, or anything. It just suggests some routes that might be nearby you but the list is hardly ever inclusive of all routes nearby and I find myself frustrated by it. I'm not going back to the iPhone just to get bus predictions so I hope the Android developers step up their game...

Comment by Zach

Fri, 18 Jan 2013 13:06:13 EDT

What I don't quite understand is why ART buses don't show up in realtime on Google Maps. (The static schedules have been there for a long time.) Arlington County provides GTFS and GTFS-realtime feeds (http://www.arlingtontransit.com/pages/rider-tools/tools-for-developers/). Do county transit staff need to work with Google to make this happen?

Comment by Matt Caywood

Fri, 18 Jan 2013 12:55:33 EDT

GTFS-realtime helps huge data consumers like Google, but it isn't very helpful to small developers.

The agency or another public sector partner needs to provide a SIRI interface as well, or very few apps will get built.

The nice thing about NextBus and (to an extent) the existing WMATA API is that they give you the basic functionality you need to build a real-time app.

Comment by Kurt Raschke

Fri, 18 Jan 2013 12:28:05 EDT

WMATA should be using GTFS-realtime. Enough said.

Comment by MLD

Fri, 18 Jan 2013 12:17:09 EDT

Luckily some open standards (free to use) for real-time information already exist:
SIRI is a public transit standard for real-time information that is used in Europe and also used by NYMTA.
TCIP is a standard developed by APTA that has a real-time information component but is designed to connect lots of transit ITS systems.
GTFS-realtime is a standard developed by Google.

The problem for a lot of transit agencies is that they are beholden to NextBus or whoever their provider is, and those companies want to use THEIR API rather than produce an API in a standard format. Smaller agencies especially do not have the expertise or staff time to create and manage their own APIs nor do they have the expertise to put this stuff up in the initial contract.

Comment by GP Steve

Fri, 18 Jan 2013 12:09:46 EDT

Would using General Transit Feed Specification-Real Time (https://developers.google.com/transit/gtfs-realtime/) be a solution?

Comment by David Alpert

Fri, 18 Jan 2013 12:08:30 EDT

I was actually planning to use this comic in a later part. I think of it every time a discussion of standards comes up.

Comment by Gavin

Fri, 18 Jan 2013 11:49:10 EDT

Thanks for explaining this, David. But I'm always cautiously optimistic about developing standards: