Modeling bus shuttles and other replacement service in GTFS

89 views
Skip to first unread message

Developer at MBTA

unread,
Dec 13, 2017, 2:45:04 PM12/13/17
to MBTA Developers
Dear Developers,

We've gotten some questions lately about how we're representing shutttle buses and other replacement bus service for subway and commuter rail in GTFS and the API. We'd like to talk about what we've tried, what we've learned, and what we propose to do moving forward; and most importantly we'd like your feedback about the best way forward.

Our goals in producing GTFS data are to represent MBTA service as accurately, clearly, and usably as possible using everything available as part of the specification; and to add our own "experimental" fields or files that consumers of the feed can optionally use to improve their representation of our service beyond that.  

"Rail replacement bus" isn't a concept addressed in the GTFS specification, and for a long time we just scheduled regular service and left shuttle information to alerts. Then, since this August, we trialed the modeling of planned shuttles in GTFS by using our experimental trip_route_type field in trips.txt to designate a trip on a route which would not operate on its typical mode. For subway routes which had a shuttled segment replacing normal rail service, we have split the regularly-scheduled trips into the rail and shuttle bus segments. The bus shuttle segments, scheduled to the same route_id as the rail trips, were given an additional running time to the latter, as well as a value of 3 for trip_route_type. So if there was a shuttle from Wonderland to Orient Heights, the Blue Line (route_id Blue) still had service from end to end, but broken into twice as many trips, one of which had a trip_route_type of 3 and longer running times than it normally would. 

At first we used the same stop_id's. Then, over the past month, we have begun scheduling the stop times for these subway shuttle trip to bus stops on the street (whether existing bus stops or temporary ones). This was even better, now the feed contained information about where customers should really go to board shuttle service, even if it's a couple blocks from the normal station. But this is where we ran into trouble. It taught us that mixing services from normal bus routes and subway routes at the same stop_ids causes difficulties for many feed consumers. For example, should a bus stop serving bus trips on route_id “Red” and other local bus routes be labeled as a bus stop or a subway station? In building a map of the Orange Line, which stops are actual stations and which ones aren't? How can GTFS users identify the difference without using our experimental trip_route_type field?

We now think to have the most accurate, clear, and usable data possible, we need to give bus shuttles their own route_id's. These routes will contain the same properties in routes.txt as our other bus services except that the route name will indicate it is a shuttle and route_desc will have a new value of “Rail Replacement Bus”. The stop_id's will represent the actual locations where one can board or exit the shuttle. 

Unfortunately this removes the association of the shuttle route with the subway or commuter rail route. For those who want to use our experimental extensions, we can leverage an existing one to solve that problem: multi_route_trips.txt. This file can indicate that when showing information about route_id "Red" service, information about every trip in route_id "Shuttle005" service should be presented as well, as honorary Red Line service.

Our plan is to make this change for subway shuttles first, then for commuter rail shuttles in the future. We'll temporarily continue to use trip_route_type for the subway shuttle routes.  

This sample GTFS file implements these changes: 

Would this change be beneficial? Harmful? Are there adjustments that would improve it, other approaches we should consider, or a solution to this in use elsewhere that we've missed? 

Thanks for your thoughts on this and for helping us publish the best data we can.

Sincerely,
developer@mbta

Developer at MBTA

unread,
Dec 18, 2017, 12:28:22 PM12/18/17
to MBTA Developers
Update: we're going to proceed with this change with a new GTFS feed which we'll deploy on Wednesday. 

Sincerely,
developer@mbta

Developer at MBTA

unread,
Dec 20, 2017, 5:33:57 PM12/20/17
to MBTA Developers
Update: We've decided to push this back at least a day.

Sincerely,
developer@mbta

Developer at MBTA

unread,
Dec 22, 2017, 8:19:12 AM12/22/17
to MBTA Developers
The changes discussed above are now live in our GTFS file available for download. With this being said, we welcome any feedback from our data consumers about these changes or the modeling of bus shuttles in general.

Sincerely,
developer@mbta
Reply all
Reply to author
Forward
0 new messages