Web Service/API? Android App Proof of Concept

[lee.t]

Hi there,

I'm a big fan of Google Transit. So much so that I spent the last few
months developing an android app to serve transit data for consumption
by mobile users. The effort was done as part of the Android Developer
Challenge. If you're interested, you can get more info here:
http://www.tranzit.ca/readme.pdf

Anyway, since dropping a bunch of google_tranzit.zip's onto a handheld
device and telling it to go crazy isn't really an option, a huge part
of the effort was put into mirroring the existing data available from
the archived public data sources in a php/mysql back end, making it
possible for a mobile app to make a OTA request like "give me all of
the scheduled times for today's service on BART route 1 at stop 003"
and get back a nice list of scheduled stops in JSON format.

Are there any plans open up the public data with a full API or web
service? Regardless of the outcome of the Android Challenge, I hope to
continue working on this, as it's something that I would use... That
effort would be made so much easier if I didn't have to reinvent the
wheel :) I'd love to take this from the simple 'service schedule/
notifications' stage to full blown trip planning...

Any information is greatly appreciated. Also, if I can be of any help
in the effort, by all means - let me know.
Cheers
Todd

[Joe Hughes]

Todd,

That sounds really cool! I'd encourage you to post about it on the
Transit Developers Google Group. If nothing else, I'm sure there are
others that would be interested in hearing more about your project,
and possibly even making use of/extending the API server you've
written.

Joe

[lee.t]

Thanks Joe - done.

T

[p...@globalxpres.com]

Don't know if there is any way to work together. Our app is entirely
javascript and ajax.

TransitTrips.com

PatC

[JP]

On Apr 15, 12:13 pm, "lee.t" <3le...@gmail.com> wrote:

> Are there any plans open up the public data with a full API or web
> service?

Hi Todd,
TriMet in Portland does that already.
http://developer.trimet.org
The API is geared towards real time passenger information, but builds
on the same original data source as the Google Transit feed does.
I have a discussion and a few flash clips of an Android demo in the
googletransitdatafeed wiki:
http://www.googletransitdatafeed.org/wiki/index.php?title=TransitCast

JP

[lee.t]

This is interesting JP, but I'm thinking that, while the real-time
info is certainly novel, the majority of agencies either don't have
it, or if they do they're not sharing it externally... What is
generally shared (the regularly scheduled routes/stops in a given
service area) is useful enough in it's own right and could certainly
benefit from an open Web Service/API so that developers don't have to
'reinvent the wheel' in order to get access to up to date data on
mobile device.

The idea here would be to have a standard, hosted solution based on
the google transit data that allows structured queries or specific api
calls of ALL available agency data, rather than a specific solution
tailored to one specific transit provider (like trimet). In order to
be truly useful (in the broader sense) I think this is the biggest
hurdle - get something that works for every user/agency.

Cheers
Todd

On Apr 16, 12:33 am, JP <Joachim.Pfeif...@gmail.com> wrote:
> On Apr 15, 12:13 pm, "lee.t" <3le...@gmail.com> wrote:> Are there any plans open up the public data with a full API or web
> > service?
>
> Hi Todd,

> TriMet in Portland does that already.http://developer.trimet.org

[JP]

Hi Todd,
See below...

On Apr 23, 10:58 am, "lee.t" <3le...@gmail.com> wrote:
> This is interesting JP, but I'm thinking that, while the real-time
> info is certainly novel,

...actually, it isn't at all. The first real-time passenger
information system for bus fixed-route services with wayside displays
along the route - that I am aware of - is route 54 in Stockholm,
Sweden. This system was built around 1992. Many systems of this kind
around Europe and North America were built since (I worked on a
handful) and probably other continents as well...

> the majority of agencies either don't have
> it,

The bigger ones typically do for quite some time (called CAD/AVL
systems) and many in Europe have second generation refresh's behind
them for quite some time now, while the first transit agencies which
implemented CAD/AVL in North America are now also looking at
refreshing their systems with new technology.

> or if they do they're not sharing it externally...

which is absolutely correct. Initiatives like Dabnab or Trillium's
project in San Francisco illustrate that need - at this point, they
are scraping arrival estimates off transit agencies web sites. Less
than ideal, as the format of the presentation layer will change more
easily than the underlying data feed.

> What is generally shared (the regularly scheduled routes/stops in a given
> service area) is useful enough in it's own right and could certainly
> benefit from an open Web Service/API so that developers don't have to
> 'reinvent the wheel' in order to get access to up to date data on
> mobile device.

With growing maturity and broader implementation of CAD/AVL, real-time
data indeed are available. These are multi-million dollar systems, so
you can see that offering the relevant data to the public is by far
and large a cultural and "political" issue rather than a technical or
fiscal one, and the benefit over plain schedule data outweighs the
extra effort IMO.

>
> The idea here would be to have a standard, hosted solution based on
> the google transit data that allows structured queries or specific api
> calls of ALL available agency data, rather than a specific solution
> tailored to one specific transit provider (like trimet).

You hit it on the head - it would be more than feasible that other
transit agencies offer feeds in this format. Development of standards
however has been a longstanding issue. You've got to start somewhere,
as they say.