GTFS-Flex

[tzujenchanmbd]

GTFS-Flex is a GTFS extension that aims to facilitate discoverability of Demand Responsive Transportation Services. This extension describes services that operate according to a schedule, but also include one or more flexible features, such as:

• Dial-a-ride service: the vehicle serves a zone where pickups and drop offs are allowed during certain service hours.
• 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.
• Point-to-zone service: the rider can board at a fixed stop such as a train station, and then alight anywhere within an area, or vice versa. Departures from some locations are scheduled or timed with other services.
• Point deviation or checkpoint service: the rider can board at a fixed stop, and then alight anywhere among an unordered list of stops, or the opposite. The driver only serves stops at which a request is made.

For more information please see original proposal and issue#382(closed since we changed the scope).

In the working meeting on June 28th, there was an agreement among the group community to pursue an iteration that covers all fields currently produced and consumed. Therefore, all fields that appear as “in discussion” in the adoption tracker are included in this PR.

The changes in this PR are:

• Modify file:
  • Modify stop_areas.txt to allow grouping of GeoJSON locations and/or stops which allow predetermined groups of these features to be specified on individual rows of stop_times.txt.
  • Modify stop_times.txt to clarify elements of the current specification necessary to inform data consumers of how to interpret the added and extended files and fields
• Extend file:
  • Extend stop_times.txt with start_pickup_drop_off_window and end_pickup_drop_off_window to define the time that demand responsive transportation service becomes available/ends in a GeoJSON location, stop area or stop.
  • Extend stop_times.txt with pickup_booking_rule_id and drop_off_booking_rule_id to define links to booking rules
• Add new file:
  • locations.geojson, to define zones (Polygon or Multipolygon) where riders can request either pickup or drop off.
  • booking_rules.txt, to define the booking rules that provide riders information about how to request service.

Here is a data example for RufBus in Angermünde and Gartzer, Germany. The image below is an example illustrating how the data could be presented in a trip planner:

Based on the previous discussions, there are still some outstanding items that need to be clarified in this PR, before we proceed to the voting process:

• PR#50 - Should we change prior_notice_last_time/prior_notice_start_time from Conditionally Required to Optional? For cases in which a service has defined earliest/last days but unknown or undefined earliest/last times, should we ask producers to explicitly define earliest/last times or it’s okay to not provide values?
  If we change to Optional, what is the empty semantics? (e.g. 24:00:00)
• issue#72 - Do we want to allow GeoJSON locations and stop areas having fixed arrival_time and departure_time? (i.e. Change presence of pickup_drop_off_window from Conditionally Required to Conditionally Forbidden) @klement-MENTZ mentioned there are “area-based” services that have fixed departure time.
• Issue#339 - Do we want to move locations.geojson.properties to stops.txt? It seems there was a soft consensus of NOT moving it, we would like to confirm this.
• Issue#70 - What does continuous_pick_up/continuous_drop_off mean for stop areas and GeoJSON locations? Do we want to forbid continuous pickup/drop-off for stop_times that refer to a locations.geojson or stop area?

Please go through the changes and outstanding items and share your thoughts here. MobilityData plans to hold a technical meeting to discuss any remaining outstanding items and build on the consensus reached within the discussion in this PR. Details will be announced soon.

[westontrillium]

Fantastic work! The PR looks great to me, pending these outstanding items.

PR#50

Curious to hear other's thoughts. I had already laid out mine in that PR's comments.

issue#72

I've given this some more thought and lean against allowing allowing arrival_time and departure_time for zones, and I'll add another reason: I think it would cause undue risk of having incorrectly built/interpreted Flex data out in the wild that got past validators because this would be technically allowed. With these and the pickup/drop-off window fields coexisting as possibilities for a flexible route, there is the potential for producers to use arrival_time/departure_time over start/end_pickup_drop_off_window when they most likely shouldn't. The use case for using arrival_time/departure_time for zones is extremely rare in my estimation, and, as described in the issue comments, there is a workaround.

issue#339

No, and I think the consensus was considerably strong (not just within the context of the GH issue, but also in discussion elsewhere) for not doing so for reasons outlined in the issue.

issue#70

Continuous pickup/drop-off should only be defined for a standard fixed route. I recommend forbidding in:

• routes.txt if that route has a stop_time referencing a locations.geojson id or area_id
• stop_times record referencing a locations.geojson id or area_id.

[leonardehrenfried]

Thanks for this, @tzujenchanmbd!

Here are my replies about the open questions:

PR#50

I can't say that I have much of an opinion about this since I have yet to work with flex services that had formalised their workflow to this degree. Most have been "Call this number and we will work it out."

Having said that I would prefer to force people to supply a time it even if they say 24:00:00 which may not correspond to reality but at least removes ambiguity.

Issue#72

My reservations (or soft opposition) are documented in the ticket. It feels like an impossible scenario that I would be ok with not being able to model in the spec.

If the proposer cannot convince the operator that it's a bad idea to advertise a fixed time for a zone, I would prefer something more explicit in the spec, because as Weston has pointed out, it's easy to switch to this behaviour by accident.

Issue#339

I don't have very strong emotions either way but I would prefer to keep the properties in locations.geojson.

Issue#70

I have originally asked this question and I think mixing continuous_pickup/dropoff with flex makes no sense, so I'm in favour of not allowing it.

[e-lo]

MobilityData/gtfs-flex#72: Do we want to allow GeoJSON locations and stop areas having fixed arrival_time and departure_time?

No. I think the most common occurrence of flex service that includes a fixed arrival_time or (more likely) departure_time is that you have a stop_id which refers to a specific location (not a zone) with the fixed time and the zone then has windows. I believe that is allowed in the current proposal (although correct me if I am wrong). I agree with @westontrillium that it would likely cause a lot of incorrectly specified flex data to sneak through the validator.

[e-lo]

MobilityData/gtfs-flex#70 - What does continuous_pick_up/continuous_drop_off mean for stop areas and GeoJSON locations?

I agree with @westontrillium on:

forbidden if stop_times record referencing a locations.geojson id or area_id.

I have a question about the same for routes though...if we forbid it for any route that has a stop_id that refers to locations.geojson, then are we basically just saying that the following should be coded instead within stop_times.txt? It would be simpler to allow this to be coded in routes.txt and I can't think of the downside but I'm sure @westontrillium has some thoughts (perhaps highlight them?)

graph LR
    A(A) --> | continuous stops | B(B)
    B --> | continuous stops | zone
    subgraph zone
    end

Loading

[klement-MENTZ]

MobilityData/gtfs-flex#50
I think this will only be used very rarely. I agree with the PR to make it optional.

MobilityData/gtfs-flex#72
Since the general consensus is that this change is rather disadvantageous I will close the ticket. We will find other ways to model these probably rare cases as described in the ticket. And I also agree that the operators should be motivated to properly specify their services in the first place. :-)

#339
I like this part:

Remove Point, MultiPoint, Linestring, and MutiLineString from the list of options for Geometry.Type since there is no need to define points or lines in locations.geojson

One weakness of gtfs is that often field lengths or datatype are not well defined. Removing those options will help.
In addition, I think that incorrect data deliveries can be prevented here as mentioned above.

I don't agree with the rest of the ticket but on the contrary would like to see as much information (name, description) about the areas as possible in the geojson file. The geojson file can then be usefully processed without the rest of the GTF.

[e-lo]

RE moving locations.geojson properties to stops.txt. As I indicated in the issue discussion, I think it is much simpler to have all the primary keys for something in a single file (stops.txt) and to avail locations.geojson of important attributes in stops.txt by default (although I'm sure some would be conditionally forbidden). PrimaryKeys across tables is dicey/impossible to implement easily (based on my own experience in trying to do so, and also a quick scan of stack-overflow which basically says....you should combine the tables if they share a primary key)

I can also see an extension for using locations.geojson for defining non-point geometry of other entities in stops.txt (i.e. the footprints of parent stations, platforms, etc).

Another way to simplify this is to add an optional geometry field to stops.txt which defines the geometry of the stop entity which is either a geojson object or more simply, wkt. This would allow you to visualize everything in a single place.

Either way, I don't see a particular advantage to having properties in locations.geojson.

I understand and agree with @westontrillium 's comment that this should have been discussed in the drafting phase, but also the drafting phase has lasted a decade or so and we shouldn't ignore the various experiences with gtfs and data wrangling in the interim that have happened.

Ultimately, I represent more of the data producers though, and Flex doesn't/wont' matter unless it is adopted by data consumers...so I'm happy to "disagree and commit" to adopt the framework that would make adoption easiest for data consumers.

[westontrillium]

Re. continuous stopping...

I have a question about the same for routes though...if we forbid it for any route that has a stop_id that refers to locations.geojson, then are we basically just saying that the following should be coded instead within stop_times.txt? It would be simpler to allow this to be coded in routes.txt and I can't think of the downside

While that specific scenario may be easier to code in routes.txt, a universal allowance at the route level would make way for scenarios we'd want to disallow. For example, with no forbids, it would be "valid" to have continuous stopping enabled at the route level and have that route contain any number of intra/interzone-only trips which would technically be continuous stopping even though it doesn't make sense to define those trips as such.

@e-lo Do you think there is a way to word the forbid that would allow for the scenario you describe without causing confusion? "Forbidden in routes.txt unless that route has a stop_time referencing a locations.geojson id or area_id that precedes or follows a fixed stop" seems more confusing to me than just directing producers to define this specific scenario at the stop_time level.

[westontrillium]

Re. moving locations.geojson's primary key to stops.txt

I'll simply stand by what I've said already in issue #339's comment section, but add that this issue has been open for over a year with multiple requests for comment, and there is still no common call for moving the locations.geojson's primary key to stops.txt. This suggests to me that locations.geojson's current design is not an obstacle to adoption.

[e-lo]

RE Continuous stops...

@westontrillium I think you are talking about wanting to make sure that adding continuous stops to routes.txt would not make sense for the following situation?

graph LR
    A(A) --> | continuous stops | B(B)
    B --> | continuous stops | zone1["Zone 1"]
    zone1 --> | NO continuous stops | zone2["Zone 2"]

Loading

I would think that adding continuous stops in routes.txt would be interpreted as this...and anything else would need to be articulated in stop_tims.txt

graph LR
    A(A) --> | continuous stops | B(B)
    B --> | continuous stops | zone1["Zone 1"]
    zone1 --> | YES  continuous stops | zone2["Zone 2"]

Loading

Or are you referring to another situation?

[westontrillium]

I think I still agree with my original recommendation on routes.txt. I don't think you could ever see either a "YES continuous stops" between Stop B and Zone 1 or between Zone 1 and Zone 2 out in the wild.

Let's back up and think in concrete, operational terms what kind of service this is actually describing, because I don't think it is possible: A transit service that runs a fixed route and allows continuous stopping along that route between stops, but also may subsequently serve two consecutive zones and allows continuous stopping on the way to/from those zones (but those trips only exist if someone books them, and the path of travel to/from those zones cannot be pre-defined since it depends on the destination of the scheduled ride(s), so a rider couldn't know where to stand to flag the vehicle).

[tsherlockcraig]

I just left a comment on MobilityData/gtfs-flex#50 indicating opposition to that change, but otherwise agree with what I see @westontrillium articulating above:

• don't allow arrival_time or departure_time on locations
• leave attributes in locations.geojson
• clarify in spec that continuous stops can't exist between location (ie, forbidden in stop_times where the current or subsequent stop_time is a location; forbidden in routes where any stop_time refers to a location)

[abyrd]

Hi all, I'm providing some comments in hopes that they will be useful.

I have not participated in the working group meetings, nor in the early drafting of the spec, and other than code review on early Flex routing implementations I have not been involved. For these reasons I realize my comments will not carry much weight, but I’m providing them as observations from a relative outsider to the Flex spec catching up on its current state. Maybe the outside perspective is useful.

[eliasmbd]

📣 FLEX WORKING GROUP MEETING ALERT!

GTFS-Flex - Working Group Meeting - Implementation & Testing | January 17, 2024 @ 10 AM EST

Sign up here

Topics to discuss in Flex meeting:

• Should we include normalization of location_groups in a separate file (similar structure to areas/stop_areas) OR add description in location_groups to coherently capture why different tables share an ID namespace.
• Should we rework naming convention of location_groups.txt and locations.geojson

Can't make the meeting? no problem. Write down your comments and concerns here or contact us at: [email protected]

[tzujenchanmbd]

👋 On January 17, we held the 4th GTFS-Flex Working Group Meeting and discussed the outstanding issues. Here is a brief summary. More details are available in the meeting notes.

🦜 Discussed during meeting:

1️⃣ Should we include normalization of location_groups in a separate file?

• Adding a new file because of the following arguments
  • This aligns with the fundamental principles of data modeling.
  • This aligns with similar existing structure in GTFS, such as [areas.txt + stop_areas.txt]

2️⃣ File name for locations.geojson , location_groups.txt , and the added normalized file:

• locations.geojson - keep this name
• Existing location_groups.txt → location_group_stops.txt
• New normalized file → location_groups.txt
• Using these file name based on the following arguments
  • In general the working group agreed that there is no perfect name for these files.
  • Since there’s a possibility of using files for other purposes in the future, word flex might be too specific
  • There are other things that use the word “zones”

3️⃣ Opening a vote without the 4 duration fields? (mean_duration_factor, mean_duration_offset, safe_duration_factor, safe_duration_offset)?

• Agreed that we can move forward with the vote for adoption without these fields.

⏭️ Next steps:

• MobilityData modifies Pull Request according to discussed changes.
• MobilityData will coordinate with First Producers and First Consumers to ensure that changes are implemented
• MobilityData will add data examples on MobilityData/gtfs.org repo. The data examples will be published on gtfs.org right after the spec got adopted.

🙏 Thank you for joining us and we are hopeful for the future of GTFS-Flex.
🚂 MobilityData Team

[abyrd]

Thanks @tzujenchanmbd for the summary of the meeting. For time zone reasons I will not be able to participate in meetings of this kind for the foreseeable future, but since live meetings seem to be the preferred collaboration approach I'm happy to see that people are apparently reaching some conclusions in them, and I hope my written commentary was useful in the course of that discussion.

[tzujenchanmbd]

@abyrd Appreciate your valuable written commentary, which has been a valuable contribution to the ongoing discussions. Your insights have played a crucial role in shaping our conclusions!

Accommodating every contributor's schedule can pose challenges due to the global nature of our collaboration. You are not alone in this situation, as we also engage with stakeholders in Japan and Australia. We have and will continue to accommodate different timezones from time to time.

[tzujenchanmbd]

Quick updates:

• We have made spec changes based on consensus reached in the working group meeting.
• Please also review the data example page in Mobilitydata/gtfs.org repo, we plan to publish these examples on gtfs.org after the spec got adopted.
• Since this PR has existed for a while (since last July), there are many conflicts with the current spec. We will create another "voting version" PR shortly. The changes are the exact same as this PR, but they are based on current spec instead of the spec from last July.

[tzujenchanmbd]

Closing this one as the vote passed on #433