Add continuous/request stops

[antrim]

Bring in request stops features from GTFS-flex

Based on: https://github.com/CUTR-at-USF/gtfs-flex/blob/master/spec/reference.md, MobilityData/gtfs-flex#7 and other comments from @mgilligan.

I expect this will need some discussion & fine-tuning.

[LeoFrachet]

+1 for the current pull request.

One day, we'll have to change all the "Must phone agency to arrange a request[...]" in the spec, by something less specific than "phone". Maybe "Must contact agency[...]" would be better.

But, for the sake of consistency, I would stick with the current wording, aka "Must phone [...]".

Therefore I agree with the current pull request.

[barbeau]

+1 for this as well. I agree with @leofr - following this proposal (assuming it's merged), we should take a look at the wording such as "phone agency" and replace it with something more general that would allow contact via app, etc.

[antrim]

@barbeau @leofr 👍 on considering alternative wording to "phone agency". We could do a survey of how current agencies are using ...pickup_/drop_off[_type]=2 to see how this is put into practice today. I do wonder whether we should wait to officially change this definition throughout the Spec until after we have established use around agency_contact_email, and any new fields for reservation system URL, mobile app link etc.

[mgilligan]

+1

[antrim]

Here is an alternate approach to consider: We could put continuous_pickup and continuous_drop_off into shapes.txt.

• Advantage: This might facilitate more granular definition of boarding areas (e.g. safe curbs and roadsides) without burdening stop_times.txt. This would also avoid any issues introduced by adding new points into stops.txt that are not stops, but points used to define the edges of boarding zones.
• Disadvantage/counterpoint: The above advantage may be hypothetical rather than meaningful. Would it be better to define safe boarding areas using other datasets (e.g. sidewalk infrastructure data)?

[slai]

Apologies if I'm offering comments that have been discussed before - haven't been following this closely.

Why is there no option 1? Is that to try and align the values with pickup_type and drop_off_type? In that case, the value for 0 is already the opposite, but I guess pragmatically, this makes sense.

Also, is it worth making shape_dist_travelled required as well so feed consumers can be more accurate in identifying the continuous stretch?

Finally, there are a few other disadvantages with @antrim 's counter proposal -

• while having stops in stops.txt that aren't stops isn't ideal, using stop_times.txt means this proposal is backwards compatible with consumers that haven't been updated with this new field, i.e. they can tell users to board/alight at the beginning and end of the continuous stretch and still be correct.

• adding continuous stretch information into the shape effectively ties a shape to a particular route/trip in cases where multiple routes/trips may share a shape but have different pickup/dropoff properties. I feel this new dependency makes the data harder to manipulate as you need to be aware of the shape when all you want to do is change the pickup/dropoff properties.

That said, and this may be a bit speculative, safe curbs are generally applicable to all trips that share the shape, so being able to specify these in shapes.txt is still a worthwhile proposal.

[antrim]

Why is there no option 1? Is that to try and align the values with pickup_type and drop_off_type? In that case, the value for 0 is already the opposite, but I guess pragmatically, this makes sense.

Indeed, my attempt was to align these values with pickup_type/drop_off type values. Perhaps we should make a change so that 1 = No continuous pickup/drop off available.

Also, is it worth making shape_dist_travelled required as well so feed consumers can be more accurate in identifying the continuous stretch?

This would not be necessary if we put the new fields into shapes.txt.

Finally, there are a few other disadvantages with @antrim 's counter proposal -

The primary disadvantage I see of shapes.txt is that this might be more complex to produce for manually created feeds. One of the principles of GTFS is to make it easy for feed producers.

Though…

That said, and this may be a bit speculative, safe curbs are generally applicable to all trips that share the shape, so being able to specify these in shapes.txt is still a worthwhile proposal.

Overall, as I deliberate, I am more inclined to advocate that we put these new fields into shapes.txt. It accommodates whatever level of granularity feed producers and consuming applications ultimately might choose, and it doesn't overwhelm stops.txt.

@mgilligan : Any thoughts on this?

[antrim]

(above comment was modified)

[antrim]

See previous discussion from 2015. It was actually Mike (@mgilligan) who first suggested putting request stops fields in shapes.txt!

[mgilligan]

@antrim I had thought about my previous proposal from a few years ago but had decided it would be more complex for feed producers. However, I'm leaning towards adding the fields to shapes.txt. Here are my reasons:

1. In all cases I've seen, 'continuous' applies to all trips following the pattern so it could live in shapes.txt, reducing the row count in stop_times.txt.

2. Reduces/eliminates the need for creating fake stops in stops.txt to define begin and end of 'continuous' zone.

3. It forces a producer to supply shapes.txt to add continuous stops.

I am now +1 for the shapes.txt proposal, +0 for the stop_times.txt proposal and +1 for adding option 1 for both fields.

[slai]

I've had a look at the past discussion, and I'm coming around to this shapes.txt proposal.

However, this means it will no longer be possible for feed producers to specify a time for when a vehicle enters a continuous pickup/dropoff stretch, or leaves it. This may be a problem if the stop before the stretch is some distance away.

Also, this means trips cannot start or end with a continuous stretch, as there are no proposed fields in shapes.txt to handle arrival/departure times.

EDIT: I suppose for the latter case, you could argue that each trip must start/end with a stop, even if it is the start/end of a continuous pickup/dropoff stretch.

[LeoFrachet]

[tl;dr at the bottom, sorry]

I haven't thought it through, but at first glance, I'm very reluctant in adding any onboarding information in the shapes.txt. I understand that — even if we put it in stop_times.txt — the shape will play an important role. But putting pickup and drop_off values in there makes me uncomfortable.

As a GTFS consumer, we often have to drop the original shapes by creating new cleaned ones. Adding extra information on some shape points of the shape breaks the whole idea of a shape just being... well... a shape.

Also, what will be the name of that area? We won't be able to add a stop_name anymore, so how will it be displayed in the stop list? If we add then in shapes.txt, I'm afraid we will have to add odd things like section_name or area_name to be able to put a name to that continuous stop, same thing for stop_url, stop_desc...

@mgilligan you say "It forces a producer to supply shapes.txt to add continuous stops.": I rather have a producer not providing a shapes.txt, and implying that all the continuous stops are a straight line between the start and the end, rather than having a producer supplying an awful shapes.txt, which doesn't make sense. For example, a file just providing the portion of the shape which are continuous stops.

@mgilligan you say "In all cases I've seen, 'continuous' applies to all trips following the pattern so it could live in shapes.txt [...]". I am already expecting that some agency will add some continuous stop for one trip, and therefore add it for the shape, and down the road won't realize that they have added it to all the trips describe by that shape.

The title of that discussion is "Add continuous/request stops". And I think we are indeed still speaking about stops of some kind. Therefore we should still rely on stops.txt and all the fields that we have created in the file...

[tl;dr:] I would rather see that in stop_times.txt, because IMHO:
(i) it reduces the risk of agency breaking everything (1 stop_time - 1 trip vs 1 shape - n trips);
(ii) it allows the GTFS consumers to keep on relying on existing shape-improving tools;
(iii) it allows to reuse the work done on defining the concept of stops (name, code, desc, fares, stop_timezone, parent station, ...);
(iv) is more consistent with the spirit of the GTFS (that last one may just be in my mind, I agree).

[antrim]

Quoting @slai ,

Also, this means trips cannot start or end with a continuous stretch, as there are no proposed fields in shapes.txt to handle arrival/departure times.

EDIT: I suppose for the latter case, you could argue that each trip must start/end with a stop, even if it is the start/end of a continuous pickup/dropoff stretch.

The proposed stops.location_type=4 could fulfill this function and provides a clear indication of a point that is used for timing rather than a discrete boarding/alighting opportunity.

We could also consider adding other location_types.

Hypothetically, feed producers could provide as many such points as they wish. Feed consumers might choose to interpolate times.

Quoting @leofr ,

Also, what will be the name of that area? We won't be able to add a stop_name anymore, so how will it be displayed in the stop list? If we add then in shapes.txt, I'm afraid we will have to add odd things like section_name or area_name to be able to put a name to that continuous stop, same thing for stop_url, stop_desc...

Let's discuss how names of boarding areas might be determined and shown. When originally imagining this, I was assuming that hail-and-ride/request stop segments would be up to many miles long with small breaks for unsafe areas. Therefore, I imagined that consuming applications would use some sort of reverse geocoding to instruct passengers where to board or determine roadway names. It sounds like we should reevaluate that assumption.

One possible benefit of using stop_times.txt is that it might make it possible to compare trips (schedule and travel pattern) based just on records in stop_times.txt, both when viewing raw GTFS and perhaps even when using an application that does not offer full support for the request stops feature in shapes.txt.

Still, if we include this in shapes.txt, we'll get a cleaner stops.txt and stop_times.txt.

Seems like we need to game out some of the implications and uses further. I think it would be useful to hear from some other feed consumers. @abyrd @sdjacobs @barbeau @RachM @drewda ?

[abyrd]

I am not in favor of putting pickup/dropoff information into shapes.txt. I would prefer that shapes.txt remain focused solely on geometry. The general idea of the pull request is good: use pickup and dropoff fields in stop_times.txt to indicate that the pickup or dropoff is possible along whole segments of the route.

However, splitting this out into a separate field from the normal pickup and dropoff types seems unnecessary, as does the rule that "After a continuous_pickup type is specified that type applies for the length of the vehicle path through stop points until a different, non-empty continuous_pickup value is specified".

I tend to see these as simply new pickup / dropoff types, to be included in the existing pickup / dropoff field, with the difference that instead of applying to that single stop as a point, they apply to the path the vehicle takes up to the next stop time.

Since this would involve duplicating the semantics of all the existing pickup/dropoff types (regular, contact agency, coordinate with driver), I suppose a more normalized approach would be two boolean fields stating whether the supplied pickup/dropoff value was continuous or not.

The main problem I see with adding continuous_pickup and continuous_drop_off fields (either boolean or numeric) is that consumers are forced to add two sparsely populated fields to whatever datastore they use for GTFS, in what is usually by far the most voluminous table in a GTFS feed.

[abyrd]

Do we have concrete examples of any route or trip where pick-up and drop-off only apply to part of the route or trip? Have we considered just making entire routes or trips continuous-drop-off or continuous-pick-up?

[mgilligan]

TriMet's line 84 is an example of a route with regular and flag stops. While serving an urban area, the vehicle serves stops with poles/shelters and then when it is serving the rural roads, it will pick up anyone who flags down the driver.

…

On Jan 18, 2017, at 2:20 AM, Andrew Byrd ***@***.***> wrote: Do we have concrete examples of any route or trip where pick-up and drop-off only apply to part of the route or trip? Have we considered just making entire routes or trips continuous-drop-off or continuous-pick-up? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[antrim]

quoting @abyrd

However, splitting this out into a separate field from the normal pickup and dropoff types seems unnecessary, as does the rule that "After a continuous_pickup type is specified that type applies for the length of the vehicle path through stop points until a different, non-empty continuous_pickup value is specified".

I tend to see these as simply new pickup / dropoff types, to be included in the existing pickup / dropoff field, with the difference that instead of applying to that single stop as a point, they apply to the path the vehicle takes up to the next stop time.

Since this would involve duplicating the semantics of all the existing pickup/dropoff types (regular, contact agency, coordinate with driver), I suppose a more normalized approach would be two boolean fields stating whether the supplied pickup/dropoff value was continuous or not.

In many cases, the request/continuous stop policy (e.g. call ahead required) is different than the policy for regularly scheduled stops (e.g. no call ahead required).

One consequence of this might be that in places where continuous stopping begins exactly at a defined (regularly scheduled) stop, there would need to be two stop_time records referring to the same location in order to express the two different policies. That seems as though it could pose a backward compatibility issue.

Here are a few 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/)

It will be useful to gather more examples of request/flag stop/hail-and-ride policies & practice.

(Edited)

[mgilligan]

@abyrd, I believe having continuous_drop_off & continuous_pickup as separate fields is more clear than adding additional types to the existing drop_off_type & pickup_type. I'd be reluctant to implement it in TriMet's GTFS unless they were separate fields. I don't want to break existing apps by including not yet supported enumerations . Also, we wouldn't have to deal with the rule of product as new values are added.

[abyrd]

Thanks @antrim and @mgilligan, very good arguments in favor of separate continuous_drop_off & continuous_pickup fields. The permissible values and their meanings should then be identical to those for drop_off and pickup, i.e. 1 = No continuous pickup/drop off available. The value 0 is kind of meaningless and therefore excluded, but that still leaves us with the contiguous series of values 1, 2, 3.

I still am uncomfortable with the idea that pickup/dropoff types propagate down the trip when values are not provided. This is a departure from the rest of the spec. I would prefer that these values only apply to the portion of the trip beween the current stop and the next stop, and that a missing value default be interpreted as a specific numeric value, in this case 1 (no continuous pick-up / drop-off).

[mgilligan]

@abyrd, +1 for explicit values for each stop_times.txt row that continuous logic applies and exclusion of 0 as a value for continuous_drop_off and continuous_pickup fields.

[LeoFrachet]

+1 to have that in stop_times.txt.
+1 to have separated fields for the reasons @antrim and @mgilligan have exposed.
+1 also for explicit values.

In a perfect world, empty string "" would always be equivalent to "0" IMHO. But in this case, for backward compatibility, I agree that we should make an exception and define "" as equivalent with "1". (Alas).

[abyrd]

@leofr I don't agree it is desirable for "" to always be equivalent to "0". A solution which works uniformly across the whole feed spec is for the empty string to be equivalent to a completely missing column, both of which yield a default value. Some fields already list default values which are not 0, e.g. the default route color is white (FFFFFF).

[barbeau]

A solution which works uniformly across the whole feed spec is for the empty string to be equivalent to a completely missing column, both of which yield a default value.

+1 for that, as a new proposal :). We'd need to acknowledge some exceptions, such as stop_times.arrival_time/departure_time.

[LeoFrachet]

@abyrd You are right. Indeed. Sorry.

+1 on what @barbeau quoted from your message:

A solution which works uniformly across the whole feed spec is for the empty string to be equivalent to a completely missing column, both of which yield a default value.

We just have to keep in mind the non-consistency of the defaults between the two pickup fields:

• If the pickup_type is empty, that means 0, aka allowed pickup.
• If the continuous_pickup is empty, that means 1, aka unallowed pickup.

But I think that make sense.

=> So, I agree with the current pull request about:

• put the fields in stop_times.txt.
• use separated fields continuous_pickup and continuous_drop_off.

=> And I agree on the further enhancement of the pull request:

• Values should have same meaning than for the pickup_type (aka 1 for No pickup instead of 0).
• No value 0 allowed.
• Default, aka empty string or no column, is 1 (aka not the current meaning which is No change in continuous pickup type)

[mgilligan]

I am now including continuous_drop_off & continuous_pickup in TriMet's GTFS

[antrim]

Closing because this is replaced by GTFS-ContinuousStops #208

[timMillet]

For all of you who participated in this pull request: the vote is now open on GTFS-ContinuousStops. Please share your vote on #208 if you want to.