Proposal: Simple method for defining flexible boarding along a route

[Neil Taylor]

Hi All

Here's a simple proposal for defining whether services along a route operate on a formal stop and schedule basis or a less formal 'flexible' basis when it comes to passenger boarding and alighting': https://docs.google.com/document/d/1UjDV6g94-vJnREUDXr9mLkyCCgj48pin__yC97DSoBs/edit?usp=sharing

It was developed as an output of a small-group discussion at the 'GTFS for the Rest of Us' event convened in Washington DC on Nov 12th, which focused on how minor changes to the GTFS Spec could make it easier for transportation authorities developing GTFS feeds for the purposes of enhancing public transport information / transportation planning.  The proposal aims to make GTFS more relevant in cities where a large proportion of road-based transit services are run on a more flexible basis than elsewhere in the world, and often represent the most significant portion of a city's transit ridership mode-share.  

We focused on flexible boarding as an issue, since it was clearly common across the contexts discussed at the event on 12/11/13.  In preparing the proposal we are mindful of the deeper work being undertaken by the GTFS Flexible Working Group (who I'm pleased to say were represented at the event and in the technical discussion around the spec), and see this as a short-term change to the GTFS spec, which paves the way for a more complex suite of proposals they are currently working on.

Please post any comments or possible reasons why this could not be adopted into this discussion topic, and feel free to edit the Google doc to demonstrate your suggestions.  It is worth noting that we were mindful not to break backwards-compatibility of GTFS when defining this proposal, and feel this remains quite important if  this change is likely to be adopted quickly (as we hope it will!).

Cheers

Neil

[Brian Ferris]

I've updated the proposal doc with some ideas for modeling continuous boarding / alighting behavior as discussed in the GTFS Flexibe WG:

 Flexible Public Transportation Services in GTFS

I'm wondering if the proposal might need some work around different pickup/dropoff semantics.

--
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-changes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/10ca3c84-60fb-4d94-82a3-c5487e6630fd%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Becker, Jeff]

Denver RTD has 22 flexible service areas AKA Call-n-Rides that includes every type of characteristic in the doc except route deviation, plus, perhaps, a few other characteristics: please see http://www.rtd-denver.com/callNRide.shtml.  Fifteen of these have scheduled checkpoints that coincide with bus stops or rail stations to facilitate connections to the transit network.  I’m going to need some time to see how our data would fit the current proposal and make suggested changes.

 

Brian – Could you add Jonathan Wade (jonath...@rtd-denver.com) to our group?  He is our Service Development Support manager and GTFS guru for both fixed-route and flexible services and will be able to contribute significantly regarding data availability and use.

 

Happy Thanksgiving everyone!

 

A. Jeff Becker | Senior Manager of Service Development | Regional Transportation District | 303-299-2148

To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/CAG9YwWCYEjMMT1Etr5y7fJi%2BX%3DVMXCg3SahpVCbWOqxoVeLmQg%40mail.gmail.com.

[Mike Gilligan (TriMet)]

I have added `continuous_stops` to TriMet's stop_times.txt. Our route 84 allows pickups/dropoffs anywhere along select rural segments.

[Aaron Antrim]

Consider the following scenarios, which cannot be described with the continuous_stops field:

• Service to declared stops is regularly scheduled, but request (continuous) stops that can only be requested from on-board the vehicle. The request stop service will not pick up passengers.
• Request pickup that must be requested in advance (by phone)

I suggest is to borrow from the existing pickup_type and dropoff_type fields. Here are two ideas:

1. Split continuous_stops into two fields: continuous_stops_drop_off and continuous_stops_pickup. Values of digits 0-3 would indicate the same meaning as for the existing drop_off_type and pickup_type fields (https://developers.google.com/transit/gtfs/reference#stop_times_fields). I think this is what I would prefer.
2. Just add one field, continuous_stops, but define additional possible values. e.g. "32" indicates the passenger must request drop-off from the driver and that one must phone the agency for pickup. "31" indicates the passenger must coordinate with the driver for drop-off but that there is no pickup available.

Thoughts? Other ideas?

[Mike Gilligan (TriMet)]

Thinking about Aaron's proposed changes, I have a 3rd option for representing the pick-up/drop-off rules along a flexible passenger route.

In combination with continuous_stops, add pickup_type and drop_off_type as optional fields within shapes.txt. Possible values would be the same as stop_times.txt. These fields would allow the provider to adjust pickup_type and drop_off_type rules along the pattern without having to insert "dummy" stop_times.

[Aaron Antrim]

+1 to Mike's idea. It keeps stop_times.txt clean, even in cases where a lot of granularity is expressed.

--

You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-changes...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/aae5c7a8-5224-4ceb-b551-8b6598523523%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.