mobilitydata / gtfs-flex Goto Github PK

I noticed in reviewing a feed and the specification today, that we have the fields mean_duration_factor,mean_duration_offset,safe_duration_factor,safe_duration_offset indicated an conditionally forbidden, but optional otherwise.

Should these values be conditionally required in the case that the stop_time references a flex service location?

If not, we should state in the spec what the assumed default value is. The current spec mentions a default value between locations, but not a default value within locations.

I'm fine with either solution, though i lean towards making these conditionally required.

The bottom of the Readme refers to example implementations, but these links are broken.

via @keviniano, in the Google Doc comment

Some Ride Connection services only allow one deviation per passenger trip. We would need the capability to express this.

via @mgilligan, from comment in Google Doc

How would one define an area with a hole in the middle? For example, the TriMet service benefit area has a hole in Happy Valley, OR. Maybe defining the points as part of an interior vs. exterior ring (similar to KML).

For flexible services, applications may need to provide some written direction to users, explaining "stand by the side of the road and wave your arm".

For all flex services, these messages could probably be defined in application, but agencies may have a desire to phrase directions in a certain manner. Should agency.txt have an optional continuous_stop_notification text field that contains a message like

"Wait in safe area along route..." (see text in image below)

there might be a separate area_stop_notification that explains use of areas.

Consideration:

• would there need to be separate notifications for pickup and drop off? (probably)
• would there need to be separate notifications by route (probably)
• should all this ideally be automated by applications via picking up necessary text components from pre-existing fields (e.g. agency_phone or drt_advance_book_min
• if this is handled in application, what do we do if there are tiny disagreements on wording between agencies? is it just an app-by-app problem?

The current description of arrival and departure times reads as if there are times when the fields are simultaneously required and forbidden. The text regarding when they are required should be altered e.g. "required in the first and last stop of a trip, if there are no start_pickup_window... values" or something like that.

For the example feeds, I noticed some entries in the contents are empty. Is there documentation for what some of these mean? Like the trip.txt. Also, is there a way to apply these locally ?

As written, the Spec would allow multiple service areas to be activated in a single "trip" at the same time. i.e. a record in stop_times.txt with start_service_area_id='AreaX' immediately followed by another record where start_service_area_id='AreaY'. We have not provided any examples of this in the draft spec.

Question: Are there indeed cases where it would be useful to have this capability?

• If so, then let's better define this.
• If not, then let's think about removing this capability/simplifying.

I'm currently implementing the fields mean_duration_factor and mean_duration_offset and have a question about it being part of the stop time, rather than the trip: What happens when you have multiple factors/offsets in a trip?

Let me illustrate this with a sketch:

Does this mean that when the vehicle is inside zone 1 then the factor is 1.5 and when it enters zone 2 the factor then increases to 2.5 for the duration it is inside of it?

And a related question: since you need two lines in stop_times for a single flex zone, what happens when those two lines don't have the same duration/offset values?

cc @tsherlockcraig @westontrillium

We aspire toward backward compatibility with GTFS. How feasible is that? In what circumstances might it make sense to give that up, and how would that be managed?

Open thread for discussion and reference.

Is there a reason that start_pickup_dropoff_window is only allowed for locations of locations.geojson? To me it seems useful to have flexible service that have fixed stop.

Currently stop_times.arrival_time and .departure_time are forbidden if .stop_id refers to geojson areas. This is an ad-hoc way to say that arrival and departure times should not be defined for on-demand service, but does not capture point to point on demand service (i.e., point type polygons).

Therefore, a different approach should be considered for "hard coding" on-demand data in GTFS to avoid future conflicts.

Looks like the drt_pickup_message and drt_drop_off_message and their analogues with continuous stops are attempting to do two things at once: 1) Provide instructions, and 2) Indicate the announcement for the start and end of on request pickup and drop off along a trip.

From reviewing publications, publishers have used the attribute for both purposes.

I suggest adding an additional attribute with an "_announcement" suffix and clarifying the documentation since both these attributes are important for transit provides and passengers. Not doing so, also means developers cannot reliably present their values in a way that makes sense.

Let's link to the GTFS-flex projects in motion from the repo homepage!

e.g. OpenTripPlanner:
https://github.com/camsys/OpenTripPlanner/tree/vtrans-gtfsflex
https://trilliumtransit.com/2016/10/21/announcing-the-flexible-transit-trip-planner/
https://trilliumtransit.com/2017/03/10/flexible-trip-planner-update-project-kick-off/
https://trilliumtransit.com/2017/09/01/alpha-release-of-the-flexible-trip-planner/

And, draft GTFS-flex datasets.

GTFS-Flex v2 does not currently describe disallowed travel between or within locations. Can GTFS-TravelRestrictions be used in parallel to describe such restrictions in flexible service?

Has anyone ran into this problem or has a solution they currently implement?

Edit: Renamed issue from "Travel restrictions in GTFS Flex" to "Directional and non-directional service patterns"

In the upper half (GTFS model) of the comparison chart, background colors for optional and required files are swapped.

They are missing the "properties" key which is required.

Below image shows DRT options from Claremont, CA. (Credit: Selena Barlow, Transit Marketing)

This presents an issue in that travel between points outside of the DAR areas is not allowed (diagram below).

(Original - Google Drawing)

The way to model this presently would be to set up multiple "trips", each with service from the area to one of the outside points.

In GTFS-flex consuming trip planners, we'd need to prevent the trip planner from showing travel from Point A to B by traveling from Point A to the DAR Area, and then to Point B.

There is a shared aspect to the problem described for fixed-route GTFS ("Disallow transport between some stops in one trip") -- https://groups.google.com/d/topic/gtfs-changes/BK0hafXbeJ4/discussion

Add semantic versioning to README.md to distinguish the implied versions of the spec and make it easier to navigate.

Suggested description:

Versioning

Semantic versions are established by a git tag in the form of vX.Y where X.Y is the version name. Multiple changes (commits) may be batched into a single new release.

A whole integer increase is used for breaking changes (MAJOR changes). A decimal increase is used for non-breaking changes (MINOR changes or patches).

Breaking changes include:

• Removing or changing features.

Non-breaking changes include:

• Adding features.

Tag commits with versions:

• e1832cf as v2.0
• 2dd3802 as v1.0

Hello everyone,

in the documentation it says start_pickup_drop_off_window and end_pickup_drop_off_window are

• Required if stop_times.stop_id refers to stop_areas.area_id or id from locations.geojson.

To my understanding, this would mean that departures from areas always require an interval.
However, there are indeed on-demand services that run between two areas with fixed departure times.
Here is an example for area relations with fixed departures: https://www.vor.at/fileadmin/CONTENT/Downloads/Folder/Anrufsammeltaxi_Folder/AST_Infoblatt_MOSTI.pdf
I do understand that in reality the vehicle will start picking up passenger from that departure time on, but so do the operators that design there timetables in such a way.

Can someone clarify if this indeed currently not intended in GTFS-Flex or if I may have simply misunderstood it?

Currently, it would probably have to be solved in such a way that in this case the time window is filled with identical start and end times.

Thank You!

A constraint force direction is useful for unordered stops. This is to prevent traveling passengers backwards then forwards. The scenario is like this: We have a set of unordered stops that can be served in any order. However, once a customer trip is scheduled, for example, with pickup at stop C (stop sequence 3) and delivery at stop E (stop sequence 5), this trip cannot be interrupted with a pickup/delivery at stop B (stop sequence 2) or any stop with stop sequence < 3. The trip can be interrupted with a pickup/delivery at stop D (stop sequence 4). This constraint can be specified as special value of the field unordered (e.g. unordered = 2 means force direction) in stop_times.txt

When implementing Flex v2 support we noticed the following combination that we don't know how to interpret:

The feed available at http://oregon-gtfs.com/gtfs_data/lincolncounty-or-us/lincolncounty-or-us--flex-v2.zip contains the following stop_times for trip t_299275_b_26748_tn_0:

trip_id,arrival_time,departure_time,stop_id,stop_sequence,stop_headsign,pickup_type,drop_off_type,shape_dist_traveled,timepoint,start_service_area_id,end_service_area_id,start_service_area_radius,end_service_area_radius,continuous_pickup,continuous_drop_off,pickup_booking_rule_id,drop_off_booking_rule_id,min_arrival_time,max_departure_time,mean_duration_factor,mean_duration_offset,safe_duration_factor,safe_duration_offset
881:t_299275_b_26748_tn_0,,,radius_1207_s_16069_s_16024,1,,0,0,0,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
882:t_299275_b_26748_tn_0,,,radius_1207_s_16024_s_16025,2,,0,0,775.596266212284,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
883:t_299275_b_26748_tn_0,,,radius_1207_s_16025_s_16026,3,,0,0,1807.22190535612,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
884:t_299275_b_26748_tn_0,,,radius_1207_s_16026_s_2483495,4,,0,0,2766.28482550726,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
885:t_299275_b_26748_tn_0,,,radius_1207_s_2483495_s_29681,5,,0,0,5416.75044306174,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
886:t_299275_b_26748_tn_0,,,radius_1207_s_29681_s_16032,6,,0,0,6436.45201007476,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
887:t_299275_b_26748_tn_0,,,radius_1207_s_16032_s_2438933,7,,0,0,7576.71452995217,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
888:t_299275_b_26748_tn_0,,,radius_1207_s_2438933_s_16031,8,,0,0,8240.84195654157,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
889:t_299275_b_26748_tn_0,,,radius_1207_s_16031_s_16030,9,,0,0,8527.62288862872,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
890:t_299275_b_26748_tn_0,,,radius_1207_s_16030_s_16033,10,,0,0,8932.84679637186,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
891:t_299275_b_26748_tn_0,,,radius_1207_s_16033_s_16034,11,,0,0,9165.13404331625,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
892:t_299275_b_26748_tn_0,,,radius_1207_s_16034_s_15889,12,,0,0,9628.59060260394,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
893:t_299275_b_26748_tn_0,,,radius_1207_s_15889_s_16039,13,,0,0,10510.9386855591,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
894:t_299275_b_26748_tn_0,,,radius_1207_s_16039_s_16040,14,,0,0,11686.4154079233,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
895:t_299275_b_26748_tn_0,,,radius_1207_s_16040_s_16042,15,,0,0,12047.7835753043,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
896:t_299275_b_26748_tn_0,,,radius_1207_s_16042_s_16043,16,,0,0,12324.4604601439,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
897:t_299275_b_26748_tn_0,,,radius_1207_s_16043_s_16044,17,,0,0,12526.5458089135,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
898:t_299275_b_26748_tn_0,,,radius_1207_s_16044_s_16045,18,,0,0,12886.5424727922,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
899:t_299275_b_26748_tn_0,,,radius_1207_s_16045_s_15942,19,,0,0,13106.2063391676,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
900:t_299275_b_26748_tn_0,,,radius_1207_s_15942_s_16048,20,,0,0,15282.8820371869,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
901:t_299275_b_26748_tn_0,,,radius_1207_s_16048_s_2438934,21,,2,3,17060.1720314054,0,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
902:t_299275_b_26748_tn_0,,,radius_1207_s_2438934_s_16049,22,,0,0,18604.0056042532,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
903:t_299275_b_26748_tn_0,,,radius_1207_s_16049_s_16050,23,,0,0,19098.7301834617,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
904:t_299275_b_26748_tn_0,,,radius_1207_s_16050_s_16051,24,,0,0,19388.6880759922,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
905:t_299275_b_26748_tn_0,,,radius_1207_s_16051_s_16052,25,,0,0,20425.6382579853,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
906:t_299275_b_26748_tn_0,,,radius_1207_s_16052_s_16053,26,,0,0,20752.5347065814,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
907:t_299275_b_26748_tn_0,,,radius_1207_s_16053_s_833259,27,,0,0,21230.9536762786,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
908:t_299275_b_26748_tn_0,,,radius_1207_s_833259_s_16275,28,,0,0,23127.0336395412,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
909:t_299275_b_26748_tn_0,,,radius_1207_s_16275_s_16055,29,,0,0,23551.6916242021,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
910:t_299275_b_26748_tn_0,,,radius_1207_s_16055_s_16057,30,,0,0,23808.8722434897,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
911:t_299275_b_26748_tn_0,,,radius_1207_s_16057_s_16058,31,,0,0,24487.418244042,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
912:t_299275_b_26748_tn_0,,,radius_1207_s_16058_s_16059,32,,0,0,24680.6102514857,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
913:t_299275_b_26748_tn_0,,,radius_1207_s_16059_s_16060,33,,0,0,25614.1591340582,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
914:t_299275_b_26748_tn_0,,,radius_1207_s_16060_s_16061,34,,0,0,26256.131709164,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
915:t_299275_b_26748_tn_0,,,radius_1207_s_16061_s_16062,35,,0,0,27180.643659028,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
916:t_299275_b_26748_tn_0,,,radius_1207_s_16062_s_16063,36,,0,0,27686.863698439,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
917:t_299275_b_26748_tn_0,,,radius_1207_s_16063_s_15890,37,,0,0,28259.1890347633,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
918:t_299275_b_26748_tn_0,,,radius_1207_s_15890_s_2438932,38,,0,0,28886.6228332024,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
919:t_299275_b_26748_tn_0,,,radius_1207_s_2438932_s_16065,39,,2,3,29619.901749005,0,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
920:t_299275_b_26748_tn_0,,,radius_1207_s_16065_s_2483495,40,,0,0,30254.2525223819,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
921:t_299275_b_26748_tn_0,,,radius_1207_s_2483495_s_16066,41,,2,3,30838.8763853997,0,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
922:t_299275_b_26748_tn_0,,,radius_1207_s_16066_s_16068,42,,0,0,32312.2465968761,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
923:t_299275_b_26748_tn_0,,,radius_1207_s_16068_s_16069,43,,0,0,34898.4147967777,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
924:t_299275_b_26748_tn_0,,,radius_1207_s_16069_s_16069,44,,0,0,36360.0641114,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
881:t_299275_b_26748_tn_0,,,radius_1207_s_16069_s_16024,1,,0,0,0,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
882:t_299275_b_26748_tn_0,,,radius_1207_s_16024_s_16025,2,,0,0,775.596266212284,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
883:t_299275_b_26748_tn_0,,,radius_1207_s_16025_s_16026,3,,0,0,1807.22190535612,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
884:t_299275_b_26748_tn_0,,,radius_1207_s_16026_s_2483495,4,,0,0,2766.28482550726,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
885:t_299275_b_26748_tn_0,,,radius_1207_s_2483495_s_29681,5,,0,0,5416.75044306174,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
886:t_299275_b_26748_tn_0,,,radius_1207_s_29681_s_16032,6,,0,0,6436.45201007476,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
887:t_299275_b_26748_tn_0,,,radius_1207_s_16032_s_2438933,7,,0,0,7576.71452995217,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
888:t_299275_b_26748_tn_0,,,radius_1207_s_2438933_s_16031,8,,0,0,8240.84195654157,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
889:t_299275_b_26748_tn_0,,,radius_1207_s_16031_s_16030,9,,0,0,8527.62288862872,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
890:t_299275_b_26748_tn_0,,,radius_1207_s_16030_s_16033,10,,0,0,8932.84679637186,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
891:t_299275_b_26748_tn_0,,,radius_1207_s_16033_s_16034,11,,0,0,9165.13404331625,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
892:t_299275_b_26748_tn_0,,,radius_1207_s_16034_s_15889,12,,0,0,9628.59060260394,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
893:t_299275_b_26748_tn_0,,,radius_1207_s_15889_s_16039,13,,0,0,10510.9386855591,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
894:t_299275_b_26748_tn_0,,,radius_1207_s_16039_s_16040,14,,0,0,11686.4154079233,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
895:t_299275_b_26748_tn_0,,,radius_1207_s_16040_s_16042,15,,0,0,12047.7835753043,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
896:t_299275_b_26748_tn_0,,,radius_1207_s_16042_s_16043,16,,0,0,12324.4604601439,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
897:t_299275_b_26748_tn_0,,,radius_1207_s_16043_s_16044,17,,0,0,12526.5458089135,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
898:t_299275_b_26748_tn_0,,,radius_1207_s_16044_s_16045,18,,0,0,12886.5424727922,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
899:t_299275_b_26748_tn_0,,,radius_1207_s_16045_s_15942,19,,0,0,13106.2063391676,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
900:t_299275_b_26748_tn_0,,,radius_1207_s_15942_s_16048,20,,0,0,15282.8820371869,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
901:t_299275_b_26748_tn_0,,,radius_1207_s_16048_s_2438934,21,,2,3,17060.1720314054,0,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
902:t_299275_b_26748_tn_0,,,radius_1207_s_2438934_s_16049,22,,0,0,18604.0056042532,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
903:t_299275_b_26748_tn_0,,,radius_1207_s_16049_s_16050,23,,0,0,19098.7301834617,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
904:t_299275_b_26748_tn_0,,,radius_1207_s_16050_s_16051,24,,0,0,19388.6880759922,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
905:t_299275_b_26748_tn_0,,,radius_1207_s_16051_s_16052,25,,0,0,20425.6382579853,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
906:t_299275_b_26748_tn_0,,,radius_1207_s_16052_s_16053,26,,0,0,20752.5347065814,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
907:t_299275_b_26748_tn_0,,,radius_1207_s_16053_s_833259,27,,0,0,21230.9536762786,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
908:t_299275_b_26748_tn_0,,,radius_1207_s_833259_s_16275,28,,0,0,23127.0336395412,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
909:t_299275_b_26748_tn_0,,,radius_1207_s_16275_s_16055,29,,0,0,23551.6916242021,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
910:t_299275_b_26748_tn_0,,,radius_1207_s_16055_s_16057,30,,0,0,23808.8722434897,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
911:t_299275_b_26748_tn_0,,,radius_1207_s_16057_s_16058,31,,0,0,24487.418244042,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
912:t_299275_b_26748_tn_0,,,radius_1207_s_16058_s_16059,32,,0,0,24680.6102514857,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
913:t_299275_b_26748_tn_0,,,radius_1207_s_16059_s_16060,33,,0,0,25614.1591340582,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
914:t_299275_b_26748_tn_0,,,radius_1207_s_16060_s_16061,34,,0,0,26256.131709164,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
915:t_299275_b_26748_tn_0,,,radius_1207_s_16061_s_16062,35,,0,0,27180.643659028,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
916:t_299275_b_26748_tn_0,,,radius_1207_s_16062_s_16063,36,,0,0,27686.863698439,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
917:t_299275_b_26748_tn_0,,,radius_1207_s_16063_s_15890,37,,0,0,28259.1890347633,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
918:t_299275_b_26748_tn_0,,,radius_1207_s_15890_s_2438932,38,,0,0,28886.6228332024,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
919:t_299275_b_26748_tn_0,,,radius_1207_s_2438932_s_16065,39,,2,3,29619.901749005,0,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
920:t_299275_b_26748_tn_0,,,radius_1207_s_16065_s_2483495,40,,0,0,30254.2525223819,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
921:t_299275_b_26748_tn_0,,,radius_1207_s_2483495_s_16066,41,,2,3,30838.8763853997,0,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
922:t_299275_b_26748_tn_0,,,radius_1207_s_16066_s_16068,42,,0,0,32312.2465968761,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
923:t_299275_b_26748_tn_0,,,radius_1207_s_16068_s_16069,43,,0,0,34898.4147967777,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00
924:t_299275_b_26748_tn_0,,,radius_1207_s_16069_s_16069,44,,0,0,36360.0641114,1,,,,,2,3,booking_route_491,booking_route_491,,,1,00:03:00,1,00:05:00

Here we see that the stop_times has continuous_pickup and dropoff set to 2 and 3 respectively.

The GTFS-Static spec says about these fields:

Indicates whether a rider can board the transit vehicle anywhere along the vehicle’s travel path. The path is described by shapes.txt on every trip of the route.

Can someone explain how this is meant to be interpreted in the context of flex stops? Does it mean that the vehicle follows the shape or that it doesn't?

Or is this perhaps a remnant in the feed to stay compatible with consumers that implement it and show it as some sort of "quasi-flex"?

This is my biggest problem currently with the v2 Flex proposition.

I understand the need to integrate in stop_times for service that includes a fixed section. However, for a completely flexible service it adds a lot of strange complexity for a service that will most likely be considered completely differently by consumers.

Disadvantages that I see

• It forces creating "trips" that have no meaning on a trip basis.
• It forces ordering of "stops" even if there are no actual ordering
• (Relatively subjective) It's hard to understand what a on demand service by looking at the stop_times, especially if there are more than 2 or 3 zones

Proposed solution :

• Have a separated on_demand_locations.geojson that contains only on-demand services. And define the relationship between those locations inside the properties (details TBD).
• Remove location_groups.txt since it was used mainly for groups of on demand zone (I might be missing something here)

It's quite possible my proposed solution is not up to some of the requirements needed as I haven't spend as much time thinking about the problem as other people here.

Edit : Concrete proposal on how to improve things in this post

We need to account for other attributes of request stop service, for example:

• Request stops that can only be requested from on-board the vehicle
• Request pickup that must be requested in advance (by phone)
  To account for this, I suggest is to borrow from the existing pickup_type and dropoff_type fields. Here are two approach options:
• 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).
• 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?

Here are some examples of how flag stop policies are presented by agencies:

• RCT/Rural Community Transportation (in Vermont) -- phrasing is "ON-BOARD REQUEST: Passengers may request stop along the service route in low speed zones at safelocations, such as the Health Center in Plainfield." (http://www.riderct.org/wp-content/uploads/2014/08/US2-route.pdf)
• RCT/Redwood Coast Transit (Del Norte County, California) - "In addition to the stops shown on this schedule, RCTA will make flag stops on request at any safe location as determined by the driver. Passengers desiring flag stops are encouraged to call RCTA at (707) 464-6400 to determine the best place to wait." (http://redwoodcoasttransit.org/routes-schedules/route-20/)

Move over comments from Google Doc to Github "Issues"

This existing text (that I wrote in f05566f) is atrocious:

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.

Opening an issue to go back and clarify that:

• there should be no shape/alignment for travel among unordered stops
• shape_dist_traveled is needed to clearly match the alignment to ordered stops

Using an example might be good.

The reference definition of drt_max_travel_time refers to values that are a multiple of the "direct travel time".

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.

What exactly does "direct travel time" mean? Is this supposed to mean "drive time" or something else?

For now I'm going to try and collect links here of known flex service that we can potentially use as sample producers of GTFS-flex:

• RTD Denver - http://www.rtd-denver.com/callNRide.shtml
• JTA Jacksonville
  • http://claytransit.com/default2.asp?active_page_id=1018 ?
• HART Tampa - http://www.gohart.org/Pages/services-van.aspx
• FDOT report for all of Florida from 2013 - http://www.dot.state.fl.us/research-center/Completed_Proj/Summary_PTO/FDOT-BDK85-977-37-rpt.pdf
• King County Metro (Seattle, WA) - On-demand service, w/in a specific service area. Within that geographic area, the trip must either start or end at one particular transit hub - https://kingcounty.gov/depts/transportation/metro/programs-projects/innovation-technology/innovative-mobility/first-last-mile/ride2.aspx

The "Multiple Zones and Intermediate Stops" example currently shows an AreaY turned off, but it was never turned on.

While making the feed for the Catholic Community Services of Western Washington work in OTP, we hit upon an interesting edge case: what is the expected travel time for services that have more than 2 zones in their stop times which have a time window?

Let me illustrate what I mean with a sketch:

Here we have three zones which all have pretty long time windows. In stop_times the are listed in order and you can get on or off in all zones.

Now, if you're planning a trip from Zone 1 to Zone 3 is the expectation that the trip will always go via zone 2? Or can the shortest path from 1 to 3 be used?

Since services which have more than one zone are pretty rare (I only know CCSWW) and right now the case with more than 2 zones is theoretical I'm wondering what the correct router behavior should be.

Has anyone thought about this yet?

cc @t2gran @vpaturet @tsherlockcraig @jon-campbell-ibigroup @westontrillium

Is there any plans for gtfs-flex-realtime? I could see dynamic scheduling needing to modify the static data for on-demand transit solutions.

I'm currently fine-tuning the flex implementation in OTP2 and have been wondering about the following point:

If I have a service that has both fixed schedule and flex location stop_times in the following order:

1. Fixed schedule stop_time at stop A
2. Flex stop_time at flex zone B (pick up and drop off possible by calling ahead)
3. Fixed schedule stop_time at stop C

Currently the OTP code interprets this as follows:

• you can get on the vehicle at zone B but since the stop_sequence needs to increase you cannot get off straight away inside zone B.
• If you want to treat this trip as a taxi service that can pick up and drop off passengers anywhere in zone B before proceeding to stop C, you'd have to add a second, identical stop_time in zone B.

I cannot find anything in the spec that would clarify what the intention is. Should you be allowed to get on and off at the same flex zone stop_time?

If so, how would you model a service that picks up or drops off passengers in the zone, but doesn't drive them from one point to another one inside the zone?

This actually also applies to trips that contain flex zones only: if you have a trip with two flex zones, can you get on and off at the same stop_time?

One could argue that it doesn't make sense to get on and immediately off at the same "stop" but I recognise that this is a special case.

I'd love to hear your opinions!

cc @hannesj

The diagram of the GTFS-flex model indicates that routes.txt is an edited file, but I don't see a reference to changes to routes.txt in the spec.

Is there a reason that points and multipoints are not an allowed geometry in locations.geojson? It seems like it would be useful to define a collection of stops as a multipoint instead of grouping predefined stops from stops.txt.

For regular GTFS there are several tools available to validate feeds (structure, logic of data, etc).

Does a similar thing exist anywhere for GTFS-Flex? How are implementers verifying their feed complies with the spec?

The specification refers to route deviation as follows:

Route deviation services: the vehicle serves a fixed route and ordered set of stops, and may detour to pick up or drop off a passenger between stops.

It is currently not clear how such a route would be defined. For instance, would stop_times.txt be set up with a single trip that alternates between point stops and a common area zone? Or would the area be at the beginning of the stop sequence with a time span the covers the entire route?

I played around with these scenarios in OTP2 and could not get anything to follow the sequence while allowing for deviation. It would be great to create a sample to be hosted in this repository alongside the existing samples (which I could create with some guidance).

Many taxis and hired car services may not have a fixed boundary of service. Instead, there is a generalized service area around a center point. See screenshot from Google Maps showing a Portland-area taxi company service area as an example.

Should we add a feature in GTFS-flex to define a service center point with radius?

continuous_pickup is already a used field in GTFS, it might be worthwhile re-using more of the same concept instead of adding new geometry on locations.geojson. Is there some advantage to "LineString" that I'm missing?

After reading the spec, I got a little confused about the precise nesting of the JSON properties in the locations.json. I'm pretty sure that it's just the indentation that is slightly off but I'd love some clarification.

Here is a screenshot how the table renders in my browser (Firefox on Linux):

Am I right in thinking that the fields stop_name and stop_desc are supposed to be indented the same way as zone_id and stop_url, namely that they are all fields of the the JSON object properties?

Secondly, the last bullet point just before the table says: "Every GeoJSON Feature must have a properties object, which may have the following keys:"

Then follow properties which should definitely not be keys of the properties object. I think this sentence is left over from an earlier version of the spec where the structure of the table was different.

Am I seeing this correct?

Referencing polygons in stop_times.txt poses an issue for backward compatibility because a stop_id needs to be referenced in each record. How about creating a stop_times_areas.txt or demand_response.txt that follows similar structure, including stop_sequences and references to trip_id?

stop_times_areas.txt file which contains the records with start_service_area_id and end_service_area_id. The schedule for a trip_id is expressed through the combination of these two files — stop_sequence numbers count up through both files. For an example, see the gtfs-flexible sandbox example 5.A or “Green Mountain”.

Currently it's unclear how start_pickup_dropoff_window/end_pickup_dropoff_window should be interpreted since it affects both pickup and dropoff but the pickup and dropoff are not at the same time.

For example, if end_pickup_dropoff_window is 21:00, can a user be picked up at 20:50 for a trip that is expected to last 20 minutes?

Potential solution :
A) Only support start_pickup_window and end_pickup_window and drop off is ignored. That would be my preferred option but it's possible it's not flexible enough for some producers.
B) Support start_pickup_window/end_pickup_window and start_drop_off_window/end_drop_off_window

Note : the name should also be drop_off and not dropoff to be consistant with the existing spec.

The current spec adds a new field to stop_times to flag unordered stops. According to the examples, within blocks of unordered stops the stop_sequence field is still present with unique, increasing integers.

Observations:

1. It seems contradictory for unordered stops to have increasing sequence numbers.
2. It seems unnecessary to extend stop_times with a new boolean field when we already have a mechanism for expressing ordering or lack thereof (the sequence number).
3. The new unordered field will be ignored by legacy software, which will silently misinterpret the unordered trip as an ordered one.

Proposal:
Indicate unordered stops with repeating sequence numbers, and without additional flags. This convention would make the data appear invalid to legacy systems, raise red flags and prevent older consumers from misinterpreting it and misinforming customers.

A partially unordered trip (leaving regularly from checkpoint stop0) would then have stop times like this:

trip_id,arrival_time,departure_time,stop_id,stop_sequence
trip0,00:00:00,00:00:30,stop0,0
trip0,,,stop1,1
trip0,,,stop2,1
trip0,00:15:00,00:15:00,stop0,2

A completely unordered trip (i.e. a completely on-demand service using fixed stops as in the Dutch OVFlex, not really a single trip) would then have stop times like this:

trip_id,arrival_time,departure_time,stop_id,stop_sequence
trip0,,,stop0,0
trip0,,,stop1,0
trip0,,,stop2,0
trip1,,,stop3,0

Of course we might want some (technically redundant) flag at the trip or route level to confirm that this is not bad data, and that repeating sequence numbers are expected. A route flag indicating that a particular route is using the gtfs-flex extensions might be sufficient.

We could also attempt to limit the rejection of flex trips by legacy systems to a single route or trip, so the rest of the classic scheduled service in the feed would still be used. This could possibly be achieved by leaving the trip_ids for flex trips out of trips.txt. But this is assuming lots of things about how consumers validate and use data.