##Flexible Public Transportation Services in GTFS
###Table of Contents
###Point Deviation
The existing GTFS assumes that stops are served in an order, defined by stop_sequence. In order to describe a point-deviation service, specification needs the capability to override this assumption.
Proposed: A new field in stop_times.txt, unordered.
| Field Name | Required? | Details |
|---|---|---|
| unordered | Optional | Consecutive values of 1 indicate a block of stops (deviation points) are not served in a predetermined order. This block is interrupted by a 0 value. Empty or other values are presumed to be 0. |
Note that if a shape_id is specified for a trip that includes stops where unordered = 1, then shape_dist_traveled must be specified in stop_times.txt and shapes.txt. The correspondence of shape_dist_traveled values must make it clear that there is no alignment specified for the block of deviation points.
###Defining Areas
A key concept in flexible services is the idea of a service area or zone. These zones are used define the region where demand-response operation is in effect. We propose a model for defining these regions in GTFS. Because “zone” also tends to get conflated with discussions of fare systems, we propose calling general polygons “areas”. As such, we propose introducing a new file, areas.txt, with the following fields:
| Field Name | Required? | Details |
|---|---|---|
| id | Required | The id field contains an ID that uniquely identifies an area. |
| lat | Required | The lat field specifies the latitude of a single point in the area’s polygon. The field value must be a valid WGS84 latitude. |
| lon | Required | The lon field specifies the longitude of a single point in the area’s polygon. The field value must be a valid WGS84 longitude. |
| sequence | Required | The sequence field associates the latitude and longitude of a single point with its sequence order in the area’s polygon. The value of sequence must be a non-negative integers and must increase sequentially between each point in the polygon. |
Basically, areas.txt provides a mechanism for defining polygon regions, identified by id. The coordinates for areas must be specified in counterclockwise order. Areas follow the "right-hand rule," which states that if you place the fingers of your right hand in the direction in which the coordinates are specified, your thumb points in the general direction of the geometric normal for the polygon.
###Route Deviation
As discussed, flexible routes can use service areas and zones in a variety of ways. Some routes provide demand-response services with a single fixed zone, while others offer regions of flexible services along an otherwise fixed route, while yet others use combinations of the two.
To support this flexibility in GTFS, we propose augmenting the functionality of stop_times.txt by allowing a provider to associate service areas with particular stop-time entry.
Specifically, we propose the following additions to stop_times.txt:
| Field Name | Required? | Details |
|---|---|---|
| start_service_area_id | Optional | The start_service_area_id specifies the id of a service area defined in the areas.txt file. When specified for a stop-time entry, it indicates the beginning of service in the specified service area and that the transit vehicle may potentially pick-up or drop-off passenger anywhere in the specified service area, as controlled by the pickup_type and drop_off_type fields. Must be followed by a corresponding stop-time entry in the trip with a matching end_service_area_id value. |
| end_service_area_id | Optional | The end_service_area_id specifies the id of a service area defined in the areas.txt file. When specified for a stop-time entry, it indicates the end of service in the specified service area. Must be preceded by a corresponding stop-time entry in the trip with a matching start_service_area_id value. The pickup_type and drop_off_type fields will be ignored for this stop-time entry. |
| start_service_area_radius | Optional | The start_service_area_radius field provides a convenient way to construct a service area without the need to define an area in areas.txt. When specified, it indicates a distance in meters from the main path of travel for the trip where service is offered. The trip must specify a shape_id if start_service_area_radius is specified. The start_service_area_radius field has the same semantics as start_service_area_id in terms of pickup/dropoff semantics. |
| end_service_area_radius | Optional | The end_service_area_radius specifies the end of an area started by a stop-time entry with a start_service_area_radius field. Must be preceded by a corresponding stop-time entry in the trip with the same start_service_area_radius value. The pickup_type and drop_off_type fields will be ignored for this stop-time entry. |
Regarding stop_id, two possibilities:
- We allow stop_id to be empty when start_service_area_id has been specified. This breaks the idea that stop_id is always required, but is conceptually cleaner.
- We still require stop_id to be specified. It should specify a stop at the center of the service area and might be used to provide additional data for the service area (name? url? fare zone?).
Regarding arrival_time and departure_time, these fields can be used to specify rough timing information for a route deviation or flexible route segment relative to other parts of the route, or can be left blank if it’s not the first or last stop-time in the trip. If a time is specified, it indicates when service begins in the area.
###Request Stops
Many transit systems allow riders to board or alight from a transit vehicle at any location along a route. Alternatively known as “flag stop”, riders can flag down a vehicle at locations other than fixed stops.
At the GTFS For the Rest of Us Workshop in Washington, DC (Nov 2013), we came up with a proposal for specifying request stops called “continuous stops”. In this proposal, a route can be annotated as supported continuous stops, such that a rider can board or alight from a transit vehicle at any point along the route, as determined by the route’s shape. See the proposal doc for more details.
One scenario that we did not tackle during the workshop was support for “request stops” for sub-sections of a route. We’d now like to propose such a mechanism with the following new fields in stop_times.txt:
| Field Name | Required? | Details |
|---|---|---|
| continuous_stops | Optional | The continuous_stops field can be used to indicate a section of a trip where it is possible to board or alight from the transit vehicle at any point along the vehicle’s path of travel. |
The continuous_stops field can have the following non-negative integer values:
- 0 or blank - Normal stop behaviour along route (default).
- 1 - Continuous stopping behaviour from this stop-time to the next stop-time in the trip’s sequence.
If specified as 1, a valid shape must be defined for the trip, in order to indicate the complete path of travel.
###Defining Service Parameters
Demand-responsive transportation services have parameters for request requirements and expected or maximum travel times. Below are additions to the trips.txt file that define parameters for the demand-responsive service portions of that trip.
| Field Name | Required? | Details |
|---|---|---|
| drt_max_travel_time | Optional | Defines maximum travel time for a demand-responsive passenger travel leg on the trip. This time may be expressed as a value (minutes), or as an arithmetic function where t=[direct travel time]. For example, the formula t*2.5+5 indicates that the maximum travel time for the passenger's demand-responsive travel leg is 30 minutes if the direct travel time is 10 minutes. |
| drt_avg_travel_time | Optional | Defines average or expected travel time demand-responsive passenger travel leg on the trip. Values or functions are expressed in the same way as drt_max_travel_time. |
| drt_advance_book_min | Optional | Minutes of advance time necessary before travel to make booking request. |
Alternative consideration: These service parameters could be included in areas.txt or stop_times.txt for more granular specificity.
###Examples
#####Point Deviation, Scheduled Start and Endpoints
The service includes 4 untimed points (Stops B, C, D, and E), which are not served in a predefined order. Riders are required to call the agency in advance to coordinate pickup and dropoff at these stops. The vehicle is regularly scheduled to begin at StopA and return to StopA 30 minutes later.
| trip_id | TripX | TripX | TripX | TripX | TripX | TripX |
| stop_id | StopA | StopB | StopC | StopD | StopE | StopA |
| stop_sequence | 0 | 1 | 2 | 3 | 4 | 5 |
| unordered | 0 | 1 | 1 | 1 | 1 | 0 |
| arrival_time | 09:00:00 | 9:30 | ||||
| departure_time | 09:00:00 | 9:30 | ||||
| pickup_type | 2 | 2 | 2 | 2 | ||
| drop_off_type | 2 | 2 | 2 | 2 |
#####Single Zone, No Defined Stops
Let’s consider an agency operating a route with a single demand-response zone. Riders are required to call the agency in advance to coordinate pickup and dropoff.
In this case, the agency defines a service area in areas.txt with id AreaX. The agency also defines a trip in trips.txt with id TripX. We also add two entries to stop_times.txt:
| trip_id | TripX | TripX |
| stop_id | StopX | StopX |
| stop_sequence | 0 | 1 |
| arrival_time | 09:00:00 | 17:00:00 |
| departure_time | 09:00:00 | 17:00:00 |
| start_service_area_id | AreaX | |
| end_service_area_id | AreaX | |
| pickup_type | 2 | |
| drop_off_type | 2 |
These two stop-time entries start service in AreaX at 9 am and stop service in the area at 5 pm. Riders are required to call the agency in advance to coordinate pickup and dropoff.
#####Single Zone, Defined Endpoints
Let’s now consider an agency operating a route with a single demand-response that has a regular start and end point. In this case, StopX and StopZ are the start and end stops, and AreaX is the service area served in-between.
| trip_id | TripX | TripX | TripX | TripX |
| stop_id | StopX | StopY | StopY | StopZ |
| stop_sequence | 0 | 1 | 2 | 3 |
| arrival_time | 09:00:00 | 10:00:00 | ||
| departure_time | 09:00:00 | 10:00:00 | ||
| start_service_area_id | AreaX | |||
| end_service_area_id | AreaX | |||
| pickup_type | 2 | |||
| drop_off_type | 2 |
#####Multiple Zones and Intermediate Stops
In this case, the agency builds on the previous example, but now defines a mix of normal stop-time and service-area stop-time entries in stop_times.txt:
| trip_id | TripX | TripX | TripX | TripX | TripX | TripX | TripX |
| stop_id | StopA | StopB | StopB | StopC | StopD | StopD | StopE |
| stop_sequence | 0 | 1 | 2 | 3 | 4 | 5 | 6 |
| arrival_time | 09:00:00 | 09:30:00 | 10:00:00 | ||||
| departure_time | 09:00:00 | 09:30:00 | 10:00:00 | ||||
| start_service_area_id | AreaX | ||||||
| end_service_area_id | AreaX | AreaY | |||||
| pickup_type | 3 | 3 | |||||
| drop_off_type | 3 | 3 |
In this example, the transit vehicle starts at fixed-stop StopA, travels through service area AreaX, stops at fixed-stop StopC, travels through service area AreaY, and finishes service at fixed-stop StopE.
#####Intermediate Stops Within Zones
In this case, the agency has a fixed start and end stop, a flexible zone between those stops, and fixed stops within the flexible zone.
| trip_id | TripX | TripX | TripX | TripX | TripX |
| stop_id | StopA | StopB | StopC | StopB | StopD |
| stop_sequence | 0 | 1 | 2 | 3 | 4 |
| arrival_time | 09:00:00 | 09:30:00 | 10:00:00 | ||
| departure_time | 09:00:00 | 09:30:00 | 10:00:00 | ||
| start_service_area_id | AreaX | ||||
| end_service_area_id | AreaX | ||||
| pickup_type | 3 | ||||
| drop_off_type | 3 |
#####Radius-Based Zones
Some agencies have a simple methodology for defining demand-response service areas. The zone is typically defined as a particular distance from the base route (eg. ½ mile). For agencies that don’t want to maintain the actual geometry for that corridor, the start_service_area_radius and end_service_area_radius fields offer a simple way to define a service area.
In the following example, an agency defines a ½ mile (~800 meter) flexible service area around their base route. For this technique to work, the trip with id TripX must also specify a shape_id value indicating the path of travel.
| trip_id | TripX | TripX | TripX | TripX |
| stop_id | StopX | StopY | StopY | StopZ |
| stop_sequence | 0 | 1 | 2 | 3 |
| arrival_time | 09:00:00 | 10:00:00 | ||
| departure_time | 09:00:00 | 10:00:00 | ||
| start_service_area_radius | 800 | |||
| end_service_area_radius | 800 | |||
| pickup_type | 2 | |||
| drop_off_type | 2 |
#####Advanced
The Cape Cod RTA operates a flex route between Harwich and Provincetown that combines a number of aspects of flexible service: route deviation, request stops, flexible-route segments, etc.
We can combine the new fields we have defined, including start_service_area_radius, end_service_area_radius, and continuous_stops, to concisely represent this route and all its flexible characteristics.