Re-Structure of Trip Scheduling

[dhensle]

The current implementation of probabilistic trip scheduling results in about 25% of stops failing to produce valid schedules. Trips fail to schedule when a selection for an earlier trip in a half-tour makes scheduling of a subsequent trip impossible (or very low probability) based on the probability distribution.

The current trip scheduling probability distributions are segmented by purpose, half-tour direction, tour time period, and trip number. The selected probabilities are independent of what the previous trip departure time was and can lead to the failed trips. The current implementation is consistent with TM1's version of CT-RAMP.

Re-structuring the trip scheduling probabilities file to replace the tour time period segment with the previous trip's time period would ensure that a trip does not get scheduled before it's previous trip. This enhancement was made in the SANDAG version of CT-RAMP and an example probabilities table for that implementation can be seen here.

The advantages of this new approach would be less failed trip schedules. Trip scheduling currently iterates up to the maximum iterations to try to get a valid tour pattern, so less failed trips would also mean less iteration and therefore decreased run-times.

(A setting in the current implementation will deal with failed trips by either throwing them out or setting them to the previous trip departure time in the outbound direction or next trip departure time in the inbound direction.)

[lmz]

From conversation with @DavidOry, it is my understanding that there are multiple approaches:

1. CTRAMP2 method (which is much more elaborate, includes accessibilities -- this is too significant a difference and is unlikely to be considered)
2. Atlanta ActivitySim model approach
3. SANDAG approach referenced above

It would be helpful to have a description of 2 vs 3 and pros/cons described here.

[DavidOry]

Following up on @lmz'z comment: The ARC implementation of trip scheduling and trip departure appears to be working correctly in the ActivitySim implementation. It segments each tour into three segments (before the primary activity or outbound leg, the primary activity or main leg, and after the primary activity or inbound leg) in the trip_scheduling module. This is represents the stage 1 portion of the CT-RAMP ARC specification. The stage 2 portion then allocates a departure time to each of the stops on each of the trip leg in the trip_departure module.

I've created a simple spreadsheet to illustrate my understanding of how this model works here.

The ARC approach seems both theoretically more attractive than successive probabilistic draws (which means future estimation efforts can add intelligence to it) and has the benefit of already existing in ActivitySim. However, it should take longer to run and the practical results are likely to be similar. (The loose handling of travel time in each of these approaches will likely result in a large number of infeasible itineraries in forecast years, but that's a broader problem with the CT-RAMP1 formulation and, as @lmz's alludes to, probably not worth considering to address the present problem).

[guyrousseau]

For additional contextual info and background on ARC's trip scheduling approach, this takes place as part of our intermediate stop duration model that we developed at ARC a few years ago. @jpn-- and @jfdman will remember this TRB paper we co-authored back then An intermediate stop duration model for the Atlanta activity-based model.pdf https://onlinepubs.trb.org/onlinepubs/conferences/2014/ITM/Resources/78.pdf, also attached