GTFS-ContinuousStops

[timMillet]

Context

Currently, the GTFS specification does not handle continuous pickup and drop off, i.e when riders can board or alight a vehicle anywhere along the route alignment. Continuous-stop services are mainly operated by transit agencies serving rural areas, where distances for reaching an actual stop by foot are considered as too long, and where population density is too low to add many stops.

In the GTFS-ContinuousStops proposal available at http://bit.ly/gtfs-continuous-stops, 2 main examples are given:

• Pickup and drop-off everywhere: The Current (Rockingham, US-VT) applies a continuous-stop policy on many routes. A rider may request to be picked up and dropped off between scheduled stops all along the route, as soon as there is a safe place for the bus to stop.
• Continuous stops on part of the route: Victor Valley Transit (Victorville, US-CA) applies a continuous-stop policy on some sections of route 22. A rider may board and get off the bus in any safe location only when the vehicle is running outside of Victorville’s city limits.

GTFS-ContinuousStops is an updated version of PR #41. It is also a subset of the broader extension project GTFS-Flex (v2), which has been elaborated with the aim that the GTFS specification could support a variety of on-demand services. GTFS-Flex (v2) is accessible at http://bit.ly/gtfs-flex-v2; all comments are welcome.

Pull Request

This pull request includes 4 new enum fields:

• routes.continuous_pickup
• routes.continuous_drop_off
• stop_times.continuous_pickup
• stop_times.continuous_drop_off

For consistency reasons, the 4 enums would be the same as the one of the fields stop_times.pickup_type and stop_times.drop_off_type. The only difference would be the meaning of an empty field: equal to 1 (either “No continuous stopping pickup” or “No continuous stopping drop off”) for reflecting that continuous stop is not a behavior by default. In this way, the regular scheduled pickups and drop offs would remain the behaviors by default.

continuous_pickup and continuous_drop_off would be proposed at the route and stop_time levels, because the use cases showed that continuous-stop behaviors are permitted for all trips, either all along the route alignment or on a section of it. We have not found examples where continuous-stop behaviors were permitted all along the route alignment on some trips only, which would have led to suggest the addition of the same fields at the trip level.

Also, a modification would be made to the field trips.shape_id that would be conditionally required: required only if a continuous-stop behavior is defined. The purpose of this modification is to provide the route alignment on which the continuous-stop behavior is allowed.

Open Question: Is continuous_pickup=0 needed?
While searching for examples, I noticed that most of the transit agencies with continuous-stop services were asking riders to wave at the bus driver for requesting to be picked up. This behavior can be assimilated as continuous_pickup=3. I’m having difficulties envisioning a continuous-stop situation where the way to request a stop would be different from “must phone/contact the agency” or “must coordinate with driver”, and in this case, continuous_pickup=0 would not be needed. However, continuous_pickup=0 could still be useful when continuous pickup rules are unknown.

Don’t hesitate to provide me with your feedback on this proposal!

[flocsy]

I find the enum values confusing and unusual. I am against having 0 with the meaning of "has continous pickup".
Would be more logical to say: empty or 0 means: "no continous pickup"
1 means: "arrange with the driver (wave your hand)"
2 means: "phone agency to arrange"

[tsherlockcraig]

enum values confusing and unusual.

I don't disagree, and the approach you suggest or something like it was considered in earlier spec discussions. The reason why this model was put forth was to maintain symmetry with the pickup_type and drop_off_type fields. Of course there is a limit to that symmetry, because 1 or blank is the "default" value.

On our end as a producer of this spec, we'd certainly be happy to make this trivial change to our data export if more members of the community thought this should be revised. I don't have a strong opinion as to which is better. I do think consistency with pickup_type and drop_off_type is a valid concern too.

[skinkie]

-1

I don't like this proposal because it introduces a virtual link (stop to stop) between stops. But what it wants to model is a stop as a link. The latter can also be used with train stations where it is possible to board allong side of a platform. I would have to think about a proper counter proposal, but given the crisis that is happening now I have other priorities.

[paulswartz]

MBTA uses a version of this for our trip planner, and have plans to incorporate it into our public GTFS feed. The only values we use are:

• 0 (along with pickup_type/drop_off_type 3): allowed between this stop and the next stop
• 0 (along with pickup_type 2/drop_off_type 3): allowed between stops, but if you want to be picked up you need to call ahead (vehicle will not travel the stop if not requested)
• empty: not allowed

[tsherlockcraig]

@skinkie I don't quite understand the point you're making. Are you suggesting that there should be an entity introduced that refers to the boardable segment of the alignment, as opposed to referencing that segment implicitly through reference to a pre-existing entity (ie the stops on either side of the segment)?

[skinkie]

@thomastrillium I don't think a new entity should be introduced. But the stop entity should be extended, with a path (for example a linestring). Also: consider the huge amount of data wasted to do this per stop_time. But it might well be that we are talking about completely different scenarios, where the entire path can be boarded.

[tsherlockcraig]

Thanks for the explanation @skinkie .

The model of providing a linestring for the boarding area is another approach that has been considered for hail-and-ride services, and is included in the "GTFS-flex v2 draft" as a use of locations.geojson.

I think the reason why this formulation of the proposal sifted to the top though is two fold:

1. this reflects how service is structured in many of the example routes we're working with. There are fixed stops in these services, and then additionally there is the policy that the bus will pull over for you if you wave at it from a safe location. This is different than a boarding area.
2. Contrary to the data waste argument, this seems compact and simple relative to the alternative. This adds one optional column with a simple value in it to stop_times. If the value is the same throughout all trips of the route, the field is also added in routes.txt where one value can define this policy for all service on the route (unless overridden in stop_times.txt).

Interested in hearing the opinions of the community. Note the earlier PR @timMillet refers to received a number of +1 votes and no -1 votes. Worth reviewing that discussion: #41

[aababilov]

Thanks for a very detailed explanation, @thomastrillium

Google uses this proposal for a bunch of feeds and it works well for several cities. The GTFS data remains compact: there is a usual shape (in shapes.txt) to describe trip geometry and several stop_times to describe fixed stops along the trip.

[timMillet]

I’m noticing that the conversation around this proposal has not evolved for more than a month now. We may have reached a consensus in favor of this proposal, as nobody has responded to the suggestion to revise the enum values or has opposed the last comment about the data representation.

Since 2 data producers and 1 data consumer have already implemented changes related to this pull request (and another data producer has plans to incorporate it into its public feed), I’m calling for a vote.

• Producer: Trillium [Datasets] and TriMet [Dataset]
• Consumer: Google

The vote will be open until Wednesday, May 13th at 23:59:59 UTC.

[skinkie]

Based on the comment of @thomastrillium: +1 OpenGeo (will be likely to produce this, we have some product formula's that match this)

[abertuca]

+1 Google

[brodyFlannigan]

+1 from Brody Flannigan Transit Data (on behalf of Transcollines)

Thanks to all the contributors making GTFS awesomer every day!

[tsherlockcraig]

+1 from Trillium

[paulswartz]

+1 from @mbta

[timMillet]

The voting period has ended and the proposal is now adopted!

Producer: Trillium and TriMet
Consumer: Google

5 votes in favor:
@skinkie from OpenGeo
@abertuca from Google
@dudebrains01 from Brody Flannigan Transit Data (on behalf of Transcollines)
@thomastrillium from Trillium
@paulswartz from MBTA

No abstentions and vetos.
I'll merge!