ProximoBus: An alternative API for the public NextBus data feed

773 views
Skip to first unread message

Martin Atkins

unread,
Nov 17, 2009, 3:48:22 AM11/17/09
to Transit Developers

Hi all,

I was really pleased to see that NextBus for Muni now has a public data
feed.

I spent last weekend making a wrapper around the NextBus data feed which
presents the same data in an alternative way.

Key features are:

* Supports JSON and JSON-P output.

* Supports KML output of stop and vehicle locations only, for Google
Earth and other compatible applications.

* Splits the data up into more endpoints containing less data each to
avoid re-transferring static data when polling dynamic data. This should
be useful to reduce overhead for mobile devices in particular.

Docs are here:

http://proximobus.appspot.com/docs.html

And I also have an example application, which is a display of real-time
predictions for Powell Station outbound arrivals in San Francisco using
the JSON-P variety of various endpoints:

http://proximobus.appspot.com/examples/arrivalsdisplay/index.html

(this station has no overnight service, so if you look at it between
~1am and 6am PST you'll probably see nothing there.)

I hope that more of the NextBus-enabled transit agencies will get
NextBus to enable their public data feed so that this API becomes more
widely useful. Right now you still need to scrape NextBus if you'd like
to get data for other agencies.


Joe Hughes

unread,
Nov 20, 2009, 2:31:45 PM11/20/09
to transit-d...@googlegroups.com
Hey Mart,

Very cool to see further innovation on top of the realtime data.
Also, your sample app that's a Muni version of the BART DIY display (
http://www.bart.gov/schedules/developers/displays.aspx ) is pretty
slick--have you considered making it a usable thing on its own (that
is, more easily configurable by a non-techie)?

Joe
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "Transit Developers" group.
> To post to this group, send email to transit-d...@googlegroups.com
> To unsubscribe from this group, send email to transit-develop...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/transit-developers?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>

Martin Atkins

unread,
Dec 4, 2009, 12:52:59 PM12/4/09
to transit-d...@googlegroups.com
On 11/20/2009 11:31 AM, Joe Hughes wrote:
> Hey Mart,
>
> Very cool to see further innovation on top of the realtime data.
> Also, your sample app that's a Muni version of the BART DIY display (
> http://www.bart.gov/schedules/developers/displays.aspx ) is pretty
> slick--have you considered making it a usable thing on its own (that
> is, more easily configurable by a non-techie)?
>

Although I didn't mention it, it'll look at the fragment in the URL and
treat it as a stop id to select another stop without hacking the source:

http://proximobus.appspot.com/examples/arrivalsdisplay/index.html#14942

I guess the logical next step is to have a UI for browsing the stops so
you don't need to hunt down the stop id; I'm not actually sure where on
the actual website you find these, since all of the UI URLs use the stop
"tag" instead.

(NextBus curiously has two different identifiers for stops. One of them
seems to match the ids used in the GTFS data, while the other is the one
that you can enter into the text field on the mini HTML site to jump to
a stop. I went for the latter thinking that folks would be more familiar
with it, but this is at the expense of being able to corrolate with the
GTFS data.)

It's probably also worth noting that Muni service is changing tomorrow,
and since ProximoBus caches some data for up to a week it might return
inconsistent results for a while where some things are cached and other
things are not. It remains to be seen when NextBus will actually be
updated to reflect the new route patterns.


j...@ultralame.com

unread,
Dec 16, 2014, 10:18:13 PM12/16/14
to transit-d...@googlegroups.com, ma...@degeneration.co.uk
Hi!  I just found this, and first off... thank you!

I am quite interested in this URL:

List of predicted arrivals for a specific stop

URL: /agencies/id/stops/id/predictions

Nextbus doesn't seem to have a call that returns predictions by stop, only by stop and route.  But your app seems to get around that.

Is there a way for me to see what you are up to with this function?

Martin Atkins

unread,
Dec 17, 2014, 2:33:34 AM12/17/14
to j...@ultralame.com, transit-d...@googlegroups.com
Jed,

The underlying "predictions" API has two modes.

In one mode it takes a route tag and a stop tag, where the stop tag is an internal code used only within the API. I think this is the one you are thinking of.

It also has another mode that takes just the public-facing stop id. Some agencies (though I noticed not all) have ids that are displayed to the public on stops, and these ids can be used without a qualifying route.

It is a known bug in proximobus that it can't really deal with the agencies that don't use these public-facing stop ids, since I realized too late that not all agencies use them.

Here is a working example URL in the form that proximobus uses:

In that example only one route serves this stop, but if you find a more central stop you can see multiple "predictions" elements, one for each route.

This is the ProximoBus equivalent of that URL:

The Python code making this call is here:






Jed Davidow

unread,
Dec 17, 2014, 2:38:37 AM12/17/14
to Martin Atkins, transit-d...@googlegroups.com
Thank you for your quick answer; I see that there are the two formats for the stopID/stopTag, and that appears to be what hung me up.

Thanks!

Martin Atkins

unread,
Jul 12, 2015, 3:39:13 PM7/12/15
to jon.e.f...@gmail.com, transit-d...@googlegroups.com
Hi Jon,

At some point last week the app engine app was suspended, but I've been unable to figure out why. 

The only indication of its status is a warning box on the App Engine dashboard that says "Your app is currently disabled or pending deletion", but there is no further context about why that might be or what I can do about it. It was running entirely from App Engine free quota so it's possible that Google is retiring the idea of "free quota" but I've seen no communication on that subject.

Since I was running this service only on a best-effort basis I wasn't able to spend an extensive amount of time trying to understand its status, and so unless a solution presents itself unfortunately I think ProximoBus has been forced into retirement. If there are any App Engine experts reading this who know what I can do to resolve this then I'd love to hear it.

The code remains in its github repo, so you and others should feel free to fork it and run your own instances on App Engine if that is helpful to you:

I'm sorry for the inconvenience and the fact that I didn't communicate about it better. Given that it was a wide open API I wasn't really sure how best to reach the (somewhat anonymous) userbase, but I guess this message might reach at least some of them.


On Sun, Jul 12, 2015 at 12:24 PM, <jon.e.f...@gmail.com> wrote:
I've been using this service for almost 5 years now, thank you for setting it up!

Sometime this weekend it stopped working. Did you decide to retire it?

Cheers,
Jon


jon.e.f...@gmail.com

unread,
Jul 12, 2015, 8:39:27 PM7/12/15
to transit-d...@googlegroups.com, ma...@degeneration.co.uk
Reply all
Reply to author
Forward
0 new messages