The Need for More Transit APIs | Hacker News Reader

The Need for More Transit APIs

blog.apievangelist.com

27 pointsapievangelist22 comments

The NYC MTA seems to have done an about-face from "you can't have any data, and we'll sue you if you do get it" [1] to opening up their data and holding app contests:

http://mtaappquest.com/

I'm still waiting on a real-time train schedule API, but they've come a long, long way.

[1] http://iplj.net/blog/archives/1346

My team built the software powering the contest. We aren't involved with the API though. I'm happy to help anyone with questions - Colin at challengepost dot com

You might be interested in the Walk Score Transit API. In addition to surfacing a "transit score" for a given area, it also provides a simple RESTful way to get stops and routes at a given lat/lon:

http://www.walkscore.com/professional/public-transit-api.php

The Walk Score API is built on top of the GTFS Data Exchange web site and APIs. GTFSDE is a clearinghouse for the latest GTFS data worldwide:

http://www.gtfs-data-exchange.com/

(Note that raw GTFS from agencies is often quite buggy -- the Walk Score API does a ton of work to clean it up and fix errors.)

Finally, the City Go Round web site and API surfaces apps that make use of transit (and other local) data:

http://www.citygoround.org/

Hope these are interesting for you!

Great suggestions. Very interesting...thanks for sharing.

I don't know why transit agencies don't just open-source and make available the raw data they have. Often I see them trying to put together "apps" or some such gizmos, when the reality is, if they just made the underlying raw data available (in a reliable manner), someone will come along and build apps for them on their own dime. The transit agencies would rather spend money hiding the data, and then more money building some crappy app, than open the data and get all the labor for free. They just don't get this whole "open-source" thing.

The underlying issue is that some agencies can't for some odd reason or another give out their data. There is either some archaic policy in place or for some historical/contractual reason the data isn't actually owned by the agency but instead by some contractor that provides the technology to generate the data. Some smaller agencies might not even have a department that is aware of that issue/possibility because they once again subcontract it all out and the contractor isn't going to suggest to release data for free to get free projects.

The best way to change that is to request it at the local level. If local developers put pressure on their transit agencies then that will help speed up the process.

I'm working on deeper stories along these lines. Many of these agencies have signed into extremely long, and closed contracts, that give away ownership of "our" data.

I agree. A lot of times the contractor who built the system will either (a) see the value in the data, and put in a clause walling it off, or (b) try to obfuscate the data so it's not easy to get to, so that they'll get more money to free the data.

SF's MUNI had a huge mess on its hands with the whole NextBus thing. Eventually the developers prevailed, but this is SF, where you can't throw a stone without hitting some developer. Imagine the situation in not so tech-heavy cities.

There's a lot of privacy implications to that as opening up truly raw data could, depending on the form, allow people to track other's movements through the system.

I'm sorry, but: the position of a transit bus at a given point in time is not really "private" data. Neither is the number of parking spots open in a City garage; or the meter rates of parking meters.

Considering that you have a picture of a Seattle bus on your blog post, I'm surprised you didn't mention OneBusAway.

The sad irony is that Seattle is most likely going to lose its best source of near-real time transit information because the author is going to work for Google on Google Transit: http://onebusaway.blogspot.com/2011/06/future-of-onebusaway....

We need to get a group together to take over. So much good stuff still to do with OBA...

I would love to see a group of people here in town take it over.

When I spoke to Brian in May, I think he said that he and a few volunteers would continue to support the app (and I'm assuming the volunteers are local)

One bus away is definitely on my list, this was just first in a series of transit API related posts.

i look forward to the rest of your series, then :)

Very interesting article. I am currently working on a project called opentimetable.net, providing tools for the community to collect timetable raw data, something similar to openstreetmap (osm), but for timetable data. Actually, the project is tighly connected to osm as I am pulling static infrastructure data from osm which is already available or is becoming available sooner or later (stops, lines, etc...). Within opentimetable.net, the user can then enrich that data with timetable information. Of course, data will be available to the public. I already cooperating with some german transit agencies.. I hope to get other agencies involved in the future. I have also implemented a route planner for public transit data which I will put online once a minimum of data is available...

This seems to be pretty "complete": http://code.google.com/p/public-transport-enabler/

It's used by Öffi (https://market.android.com/details?id=de.schildbach.oeffi...) AFAIK.

London is getting sane after a start when they didnt get it. http://www.tfl.gov.uk/businessandpartners/syndication/defaul...

There is a lot of data, producing a coherent model across different places will be hard, for a comprehensive model.

I've started modelling based on the GTFS data model. The schema I've created so far is at http://vocab.org/transit - it's close to GTFS, modified by conversations with other transit data developers. Example of data using this schema is at http://beta.kasabi.com/dataset/mta-new-york-city-transit

The TTC (Toronto) has been pretty good about this, especially lately. Initially releasing real-time APIs for our streetcar routes and now every single bus route has realtime, GPS based methods.

Info found here: http://toronto.ca/open/

There is a website scraping based API for realtime data in for the Minneapolis/St. Paul area here:

http://metrotransitapi2.appspot.com/

Source is on github

Reply on news.ycombinator.com