Utilities for DRT

[sebhoerl]

Following our recent discussion, it would be interesting to improve the out-of-the-box functionality for DRT. We already have started this with the Corsica DRT example. First, this example should be extended and standardized, then the relevant components might move to a more high-level package inside this repository.

What is there:

• Analysis tools copied from AMoDeus, which give three relevant files: List of all DRT trips with origin, destination and timing from the customer perspective; list of movements with origin, destination, timing, occupancy from the operator perspective; list of activities (idle, pickup, dropoff) from the operator perspective.
• Simple rejection handling using a constraint: The rejection rate R is measured globally, and then a constraint is defined that forbids the use of DRT in R% of cases.

What we should add:

• [ ] Current rejection constraint should be revised: Following the structure of the epsilon package, we may want this to be deterministic in the sense that if in one iteration the DRT alternative is available, and nothing else changes about the trip chain of the agent, this alternative should also be available in the next iteration, and vice versa. Currently, it seems that we go in that direction by having a person-specific random number generated, but when looking through the code we had doubts that this is really deterministic (as the constraint factory may be recreated in every iteration; and if not, there may be multiple factories in parallel accessing the same Random instance). The best would probably be to generate a random number [0,1] deterministically at MATSim start-up, save it as an agent attribute, and then make use of it for this constraint.
• [ ] Alternative handling of rejections by adding a new component to the utility function that is based on the rejection rate.
• [ ] Infrastructure for estimating the relevant metrics: Make it easy to estimate waiting times, detour factors, and rejection rates by time bin and by spatial bin. Spatial geometry should be defined by a shape file, time bins by [start, end, interval]. This is useful for estimating these attributes and feeding them back to the utility estimator, but also simply for post-simulation analysis.
• [ ] Comparison infrastructure: Once we measure the metrics, we need to compare if the measured values represent more or less what we have seen later in the actual simulation. It would be good to have this functionality out of the box to directly identify (visually) after a run whether the estimation error is normally distributed or heavily biased. This goes for waiting time, detour factors, and rejection rates.
• [ ] Options for proposing values in the utility function: So far, we have mainly used the defined maximum values for the waiting times as choice dimensions that enter the utility function. It would be good to have separation of estimation and proposition as the operator may, based on its estimates, make a proposition that is either more optimistic or pessimistic than the estimated value. We expect that an interesting trade-off can be observed here: If the operator is very "optimistic", rejection rates may go up and customers will be unsatisfied. If the operator very "pessimistic", the base number of trips will go down, because customers are not interested. So there is a sweat spot in terms of proposing a connection from the operator side.

@kaghog @tkchouaki @balacmi

[sebhoerl]

Just noting down here that MATSim now has DRT estimation code that we may want to use here