[Open-transport] Open Transport Data tools / webservices

Mon Jul 15 16:31:55 UTC 2013

tl;dr - Advocate for bulk data formats, not high-level service APIs.

Creating service APIs for transit data is the easy part.  In fact, I'm
pretty sure we could find 20-30 different APIs that people have put
together if we tried hard (my contributions below).  Don't like the
existing APIs?  Create a new one!  http://xkcd.com/927/

The real trick is getting everyone to use one API.

At one point, I used to think it'd be great if every transit agency
provided a high-level REST API that I could point my app at and suddenly my
app would work in every city in the world.  However, when I started to
think about the technical details of making this work in practice, I
quickly decided it wasn't worth the effort.  In a perfect world, of course,
every agency would be running the latest version of the API and API
endpoints could be nicely federated into cohesive service areas.  In
reality, most agencies would initially deploy their API server and not
touch it for five years.  Two agencies offering service in the same city
would both provide their own API endpoints, likely with overlapping data.
 Imagine trying to write an app that sits on top of all that.  Imagine
route planning in such a world.  It's of course possible, but it doesn't
sound like much fun ; )

And we don't even live in anything like that world.  In reality, agencies
have been deploying APIs of their own creation for years now (witness the
list below).  Trying to convince agencies to switch to a standards-based
API when they already have an API that is working and has local apps is a
tricky value proposition.  The value proposition is slightly better for new
agencies who are thinking about deploying a new API, but the "Deploy this
standard API and you will magically have 20 apps tomorrow" narrative
doesn't seem to work that way in reality quite yet.  And local developers
tend to work with whatever they can get, either way, so the new agencies
are generally fine no matter what they deploy.

In the end, I decided that it's easiest writing apps against a single API
that aggregates raw transit data from lots of agencies.  As such, I went to
work for one of the biggest aggregators of transit data in the world
(ahem... Google).

These days, I spend a lot of time advocating for standardization of bulk
data formats (mostly GTFS and GTFS-realtime) because it's what Google
needs.  But more importantly, I think the open-data movement and it's
developers are ultimately better served by bulk access to data than
high-level APIs.  When someone provides a high-level API, they are
necessarily making decision about what you will and won't be able to do
with the API.  However, with bulk data formats, you aren't so constrained.
 Applications like OpenTripPlanner wouldn't be possible without bulk access
to schedule data, for example.

So, in summary, I'd encourage the working group to advocate for bulk data
formats, not high-level service APIs.

Now all we have to do is agree on preferred bulk data formats ;)

Finally, as promised, just to point out the size of the problem, a handful
of Transit Service-Oriented APIs off the top of my head in addition to the
ones that have already been mentioned (a bit North America centric, but I
see the same fragmentation happening in Europe as well):

SIRI, epsecially with the discovery features that Michael Frumin has been
championing
NYC MTA BusTime APIs: http://bustime.mta.info/wiki/Developers/ -
Combination of RESTful SIRI + OneBusAway API
The OneBusAway REST API:
http://developer.onebusaway.org/modules/onebusaway-application-modules/current/api/where/index.html
(caveat:
I wrote this one)
The Google Directions API:
https://developers.google.com/maps/documentation/directions/ (caveat: I
work for these guys ;)  But transit data for 850+ cities worldwide is
nothing to sneeze at)
NextBus API: http://www.nextbus.com/xmlFeedDocs/NextBusXMLFeed.pdf
The TFL Bus API:
http://www.tfl.gov.uk/assets/downloads/businessandpartners/tfl-live-bus-and-river-bus-arrivals-api-documentation(1).pdf
TriMet's Web Service: http://developer.trimet.org/ws_docs/
CTA BusTracker API: http://www.transitchicago.com/developers/bustracker.aspx
The BART API: http://api.bart.gov/docs/overview/index.aspx
The MBTA API:
http://realtime.mbta.com/Portal/Content/Documents/MBTA-realtime_DeveloperDocumentation_v1.0.2_2013-06-25.pdf
The WMATA API: http://developer.wmata.com/io-docs
The Open 511 Data Exchange:
https://groups.google.com/d/msg/511sfbaydeveloperresources/zdD8ox5l2G4/yMD-Xb9R4hcJ(proposing
to use SIRI + NeTex for web-services)

On Sun, Jul 14, 2013 at 3:58 PM, Pieter Colpaert
<pieter.colpaert at okfn.org>wrote:

> Hi all,
>
> Seems like this has been an issue for quite a while: how do we turn raw
> transport data into an API and which format/vocabulary should this API
> adhere to?
>
> * I have found a GTFS → API in nodejs over here:
> https://github.com/brendannee/node-gtfs
> * There is also http://navitia.io who has plans to go open source.
> * Open Trip Planner has an API as well.
>
> Are open source open transport data tools stuff that our Open Transport
> working group should push for? Which one would you prefer rights now?
>
> Kind regards,
>
> Pieter
>
> _______________________________________________
> open-transport mailing list
> open-transport at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/open-transport
> Unsubscribe: http://lists.okfn.org/mailman/options/open-transport
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/open-transport/attachments/20130715/ff876848/attachment.html>