Skip to content

Integration of carpooling lines #430

@AurelienC

Description

@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 :

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!

Metadata

Metadata

Assignees

No one assigned

    Labels

    Change type: FunctionalRefers to modifications that significantly affect specification functionalities.Discussion PeriodThe community engages in conversations to help refine and develop the proposal.GTFS ScheduleIssues and Pull Requests that focus on GTFS Schedule

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions