This directory contains the "Version 1" GTFS-flex specification and documentation. Data following the specification laid out in this repository can be found at http://vermont-gtfs.org, and is in use by the GoVermont Flexible Trip Planner. The trip planner utilizes the open source OpenTripPlanner, and the code for the flexible transit routing is currently (as of 2019-01-05) in the process of being merged into the coming OTP 1.4.
Drawing from the development of GTFS-flex data in Vermont, MobilityData has begun an effort to refine and propose changes to the GTFS specification following the objectives of the GTFS-flex project. This new work by MobilityData constitutes a "Version 2" of the spec, which is under development here. Discussion of the specification proposal should be centered on the text in that Google Document.
GTFS-flex is a proposed/prototype extension to the General Transit Feed Specification. GTFS-flex would add the capability to model various demand-responsive transportation (DRT) services to GTFS, which currently only models fixed-route public transportation. GTFS-flex is in a prototyping phase in which its capabilities to model transportation services are being tested and adapted. There is no software that currently consumes GTFS-flex data, though projects have been proposed.
Discussion and change proposals are strongly encouraged. Rapid iteration and prototyping at this stage is necessary to develop GTFS-flex. We have adopted the following change proposal process:
- Discussion and needs documentation occur in GitHub issue threads. Refer to and describe real DRT service features in order to develop and support needs for GTFS-flex modeling capabilities.
- Propose changes to the spec that refer to needs identified in GitHub issues spec.
- Create pull request to vote on changes to the prototype spec. The pull requester becomes advocate for the proposal.
- Over the course of 7 days, stakeholders vote on the pull requests. Constructive feedback or alternative suggestions are required with downvote.
- Pull requests with at least one +1 and no -1 are merged.
The above process is intended to begin tentative governance practices, and prevent spec bloat. Given that the GTFS-flex is in early prototype phase, speculative and experimental features are welcome.
Spec extension schematic diagram
The below shows updated and added files in GTFS-flex, compared to the current GTFS (original Google Drawing is here).
Background & Purpose
We’d like to better support modeling of flexible public transportation services in GTFS. For the purposes of this discussion, “flexible” services will be defined with regard to the following characteristics, as defined in TCRP Program Report #140 - A Guide for Planning and Operating Flexible Public Transportation Services:
- Route Deviation: vehicles operating on a regular schedule along a well-defined path, with or without marked bus stops, that deviate to serve demand-responsive requests within a zone around the path. The width or extent of the zone may be precisely established or flexible.
- Point Deviation: vehicles serving demand-responsive requests within a zone and also serving a limited number of stops within the zone without any regular path between the stops.
- Demand-Responsive Connector: vehicles operating in demand-responsive mode within a zone, with one or more scheduled transfer points that connect with a fixed-route network. A high percentage of ridership consists of trips to or from the transfer points.
- Request Stops: vehicles operating in conventional fixed-route, fixed-schedule mode and also serving a limited number of undefined stops along the route in response to passenger requests.
- Flexible-Route Segments: vehicles operating in conventional fixed-route, fixed-schedule mode, but switching to demand-responsive operation for a limited portion of the route.
- Zone Route: vehicles operating in demand-responsive mode along a corridor with established departure and arrival times at one or more end points in the zone.
The TCRP report catalogs a number of transit agencies across the US, evaluating how each agency uses flexible public transportation services in their own system. What’s clear from this analysis is that these agencies use a variety of techniques, picking and choosing from various strategies and flavors of flexible service when implementing their systems. Supporting all such services in GTFS will be tricky, but hopefully not impossible.