Integration of carpooling lines

[AurelienC]

Describe the problem

We, the French National Access Point (NAP), have held workshops about carpooling lines with several main actors (Ecov, Cityway, Transit, InstantSystem, Monkey Factory, Grenoble Alpes Métropole).

The conclusions of the workshop show that to model carpooling lines correctly, we would need the following elements:

• new values for route_type in routes.txt
  • Carpooling line (group)
    • Carpooling line with application and with departure guarantee
    • Carpooling line with application and without departure guarantee
    • Carpooling line without application (spontaneous)

And also:

• trips description (as in routes.txt)
  • This new column will be used, in case of carpooling lines, for adding information about the departure guarantee, the necessity of using an application or not, etc.

We'd like to get the discussion going to move the subject forward before presenting any PR, especially for route types for which we are very unsure about what the right path is:
modifying the route type to accommodate for this new need
propose a PR to update the Extended GTFS Route types (link) (but the risk is that our specific requests could be not accepted, or take a long time to validate)
creating a custom extension, like Google did for extended route types (France specific?)
suggesting a better way to modelize services like this in GTFS (longer term)

Use cases

Carpooling line description

A carpooling line is a trip defined like a bus line : precise stops and destinations. Conductors following their journey on this “line” can open their car to passengers. They must use the designated stops. Conductors are not professionals of the road, they can receive a money incentive from collectives, or share their costs with passengers. They make the same trip with or without passengers, apart from detours to reach their stops.

There are no timetables for lines, but a frequency (waiting time estimation) depending on the time of the day. The frequency could be very high at the start and end of days.

Some lines, at specific times, provide departure guarantees to passengers. For example, if a passenger waits more than 15 minutes, a taxi solution could be proposed, without fees.

The majority of carpooling lines use mobile applications to inform drivers about stops and waiting passengers, and to inform passengers when drivers have arrived. The app is also used to certify the journey and give the money incentive.

Context : carpooling in the wild

Several french actors already produce GTFS for their carpooling lines, with route_type = bus. Examples : Ecov with several GTFS files : M’covoit , Covoit’ici

The Google Extended GTFS Route Types Extension (link), or something similar, could let us describe carpooling lines with the required level of detail.
It is interesting to note that OpenTripPlanner uses the route_type values between 1551 and 1560 for the carpooling. (Github, documentation)
But ideally, we would prefer to avoid requiring an extension for this : if we can use “stock GTFS” directly for that, it would be better for everyone.

After some searches, the carpooling subject are already mentioned on this discussion : https://groups.google.com/g/gtfs-changes/c/keT5rTPS7Y0/m/aPg9n-NiAAAJ

The GTFS-OnDemand (GOFS) project suggests adding the value 13-car in route_type enumeration (link).

Relevant issues/PR :

• Google's unofficial route_type 8 to 12 #174 → add route_type values to GTFS (merged)
• Expand / Add definition around route_type  #310 → add route_type values
• Defining a route type at the trip level #358 → route_type at trips.txt level (trip desc)
• Modifications to the GTFS Governance: Phasing Plan #413 → governance

Proposed solution

1- routes.txt - route_type

Would it be possible to integrate a plage of route_type values, like OTP reserved 1551-1560? This will permit to have the right granularity of different types of carpooling lines.

Or even specify more precisely:

• 1551 - Carpooling line (group)
  • 1552 - Carpooling line with application and with departure guarantee
  • 1553 - Carpooling line with application and without departure guarantee
  • 1554 - Carpooling line without application (spontaneous)

While working on this, we are wondering if the route_type used this way isn’t maybe becoming a “leaky abstraction” ; if we were to describe the service with only one route_type (eg. 13 - car), then the modelisation of the reality would not be accurate enough to fulfil the needs of our users.

2- trips.txt - trip_desc

Like done in routes.txt and stops.txt, we propose to add a column description trip_desc in trips.txt, to provide information for the final user about specificities of the trip.

This new column will be used, in case of carpooling lines, to add information about the departure guarantee, the necessity of using an application or not, etc.

We do realize the limitations of using such non-structured fields (e.g. problems when interpreting the “data”, translating etc), but it feels good enough for our needs.

Where do we go from here?

Carpooling has been a national government priority in France since December 2022. Currently, France has 68 carpooling lines in operation, and 72 lines new lines are planned at the moment.

We would love to be able to leverage the GTFS specification (already largely in use) to also cover the carpooling to the extent of details that is required for our user base.

We hope that this issue will lead to interesting discussions & evolutions!

[leonardehrenfried]

I implemented OTP support for carpooling back in the day and I welcome a standardization effort so thanks for this ticket.

As you know your proposal would work mostly out of the box in OTP but I have a question about your various route types: how is the routing result expected to change when one of these is selected?

I would encourage you to also take a look at the GTFS Flex Booking Rules. I believe that it will cover some of your requirements, particularly around trip_description and it's worth thinking if it can be adapted and re-used.

(The Flex spec is in the final stages of standardisation.)

[LaurentEcov]

Hi @leonardehrenfried : About your question "how is the routing result expected to change when one of these is selected?" : the routing result itself is not expected to change, but the way it is explained to user is expected to change, using words and icons related to carpooling and not to bus. This is an example of this problem in Rennes (France) where such a carpooling line is taking into account in the routing results, but not in a comprehensive way for the users.

[leonardehrenfried]

So far the semantics of the route type always describe the type of vehicle and not so much the service. I would try to find a solution where the certainty/uncertainty is expressed more directly and not put into the route type.

…

On Wed, 31 Jan 2024, at 10:53, LaurentEcov wrote: Hi @leonardehrenfried <https://github.com/leonardehrenfried> : About your question "how is the routing result expected to change when one of these is selected?" : the routing result itself is not expected to change, but the way it is explained to user is expected to change, using words and icons related to carpooling and not to bus. This is an example of this problem in Rennes (France) where such a carpooling line is taking into account in the routing results, but not in a comprehensive way for the users. Capture.d.ecran.2024-01-31.105301.png (view on web) <https://github.com/google/transit/assets/158273348/d60b75c9-3ef0-4259-865f-fe48cd1096a9> — Reply to this email directly, view it on GitHub <#430 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABE6MRTAS25G5B5H2374VTYRIIDDAVCNFSM6AAAAABCQ2C2YOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJYG43DAMJRGM>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[leonardehrenfried]

BTW, GTFS Flex has been approved and Booking Rules are now part of the mainline spec. Maybe it helps you express some of the concepts in this ticket.

[AurelienC]

We have seen that @leonardehrenfried, thanks! 😃
We will look up how GTFS Flex could be a suitable solution for describing carpooling lines.
Still open to any suggestions!

[markstos]

RideAmigos is also interested in the standardization of carpooling. The changes proposed here seem modest.

• Some extra route types
• An optional trip description that parallels the the route description

I'd like to understand more what the overall flow for the user is like. A car might have room for only 2 or 3 passengers. But it sounds like the idea is that the "carpool lines" would be common commuting routes that a lot of people would already be driving in the morning or evening.

When bus directions are displayed in a trip planner, they are telling you that a specific operator is operating a specific bus line. With these carpool lines, it sounds like what's being advertised is that you are might find a ride along one of these lines at rush hour by using an app. Is that right?

Or in some cases, is there an expectation that there would also be an API integration with an app service, so that a user might might be able to see that "5 people are offering rides along this line during the time period you are searching for".

Looking at the "GTFS-Flex" spec, what's described here also does sound very similiar to the GTFS-Flex goals like "Dial-a-Ride" and "Hail-and-ride".

[LaurentEcov]

Dear Mark, Thank you for your interest. Both of your thoughts are correct : - With these carpool lines, you *might* find a ride along one of these lines at rush hour by using an app... - and on our app, a user is able to see that "5 people are offering rides along this line, right now". This real time information is not yet available on external apps (using GTFS Real Time for instance), but it could be the case later... The main difference with dial-a-ride or hail-and-ride services is that passengers don't have to book in advance... Regards, Laurent Chevereau Expert Stratégie Ecov Le mar. 30 juil. 2024 à 16:00, Mark Stosberg ***@***.***> a écrit :

…

RideAmigos is also interested in the standardization of carpooling. The changes proposed here seem modest. - Some extra route types - An optional trip description that parallels the the route description I'd like to understand more what the overall flow for the user is like. A car might have room for only 2 or 3 passengers. But it sounds like the idea is that the "carpool lines" would be common commuting routes that a lot of people would already be driving in the morning or evening. When bus directions are displayed in a trip planner, they are telling you that a specific operator is operating a specific bus line. With these carpool lines, it sounds like what's being advertised is that you are *might* find a ride along one of these lines at rush hour by using an app. Is that right? Or in some cases, is there an expectation that there would also be an API integration with an app service, so that a user might might be able to see that "5 people are offering rides along this line during the time period you are searching for". Looking at the "GTFS-Flex" spec, what's described here also does sound very similiar to the GTFS-Flex goals like "Dial-a-Ride" and "Hail-and-ride". — Reply to this email directly, view it on GitHub <#430 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BFXQ6RFZ5HQVPK5HQIPGMSDZO6MBPAVCNFSM6AAAAABCQ2C2YOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJYGQZDMOBYGM> . You are receiving this because you commented.Message ID: ***@***.***>

[AurelienC]

Thanks for your interest @markstos!

We currently have a brainstorming about using GTFS Flex extension to having the best description of carpooling line.

The usage of GTFS Flex will require some changes, taken from work on GOFS.

Feel free to share here your suggestions and ideas on how the GTFS could be expanded to include carpooling!