From f164c64196eb8864d71090a5f3148adc1051a8d7 Mon Sep 17 00:00:00 2001 From: DaveBarker Date: Fri, 27 Jun 2014 13:42:47 -0400 Subject: [PATCH] Corrected parent stops parameter status --- MBTA-realtime API README.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/MBTA-realtime API README.md b/MBTA-realtime API README.md index f320509..50d89dd 100644 --- a/MBTA-realtime API README.md +++ b/MBTA-realtime API README.md @@ -28,11 +28,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 --------------------------------- @@ -66,10 +66,10 @@ All the parameters and fields are spelled out in the documentation, but if you j [http://54.81.189.97/developer/api/v2/vehiclesbyroute?api_key=wX9NwuHnZU2ToO7GmGR9uw&route=CR-Providence&format=json] [http://54.81.189.97/developer/api/v2/vehiclesbytrip?api_key=wX9NwuHnZU2ToO7GmGR9uw&trip=CR-Providence-CR-Weekday-Providence-Dec13-818&format=json] -And here is GTFS-realtime: -[http://developer.mbta.com/lib/GTRTFS/Alerts/Alerts.pb] -[http://developer.mbta.com/lib/GTRTFS/Alerts/TripUpdates.pb] -[http://developer.mbta.com/lib/GTRTFS/Alerts/VehiclePositions.pb] +And here is GTFS-realtime: +[http://developer.mbta.com/lib/GTRTFS/Alerts/Alerts.pb] +[http://developer.mbta.com/lib/GTRTFS/Alerts/TripUpdates.pb] +[http://developer.mbta.com/lib/GTRTFS/Alerts/VehiclePositions.pb] New Fields in Existing Alert Calls ---------------------------- @@ -134,7 +134,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

@@ -208,7 +208,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.

@@ -267,15 +267,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. In GTFS a station’s inbound platform, outbound platform, busway, etc. might be represented by different stop ID’s that all share the same “parent stop.” That means 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. +*(Coming soon)* You can use a parent_stop for a stop parameter. In GTFS a station�s inbound platform, outbound platform, busway, etc. might be represented by different stop ID�s that all share the same �parent stop.� That means 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. Sample Calls ------------ @@ -343,4 +343,4 @@ Sample Output -``` \ No newline at end of file +```