GTFS-Flex: Service Discovery

[eliasmbd]

👋 Introduction

Hello everyone, I am Elias, the new community manager for transit specifications at MobilityData. I am excited to share that MobilityData intends to facilitate the adoption of the GTFS-Flex extension into the official spec. It is great to see that some of you have already started using GTFS-Flex.

• Flex Pilot project a collaboration between MNDoT, Trillium, Transit, Cambridge Systematics, and Token Transit.
• Consumers, IBI , OTP, and Transit, have implemented some forms of GTFS-Flex on their platforms.
• Visit the original GTFS-Flex repo to access older versions of the extension.

🤔 Problem

As many of you know, services like dial-a-ride are often brushed over by riders, who sometimes have no clue they even exist. This lack of accessibility is an issue for producers, consumers, and riders. Imagine a group of tourists arriving at your local airport and would like to reach a rural area that does not offer scheduled bus routes but only an on-demand bus service. The tourists check their preferred trip planner app and do not find a viable public transportation option; they end up renting a car. Being tourists, they missed all of your paper flyers posted along the hallway announcing the on-demand service. Not only is your service underutilized, but it lacks the discoverability to meet current and future rider demand. This is where GTFS-Flex comes in by providing that information to the rider allowing them to enjoy the services you worked hard to promote.

🔭 Scope

Based on what has already been tested in the field, we see GTFS-Flex solving the following key use cases:

Display available demand responsive transportation services for rider discovery

Source: IBI

Deviated bus routes

Source: Transit App

Dial-a-ride

Source: Transit App

Displaying contact information (phone number and/or website URL) for booking

Source: Find a Ride

🧑‍💻 File and field names

To cover the base implementation of GTFS-Flex, MobilityData kindly asks you to review this adoption tracker. All of the fields in Green are what we considered essential for a base implementation. Those same fields are described below. Once reviewed we kindly ask you to fill in your organization's name and add a checkmark ✔️ to the fields you are currently using.

locations.geojson
(Optional file) Adds GeoJSON locations, which are Polygon and MultiPolygon features that indicate groups of lat/lon coordinates defining zones where riders can request either pickup or drop off.

Field Name	Description
type	"FeatureCollection" of locations.
features	Collection of "Feature" objects describing the locations.
features.type	"Feature"
features.id	Location ID belonging to the same namespace as stops.stop_id. It is forbidden to define an id from locations.geojson with the same value as a stops.stop_id.
features.properties	Location property keys.
features.geometry	Geometry of the location.
features.geometry_type	Must be of type:- "Polygon"- "MultiPolygon"
features.geometry_coordinates	Geographic coordinates (latitude and longitude) defining the geometry of the location.

stop_times.txt
(Optional file) Modifies file 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.

Field Name	Description
start_pickup_dropoff_window	Time that on-demand service becomes available in a GeoJSON location, stop area or stop.Conditionally Required:- Required if stop_times.stop_id refers to stop_areas.area_id or id from locations.geojson.- Forbidden if stop_times.arrival_time or stop_times.departure_time are defined.
end_pickup_dropoff_window	Time that on-demand service ends in a GeoJSON location, stop area or stop.Conditionally Required:- Required if stop_times.stop_id refers to stop_areas.area_id or id from locations.geojson.- Forbidden if stop_times.arrival_time or stop_times.departure_time are defined.
pickup_booking_rule_id	Identifies the boarding booking rule at this stop time.Recommended when pickup_type=2.
drop_off_booking_rule_id	Identifies the alighting booking rule at this stop time.Recommended when drop_off_type=2.

Booking_rules.txt
Defines the booking rules.

Field Name	Description
booking_rule_id	Identifies the rule.
booking_type	Indicates how far in advance booking can be made. Valid options are:0 - Real time booking.1 - Up to same-day booking with advance notice.2 - Up to prior day(s) booking.
phone_number	Phone number to call to make the booking request.
info_url	URL providing information about the booking rule.

📢 Let us know in the comments if there are key use cases missing, and express your interest in producing/consuming in the tracker.

🔮 MobilityData expects GTFS-Flex to open the door to deeper standardization of demand responsive transportation including expansion into transactional and real-time components using GTFS-OnDemand. We are preparing a suggested strategy to best handle the growing number of modes of transportation and complexity of concepts engaging in this area.

🗓️ Timeline

We feel that we can propose the following timeline for this process. We want to provide a general vision for the coming weeks but want to maintain flexibility to extend or shorten the time frame following the first working group meeting.

We kindly ask you to fill out this google form to better help us facilitate the working group meetings.

Date estimates	Task	Participants
Ongoing until first meetings	Listening Tour	MobilityData Consumers Producers
Week of May 29, 2023	Confirmation of scope	Consumers Producers
Week of May 29, 2023	Open issue according to base implementation	MobilityData
Wed, Jun 28, 2023 at 11 am	First working group meeting -Base implementation -Set 1-2 subsequent technical meetings	MobilityData Consumers Producers
Week of Jul 3, 2023	Open PR for chosen iteration -1 GH issue	MobilityData
As of Jul 10, 2023	Implementation of GTFS-Flex base implementation -Resolve outstanding PR items	Consumers Producers
As of Aug 1, 2023	Vote of base implementation	Everyone
As of Aug 1, 2023	Add validation rules	MobilityData
As of Aug 1, 2023	Update documentation	MobilityData
As of Aug 1, 2023	GTFS-Flex release blog post	MobilityData

🔗 Important Links

GTFS Slack Channel
Join the GTFS-Flex channel to stay in-touch with the community. This is a place to exchange quick messages, and hold informal conversations with the most influential participants in GTFS.

GTFS Changes Google Group
This is an email chain where you can receive major announcements about changes to GTFS-Flex. Currently we communicate GitHub Pull Requests here but we are considering including issue announcements like these.

Original GTFS-Flex Repo
Here you can find current and previous GTFS-Flex versions.

👀 TL:DR: Action Required

• Review Adoption Tracker and fill out Organization field and add checkmark to currently consumed and/or produced fields
• Fill out this google form to better help us facilitate the working group meetings.

Edit:

• Updated google forms link (EC)
• Edited first image to include descriptions (EC)
• Updated Original GTFS-Flex Repo descriptions (EC)
• Updated Flexible timeline (EC)
• Updated terminology (EC)

[davidr1234]

As requested, here's a first feedback:
First Figure:

• Icons in first Figure not explained, although message is clear
  Use cases:
• Display available on-demand bus:
• 1. in Switzerland (and to our knowledge in other regions in Europe) on-demand buses can not (are not allowed to) operate public (bus/train/...) stops. This would need to be modelled. Example: if someone searches from a public bus stop the on-demand provider should not be returned, but the location (see point 2)) the provider operates from may be returned.
• 2. given the above, some of the operators have what we describe as "Sammelstellen". These are stop places that are specifically only operated by one or more on-demand buses. An example would be a restaurent near the main train station.
• dial-a-ride: I am not sure if I understand what is meant by "dial-a-ride". Generally, a short description may be beneficial for this particular use case.
• Booking information: We differentiate between contact information and booking information, maybe this separation is also true for others?
• Booking information: The availability constraints may be relevant as well
• Booking information: In Switzerland we also have limitations concerning who's allowed to use certain services, e.g., on-demand services provided specifically only for people with an impairment
• Missing use case: A use case common in Europe is the operation along existing, public stops, but only upon request. That might need to be added as well.

David

[eliasmbd]

🙏Thank you for the swift feedback. We appreciate it and it allowed us to explore the current GTFS-Flex ecosystem in Switzerland and Europe.

👀 Concerning the first figure, we added 2 descriptions under the icons to describe them better. The first icon represents Transit app. The second icon represents Community Transit, a demand responsive transportation service within the Minnesota DoT pilot program.

🚏 Sammelstellen - From what is described in the comment, this should be able to be modeled in GTFS-flex. A possible way to model this:

1. Producers would need to provide those pickup/dropoff points as "stop" in stops.txt in GTFS.
2. Producers can group these "stops" with area_id in stop_areas.txt .
3. Referencing these area_id in stop_times.stop_id and adding start_pickup_drop_off_window & end_pickup_drop_off_window to indicate service time as on-demand service.

ℹ️ Contact vs booking information - In the current GTFS-flex proposal there are info_url and booking_url , so conceptually we differentiate "getting information" and "booking" for url. We only have 1 phone_number field at the moment, if separating booking phone number and contact phone number (e.g. customer service) is a common use case, we can discuss whether to adjust phone number field(s) in future working group meetings.

🧓 Rider restrictions- Currently we don't have any rider-category like fields in GTFS-fares v2. However producers can show the limits in the message field as text description.

📲 Dial-a-ride is a variation of multiple terms used across Europe.

🇨🇭 In Switzerland, we believe it would fall under the term Rufbus / On-call bus. We also noticed the availability of the PubliCar system by PostAuto. Under this proposal, the PubliCar App and service would be discoverable in the user’s preferred trip planner app.

• https://www.postauto.ch/en/timetable-and-network/publicar

🇦🇹 In Austria, dial-a-ride would also be Rufbus and under the bigger umbrella of Bedarfsverkehr (Demand Responsive Transport) and Mikro-ÖV (Microtransit).

• https://www.bedarfsverkehr.at/
• Wiener Linien (https://www.wienerlinien.at/documents/843721/4770179/Anleitung_Rufbus_359531.pdf/df430b95-9dd4-0d13-ffdf-bdace15932a8?t=1614165175643 )
• Rufbus [english: dial-a-bus]
  (formerly Anruf-Sammel-Taxi or ASTAX [call-collect-taxi])
• Current GTFS implementation
  As an year-long service alert

🇩🇰 In Denmark, it can be referred to NT / midttrafik / sydtrafik / FYNBUS / movia (https://flextur.dk/)

• flextur [english: flex trip]
• (formerly flextrafik [english: flex transit])

🇫🇷 ⚠️ In France “Paratransit” is used to describe “informal” transit (instead of on-demand transit for people with disabilities)

• Reseau Mistral (https://www.reseaumistral.com/services/service-appel-bus)
• Appel bus [english: call bus]

🇩🇪 In Germany they refer to it as On-Demand-Angebot, Flexible Fahrt and AST

• BVG (https://www.bvg.de/de/verbindungen/bvg-muva/flexible-fahrt)
• Brand: Muva
• On-Demand-Angebot [english: on-demand-service]
• Flexible Fahrt [english: flexible trip]
• Other areas
• Anruf-sammel-taxi or AST [english: call-collect-taxi]

🇬🇧 In the United Kingdom, there is the following service:

• go2 Sevenoaks (https://www.go-coach.co.uk/go2/ )
• On-demand service

The terminology varies across borders but in general we can assume that dial-a-ride is any demand responsive service that requires some form of contact by the rider to the operator.

As for the missing use case, we can take the time to talk about it in a working meeting. This would benefit the larger community as it would increase the awareness of the possibilities of GTFS-Flex.

[westontrillium]

Love seeing some discussion getting started here!

Booking information: We differentiate between contact information and booking information, maybe this separation is also true for others?

In the core GTFS standard, we already have agency.agency_phone which is considered the "general contact" phone number. Flex includes booking_rules.phone_number specifically for the number a rider must call to book (in most cases, an agency_phone and booking_rules.phone_number are one and the same).

Booking information: In Switzerland we also have limitations concerning who's allowed to use certain services, e.g., on-demand services provided specifically only for people with an impairment

As @eliasmbd has said, the message field can be used to clarify eligibility restrictions of a given service. It was deemed earlier in Flex's history that eligibility considerations carry a level of complexity that merits a separate extension effort. There is a proposed Eligibilities/Capabilities spec you can view here that actually does draw on some features from Fares v2 (i.e., Rider Categories).

Booking information: The availability constraints may be relevant as well

If you are referring to realtime availability of a given service, GTFS-Flex is a static spec and only covers static information intended for service discovery.

Missing use case: A use case common in Europe is the operation along existing, public stops, but only upon request. That might need to be added as well.

If I'm interpreting this correctly, this might already be covered by the core GTFS standard with stop_times.pickup_type and stop_times.drop_off_type.

[davidr1234]

Thank you @eliasmbd and @westontrillium for the prompt feedback!

I think you answered/resolved most of my points.

• Icons in first Figure. It is clear now.
• Sammelstellen. Your solution using stops and areas would be appropriate.
• Booking vs contact information. I think @westontrillium response covers this.
• Availability constraints. Apologies for causing confusion here. I think this is covered with the dropoff/pickup window.
• Missing use case. Indeed @westontrillium answer should cover this.

Topics I think were answered, but may be worthwhile to follow up upon:

• [] dial-a-ride. I know the variations you describe, at least for the DACH region. It also explains the naming convention. It seems that the use case covers all on-demand variants. How would you differentiate it from your other use cases?
• [] User group booking limitations. I see. A message allows flexibility and is probably a good short term solution. An extension as the ones you both referenced would be useful. But, although many variations may exist, some criteria/categories are common worldwide (as the documents you referenced also indicate), e.g., impairment or age ranges).

[leonardehrenfried]

I agree with others that eligibility restrictions are best expressed by the already existing rider_categories of the Fares V2 spec as they are referring to the same concept and already have the age range you're talking about. The thing is that they are not merged in the main spec yet. I think they are very useful so expect them to be in the spec at some stage in the future.

This would lead to a nice synergy between those two spec extensions.

[eliasmbd]

FYI, you can expect the conceptual meeting for GTFS-Flex to be held on Wed, 28th June at 11am EDT. Duration will be about 1.5 hours. More information will be shared in an official announcement.

The flexible timeline will shift forward by 2 weeks. Reason for shift: meeting conflicts and accommodation of international stakeholders.

[eliasmbd]

Sign up for the Conceptual Working Meeting here:
Event Page

[eliasmbd]

The PR #388 has been published and so we close this issue.

[e-lo]

🤔 Often issues are closed with a PR is merged not just opened – is there a reason to close it ahead of that?

[eliasmbd]

In order for us to limit post stagnation we took the decision to centralize these issues under a single PR. Every PR and issue is looked at on a case-by-case basis. Issues can be re-opened if they regain enough traction. In this case, the resolution of the issues and the PR are co-dependent and we decided to centralize communications. If discussions become excessively issue specific, we can choose to re-open the issue.

[eliasmbd]

🤔 Often issues are closed with a PR is merged not just opened – is there a reason to close it ahead of that?

Just to clarify. We closed this issue because the scope got bigger in the PR than what was proposed here. This is an exception. We plan on continuing to follow the norms set by the GH community when creating an issue and linking it directly to the PR.