Gregory Szorc's blog

Debugging Nextbus

This entry will serve to explain my progress with debugging Nextbus's interface for obtaining the GPS data of objects.

The Nextbus Google Maps for Case routes are the following:

• http://www.nextbus.com/googleMap/test.jsp?a=case-western&r=circlelink
• http://www.nextbus.com/googleMap/test.jsp?a=case-western&r=commuter
• http://www.nextbus.com/googleMap/test.jsp?a=case-western&r=circlelink
• http://www.nextbus.com/googleMap/test.jsp?a=case-western&r=eveningnorth
• http://www.nextbus.com/googleMap/test.jsp?a=case-western&r=eveningsouth
• http://www.nextbus.com/googleMap/test.jsp?a=case-western&r=routeb
• http://www.nextbus.com/googleMap/test.jsp?a=case-western&r=ucrc

You can query for a specific route's GPS coordinates via:

http://www.nextbus.com/s/COM.NextBus.Servlets.XMLFeed?command=vehicleLocations&a=case-western.

This script takes 3 parameters 'r', 't', and 'key'. 'r' is the route identifier. It is one of {'circlelink', 'eveningnorth', 'eveningsouth', 'routeb', 'ucrc'}. 't' and 'key' are time and key identifiers.

When you load up a Google Map from Nextbus, you are requesting http://www.nextbus.com/googleMap/test.jsp?a=case-western&r=commuter or similar. The request returns an HTML document with a lot of JavaScript. In addition to the JavaScript in that page, the following JavaScript files are references and subsequently downloaded by your browser:

• Google Maps API (standard for any application using Google Maps
• debug.js Nextbus Debugging Functions
• zoomToRectangle.js Nextbus Zooming Functions
• googleMapEnhancements.js Nextbus Google Map Enhancements
• xmaps.1c.js XMaps enhancements to Google API -- cool stuff!
• gxmarker.1.js GXMarker library

These externally-included libraries aren't very interesting for what I am doing. They just provide functions used by Nextbus's Google Map implementation.

What IS interesting in the in-line Javascript. As I said earlier, the script to request GPS updates from Nextbus takes the parameters 't' and 'key'. 't' is returned from a valid response and fed into the next update (I think). 'key' is obtained from somewhere else. That else is the inline JavaScript. Around line 67 you will find the initial value of this variable is hard-coded into the JavaScript. I'm not sure if this is a dynamically set variable or not, but for me the initial value is "6546363665".

Next, the script goes through its initialization routine. The first thing it does is get information about routes. It queries the following URL:

http://www.nextbus.com/s/COM.NextBus.Servlets.XMLFeed?command=routeConfig&a=case-western&r=circlelink&key=6546363665. Again, we have the 'r' and 'key' variables to specify. The return of this script is actually pretty darn cool. It contains XML describing every route. It has the GPS coordinates of every stop as well as a text description of the stop and information about what the next stop is. I need to import this data somewhere... At the tail end of this returned XML document, it contains something like the following:

<keyForNextTime value="1947645158130" />

The next request to Nextbus is the current location of the buses on a route. The query looks like the following:

http://www.nextbus.com/s/COM.NextBus.Servlets.XMLFeed?command=vehicleLocations&a=case-western&r=circlelink&t=0&key=1947645158130.

Notice something? 'key' is equal to the value returned from the previous script!

We look at the return from this script. It contains the GPS data we are seeking. The bottom of the XML document returned looks like the following:

<lastTime time="1138642345404"/>
<keyForNextTime value="1989361311786" />

We notice the following request for the GPS update has the parameters t=1138642345404&key=1989361311786

In summary, http://www.nextbus.com/s/COM.NextBus.Servlets.XMLFeed handles all of the important requests. This script takes the parameters 'command', 'a', 'r', 't', and 'key'. 'command' tells the script what to do. Two potential values are 'routeConfig' and 'vehicleLocations'. 'a' is the organization you are tracking. For Case, it is 'case-western'. 'r' is the route. Values are {'circlelink', 'eveningnorth', 'eveningsouth', 'routeb', 'ucrc'}. 't' is the time of last request. On the initial request to each command, its value is '0'. On subsequent requests to 'vehicleLocations' it is the value provided by the return of the previous call to the script. 'key' is a unique key to identify the session. Initially, it seems to be set to '6546363665'. When you query 'routeConfig', you will get a new key that is used to query 'vehicleLocations'. Likewise, when querying 'vehicleLocations' you get a new key to use. It seems that you can reuse the same key over and over, but I'm not sure what difference this makes.

So, the GPS query mechanism has a security measure in place to prevent people from randomly accessing the information. However, if you follow the procedure I have explained, you should be able to program a script that follows the chain of events necessary to keep fetching updates. Good luck.

You can ping this entry by using http://blog.case.edu/gps10/mt-tb.cgi/5569 .

I went to greenie.case.edu and found that the Greenie tracking service is up and running! Check it out at http://www.nextbus.com/?a=case-western....