Support for a new ridesharing mode

[hbruch]

Though ridesharing is not transit, it shares some common properties with transit, like time-dependant routing, and, depending on the flexibility of the driver, a more or less fixed route with optional stops.

I suggest to add a new mode "ridesharing" to OTP, so ridematching agencies may provide their offers as a GTFS stream. This would allow intermodal routing for carpools, vanpools, sluglines or real-time ridesharing offers with OTP.

A first PoC I did triggered the following questions:

• GTFS could be used as data exchange protocol for ridesharing/carpool offers. However, GTFS does not yet support such a mode/route_type, nor are TPEG extension defined for these modes
• is OTP capable of dynamicly adding/removing routes/stops etc. when a GTFS stream is updated?
• OTP uses the term "transit" to distinguish between car routing and schedule-based routing modes. As ridesharing is not transit, generalizing the naming to e.g. to timeDependent or scheduleBased would avoid some mismatches

[abyrd]

Hi @hbruch, there's certainly a lot of demand for ride sharing support. However, I don't think ride sharing cleanly fits into either normal street routing or scheduled "time-dependent" routing methods.

There have been efforts to add informal / flexible transit routes GTFS but they are fundamentally different than fixed route transit in that they don't usually have defined stops, but rather a set of spatial and behavioral constraints.

OTP can dynamically add routes and stops -- broad support already exists for GTFS-RT.

I think the term "ridesharing" is not a lot more specific than "transit". Ride sharing could include concepts as different as a truck that waits until it's full in a developing city, a taxi summoned with a cell phone, a subsidized on-demand semi-fixed route system for isolated or handicapped people, etc. I'd say most of these are not really time-dependent in the way transit is, and they might be better modeled by adding wait times to normal on-street routing.

[hbruch]

Hi @abyrd,

yes, that's true. The term "ridesharing" itself is not very specific. And as you point out, there exist many different concepts. However, here in Germany, there are a couple of ridematching providers, that match drivers / riders seeking to share a ride. For long distance trips, this works well. For short distance trips or daily commute, there is hardly any platform that gained critical mass.

For such short distance trips, the driver, in my opinion, is reluctant to deviate from his originally planned route or to invest much time to coordinate with a ride seeker, so this mode very much ressembles transit.

I'm aware of the GTFS-flex initiative, but in the use case scenario I have in mind I think that fixed route transit is a sufficiently good approximation.

Great, that broad support for graph reloading and GTFS-RT exists, which would allow to integrate real-time positional information.

Not sure, if there is general interest to integrate ridesharing support as described above in OTP. I forked the repo and added ridesharing as a transit mode. First results look promising.

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days

[leonardehrenfried]

The other day I had an idea how to add the somewhat fuzzy concept of ride-sharing into OTP cleanly.

Netex has the concept of submodes, which is a grab bag of things that don't fit into the main modes. So there is ferry, but also the submodes pedestrian ferry, car ferry, rail ferry...

GTFS doesn't really have this concept but since OTP already supports submodes (and they are installation-specific) it would not be much of a leap to allow GTFS users to specify a custom mapping of route_type to submode. That way we don't have to add an extra mode for every little thing that we want to support but give users the option to define their own submodes.

Of course this comes at the cost of genericness and type safety.