diff --git a/MBTA-realtime API README.md b/README.md similarity index 83% rename from MBTA-realtime API README.md rename to README.md index 7250226..9598b5e 100644 --- a/MBTA-realtime API README.md +++ b/README.md @@ -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 ----------- @@ -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 ID’s and headers of those alerts are included in the prediction call. +Finally, if there are alerts that affect the service, the ID’s and headers of those alerts are included in the prediction call. New Parameters for Existing Calls --------------------------------- @@ -100,7 +100,7 @@ The following is a list of new fields in the alerts calls:

- · Buses replacing Green Line C service btn Coolidge Cnr & Cleveland Cir fm Sat Jun 21 through Sun Jun 22. Connect to D branch at + · Buses replacing Green Line C service btn Coolidge Cnr & Cleveland Cir fm Sat Jun 21 through Sun Jun 22. Connect to D branch at Cleveland Cir

@@ -174,7 +174,7 @@ The following is a list of new fields in the alerts calls:

- · 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.

@@ -233,15 +233,15 @@ The following is a list of new fields in the alerts calls:

-_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 isn’t necessary to specify to the user that it’s affecting route 62/76, that’s implicit as long as you specify that it’s 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 isn’t necessary to specify to the user that it’s affecting route 62/76, that’s implicit as long as you specify that it’s 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. --------------