davidr1234
commented
1 year ago 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
westontrillium
leonardehrenfried
e-lo
👋 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.
🤔 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
Deviated bus routes
Dial-a-ride
Displaying contact information (phone number and/or website URL) for booking
🧑💻 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.
Booking_rules.txt Defines the booking rules.
📢 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.
🔗 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
Edit: