Introduction
-
The suppliers conduct their trips independently of any additional demand for a ride.
-
In the past, where only a small number of trips were on offer, ridesharing made sense only for long-distance trips (arranged by ridesharing agencies) or for regular trips (trip sharing with work mates).
-
Origin and destination of all trips of suppliers and demanders are located in traffic zones. Every trip originates in an origin zone, traverses a sequence of traffic zones along a shortest path until it terminates in the destination zone. Trips are only matched if their origin and destination lie within the sequence of the traversed zones. Suppliers will only make detours for picking up or dropping off passengers in the zones along the shortest path.
-
A traffic zone does not represent an exact meeting point for suppliers and demanders but it defines an appropriate area for this meeting. It is assumed that suppliers and demanders can arrange an appropriate meeting point within a zone. The exact meeting point, however, is not modeled. Longer trip times resulting from detours for picking up or dropping off demanders can be included by extra times depending on the size of the corresponding traffic zone.
-
The daily travel demand is available as a set of time-dependent demand matrices. The algorithm matches the trips for every matrix independently.
Characteristics | Macroscopic demand models | Microscopic demand models |
---|---|---|
Origin and destination of a trip | Traffic zones | Buildings or arbitrary points in the network |
Representation of demand | Travel demand matrix with volume between origin and destination zones. Demand is non-integer | Set of trips of particular agents as part of a trip chain. Demand is always integer |
Temporal resolution of demand | Discrete in time intervals | Continuous |
State of the art
Characteristics and perspective of ridesharing
-
Dynamic: mobile phones with internet access allow for matches on short-notice.
-
Cost-sharing: the variable costs of a trip are split between the rideshare participants.
-
Non-recurring trips: single-trip ridesharing does not require a rigid time schedule.
-
Automated matching: the ride matching should be automated to reduce the effort of the participants. The system finds suitable matches and facilitates the communication.
The matching problem
Algorithm and implementation
Input data
-
The demand matrix of the suppliers S. In a travel demand model they are a subset from the demand matrix of car-drivers, i.e. car drivers who are willing to provide a ride to unacquainted travelers not belonging to the family.
-
The demand matrix of the demanders D. In a travel demand model, they may come from a subset of the matrices for car-self driver, car-passenger and public transport users, who consider using a ridesharing service. They may also come from a specific ridesharing mode.
Basic algorithm
Extensions of the algorithm
-
Handling rideselling systems This refers to a case where the suppliers are not private car drivers but taxi-like rideselling services with professional drivers or driverless cars. In this case, only the demand matrix of the demanders is used as input. In the matching step all paths of the path set P t D are compared to each other. Two paths p 1 D and p 2 D are matched if one of the two conditions hold: p 1 D ⊂ p 2 D or p 1 D ⊃ p 2 D . This approach assumes that the number of taxis is not limited.
-
Smart match A partial matching following the path order (i.e. matching the first supplier to the first demander path according to the order of the zone numbers) unnecessarily wastes unused ridesharing capacity. Instead, paths can be matched in such a way that either the paths with the longest shared distance or the paths with the highest demand are matched first.
-
Arbitrary reference objects referring to one zone The basic algorithm described above assumes that every link belongs to maximum one zone, as it is the case in Fig. 2 a. Figure 2 b presents a case, where the reference object is not a link but a dedicated ridesharing meeting point. This meeting point is assigned to exactly one zone. The unique zone number of the meeting point is then assigned to all links within a certain buffer around the meeting point. This buffer expresses the willingness of suppliers to accept detours for picking up and dropping off demanders. As a result, a link may belong to more than one zone. This leads to a modified sequence of zones, which can then be processed as in the basic algorithm.×
-
Arbitrary reference objects referring to several zones Figure 2c presents a case where a meeting point can be linked to more than one zone. This case again may lead to a modified sequence of zones thus influencing the results.
-
Multi-path The shortest path assignment can be extended by any other multi-path assignment method leading to od-pairs with more than one path. In this case, the ridesharing capacity of the od-pair needs to be distributed to every path. One simple solution is to use the shares from the traffic assignment.
Implementation
Results
-
Share of car-drivers willing to offer rides (supplier),
-
Share of car-drivers willing to take a ride and leaving their own vehicle at home (demander),
-
Share of public transport users willing to shift from public transport (demander).
-
S1: 5% of the car-drivers are willing to offer a ride. The remaining 95% use their vehicle as before. 25% of the public transport users are prepared to shift to ridesharing alternatives, if a match is provided.
-
S2: 25% of the car-drivers are willing to offer a ride. Further 5% of the car-drivers would shift to ridesharing if a match is available. The remaining 70% use their vehicles as they did before. All public transport users (100%) are willing to shift to ridesharing.
Conclusion and outlook
-
Ridesharing as sub mode: This seems appropriate for traditional ridesharing systems, i.e. systems where drivers offer rides for journeys they are conducting as part of their daily travel pattern. In this case, ridesharing supplements public transport. Using such a system demanders cannot rely on the service and they need a backup mode, which is usually public transport. In a travel demand model the modal share of ridesharing would therefore be determined after the normal mode choice between the main modes within the public transport assignment.
-
Ridesharing as main mode: This seems appropriate for rideselling systems with professional drivers or driverless cars providing an on-demand shared taxi system. In this case, ridesharing competes with car and public transport. In such a system, it is less likely that demanders would need a backup mode. The modal share of ridesharing would be determined as an additional main mode in the normal mode choice step of the travel demand model. It would compete with car and public transport.
Advantages | Disadvantages, shortcomings |
---|---|
Relatively easy to implement Handling of large problem sizes Reasonably fast Works with integer and non-integer demand Can be integrated into a 4-stage travel demand model with feedback between demand calculation and assignment | Extra travel times from detours for picking up and dropping off can only be estimated from the zone size Registration time for calling a ride can only be estimated from the length of the time intervals Trips are only matched within one time interval, so that the algorithm is only quasi-dynamic producing imprecise matches for trips longer than the time intervals |