The following two sections discuss the details of real-time transit information interfaces provided by the software behind the OneBusAway Tampa deployment.

A GTFS-realtime contains a snapshot of the real-time status of the entire system. Typically, this interface is used by other servers to retrieve data for all routes and buses. This feed is used to provide real-time information to OneBusAway and Google Maps. See the GTFS-realtime spec for more documentation on the GTFS-realtime format.

We offer two types of GTFS-realtime feeds for HART data:

1. Trip Updates Feed

• Applications should access this feed at the URL http://api.tampa.onebusaway.org:8088/trip-updates to retrieve the file in Protocol Buffer format, which is the default GTFS-realtime format that would be consumed by applications.
• A plain-text version can be seen at http://api.tampa.onebusaway.org:8088/trip-updates?debug, for debugging purposes only (should NOT be used by apps).

2. Vehicle Positions Feed

• Applications should access this feed at the URL http://api.tampa.onebusaway.org:8088/vehicle-positions to retrieve the file in Protocol Buffer format, which is the default GTFS-realtime format that would be consumed by applications.
• A plain-text version can be seen at http://api.tampa.onebusaway.org:8088/vehicle-positions?debug, for debugging purposes only (should NOT be used by apps).

See more details on the Tampa GTFS-realtime feed implementation on the project wiki.

No key is required for the GTFS-realtime feed.

The OBA REST API is used to retrieve targeted real-time information for a specific bus stop or route. Typically this interface is used by mobile apps to retrieve information about a specific bus stop or route that the mobile app user has requested.

See the OBA REST API documentation for more information.

Before mobile apps can use this interface, they must request a API key from the Tampa OneBusAway administrators. See the OBA Tampa API Service page for information on how to request an API key.

The base URL for the Tampa REST API is:

http://api.tampa.onebusaway.org/api/

We recommend you use the JSON format for API responses, instead of XML.

An example request to retrieve all transit agencies that this OBA instance covers formatted via JSON is:

http://api.tampa.onebusaway.org/api/api/where/agencies-with-coverage.json?key=ADD_YOUR_KEY_HERE

...where ADD_YOUR_KEY_HERE is replaced by the API key you receive from OBA Tampa administrators.

An example request to retrieve estimated arrival information for bus stop ID 3105 formatted via JSON is:

http://api.tampa.onebusaway.org/api/api/where/arrivals-and-departures-for-stop/Hillsborough%20Area%20Regional%20Transit_3105.json?key=ADD_YOUR_KEY_HERE

...where ADD_YOUR_KEY_HERE is replaced by the API key you receive from OBA Tampa administrators.

SIRI (Service Interface for Real Time Information) is a standard covering a wide range of types of real-time information for public transportation. This standard has been adopted by the European standards-setting body CEN, and is not owned by any one vendor, public transportation agency or operator. It has been implemented in a growing number of different projects by vendors and agencies around Europe.

The SIRI API can be considered v3 of the OBA API. The open nature of this standard and its growing adoption were the two primary selling points to OneBusAway in the context of the open-architecture, standards-based OneBusAway project.

SIRI is not a simple standard, but it has a degree of elegance in it's complexity. Unlike GTFS and GTFS-RT, SIRI objects include layers of elements that are primarily designed to provide small pieces of information. SIRI can be thought of as a menu; having picked a few items from that menu, we feel the results are simple and legible, if a bit verbose. If you are curious to read about all of the features of SIRI, the SIRI Handbook makes for a bit of light reading.

One thing SIRI did not (originally) cover is the "distance away" (rather than time-based predictions) concept that we have introduced in this project. Fortunately, SIRI is an extensible standard so we were able to make it work for this project. A later version of SIRI corrects this oversight -- expect a patch in the near future. As well, while SIRI requests are typically SOAP requests sent via HTTP POST, in this case we implemented a slimmed-down RESTful interface using HTTP GET requests.

The SIRI web service calls implemented by OneBusAway are:

• VehicleMonitoring: real-time information about one, many, or all vehicles tracked by the system.
• StopMonitoring: real-time information about vehicles serving a particular stop.

The results of these two calls have many of the same elements; they simply represent different slices through the same pie.

While the SIRI standard specifies XML as an interchange format, it incurs a substantial penalty in data-transfer and processing requirements. In contrast, JSON (Javascript Object Notation) is a lightweight data-interchange format. Human-readable, lightweight, and easy to parse, JSON offers an alternative. Thus, OneBusAway provides both XML and JSON versions of its API.

All IDs (tripIDs, stopIDs, etc.) for the above real-time data match with HART's static GTFS data. You can download HART's GTFS data from HART's website. Check out the GTFS Reference page for more info on GTFS format.