Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 12 additions & 12 deletions MBTA-realtime API README.md → README.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,9 +3,9 @@ Introducing: The new MBTA-realtime API

The new MBTA-realtime v2 API integrates predictions and alerts together for MBTA subway, commuter rail, and bus. The API supports new formats, calls and fields to make it easier than ever to develop a wide variety of applications using MBTA data.

As of August 5th 2014 The new API is now in production. New documentation and access instructions are available at [http://realtime.mbta.com].

The data challenge started before development was complete, so we set up special instance running test data. That is still available, and instructions for accessing it are in the "original MBTA-realtime docs" directory. However now that the API is in production there isn�t a real advantage in using the preview server.
As of August 5th 2014 The new API is now in production. New documentation and access instructions are available at [http://realtime.mbta.com].
The data challenge started before development was complete, so we set up special instance running test data. That is still available, and instructions for accessing it are in the "original MBTA-realtime docs" directory. However now that the API is in production there isnÕt a real advantage in using the preview server.

New Formats
-----------
Expand All @@ -21,11 +21,11 @@ The API supports five new calls.

*vehiclesbyroute* and *vehiclesbystop* give vehicle locations only for all service on a route or for a specific trip.

The data returned is organized the same way for both calls, and is much like the existing schedule calls: by mode, then route, then direction, then trip, then stop. IDs and text descriptions are given in each case.
The data returned is organized the same way for both calls, and is much like the existing schedule calls: by mode, then route, then direction, then trip, then stop. IDs and text descriptions are given in each case.

The prediction data includes scheduled arrival and departure time, predicted actual time, and predicted number of seconds away from right now. The vehicle location data includes latitude, longitude, bearing (if known), speed (if known), and a timestamp.

Finally, if there are alerts that affect the service, the IDs and headers of those alerts are included in the prediction call.
Finally, if there are alerts that affect the service, the IDs and headers of those alerts are included in the prediction call.

New Parameters for Existing Calls
---------------------------------
Expand Down Expand Up @@ -100,7 +100,7 @@ The following is a list of new fields in the alerts calls:
</td>
<td width="400" valign="top">
<p>
Buses replacing Green Line C service btn Coolidge Cnr &amp; Cleveland Cir fm Sat Jun 21 through Sun Jun 22. Connect to D branch at
· Buses replacing Green Line C service btn Coolidge Cnr &amp; Cleveland Cir fm Sat Jun 21 through Sun Jun 22. Connect to D branch at
Cleveland Cir
</p>
</td>
Expand Down Expand Up @@ -174,7 +174,7 @@ The following is a list of new fields in the alerts calls:
</td>
<td width="400" valign="top">
<p>
Shuttle buses replacing Red Line service between Harvard Station and Andrew Station. Seek alternate routes if possible.
· Shuttle buses replacing Red Line service between Harvard Station and Andrew Station. Seek alternate routes if possible.
</p>
</td>
</tr>
Expand Down Expand Up @@ -233,15 +233,15 @@ The following is a list of new fields in the alerts calls:
</table>
<p>

_Example of Route_hide: Route_hide is generally for what the MBTA calls hybrid routes, like route 62/76, which is a combination of route 62 and route 76 that runs on Saturdays. Route 62 and route 76 and route 62/76 are three separate routes in GTFS, but to a rider a route 62/76 trip is a trip on both route 62 and route 76. So if a detour affects route 62 and route 62/76 it isnt necessary to specify to the user that its affecting route 62/76, thats implicit as long as you specify that its affecting route 62._
_Example of Route_hide: Route_hide is generally for what the MBTA calls hybrid routes, like route 62/76, which is a combination of route 62 and route 76 that runs on Saturdays. Route 62 and route 76 and route 62/76 are three separate routes in GTFS, but to a rider a route 62/76 trip is a trip on both route 62 and route 76. So if a detour affects route 62 and route 62/76 it isnt necessary to specify to the user that its affecting route 62/76, thats implicit as long as you specify that its affecting route 62._

Other Changes
-------------
XML header changed to include data that is technically optional but which some parsers expect.

No more empty strings � if a field isn�t applicable it�s not included.
No more empty strings – if a field isn’t applicable it’s not included.

You can use a parent_stop for a stop parameter. You can request predictions for South Station parent stop ID “place-sstat” and get predictions for all subway, bus, and commuter rail departures from South Station with one call.

You can use a parent_stop for a stop parameter. You can request predictions for South Station parent stop ID �place-sstat� and get predictions for all subway, bus, and commuter rail departures from South Station with one call.

Go to [http://realtime.mbta.com] to learn more.
Go to [http://realtime.mbta.com] to learn more.
--------------