Explicit Park-and-Ride modeling and capacity constraint

[dhensle]

Is your feature request related to a problem? Please describe.
Park-and-ride is currently onerous to model. For most ActivitySim implementations, the selection of the actual PnR lot used for park-and-ride trips is handled through hyper-pathing in the commerical assignment software packages. These packages will generate probabilities across multiple paths including potentially different PnR lots and distributes the PnR demand coming out of ActivitySim along those paths.

Skims are then generated for PnR based on these paths. The skims are very expensive -- need to generate them for both directions (since the auto portion vs tansit portion changes based on inbound vs outbound) and all the normal transit variables like in vehicle time, cost, wait time, etc. Additionally, ActivitySim does not have any mechanism to implement capacity constraints on the PnR lots.

Proposed PnR methodology
We want to implement an explicit park-and-ride lot choice model in ActivitySim. This would run before tour mode choice. The choosers for this model are all tours that have walk-transit access at their destination end. The alternatives are all lots with non-zero PnR capacity.

Utilities used to make the choice are broken down into two components - auto from tour origin to PnR lot and walk-transit from PnR lot to destination. The number of parking spaces would act as the size term.

The PnR lot choice model output is the zone_id of the PnR lot the tour would use if that tour were to choose park-and-ride in the tour mode choice model. PnR utilities in tour mode choice would be built similarly as the lot choice model -- auto costs to lot + transit costs to destination.

Capacities at each lot can then be calculated after tour mode choice. Tours that arrive after the lot is full (or sampled randomly) can be re-simulated with a new PnR lot choice option with full lots removed and updated tour mode choice utilities. PnR lot choice and tour mode choice would iterate until all PnR lots are under capacity. This is very similar to how the simulation-based constraint mechanism in workplace location works.

Some minor updates to the write trip matrices is needed to split the PnR trips into auto and transit portions for the output demand matrices.

Implications

• Allows the removal of costly PnR skims
• Allows the ability to build utilities directly to PnR lots and eventually estimate the coefficients for PnR lot choice
• Allows the ability to track the PnR lot capacity and have tour mode choice respond
• PnR lot choice also needs to be run when calculating logsums in upstream models (there is an option to skip this but then the logsum would not include PnR availability)

Limitations / Future Enhancements

• Iterating only with tour mode choice does not allow people to change other aspects of their tour.
• Downstream stop attributes should be built from the PnR lot. (We are currently not allowing stops on drive-transit trips)
• Increase in runtime because we are adding another model, particularly in the logsum calculations.
• Getting PnR lot choices out of survey data is often not a trivial exercise for estimation. The first implementation of the model will have to rely on coefficients from tour mode choice before the model can be estimated.
• It makes tour mode choice calibration slightly more complicated.

Status
Development is underway according to the above design. An initial implementation is expected to be completed by the end of August 2025.

[DavidOry]

Thanks @dhensle, cc @ActivitySim/product.

Questions:

1. Is having this feature necessary for TransLink (or any other agency) to adopt ActivitySim as their production model?
2. Is there any other practical way for TransLink (or others) to incorporate this capability without it being incorporated into ActivitySim?
3. Do you know of other model owners who desire this functionality in ActivitySim?
4. What settings/configurations would model owners who did not want to use this feature need to contend with?
5. In the proposed approach, are the PnR lots coded as one of the regular zones? Or are they special dummy zones? Or are they MAZs?

[dhensle]

@DavidOry some responses

1. ODOT is also planning to use this feature. I can't speak to whether it is a deal breaker for them or TransLink for production.
2. No -- I initially started development on this as an extension and it was quickly abundantly obvious that was not the best way to go.
3. No, but @stefancoe did mention in a meeting the other day that PSRC was interested in better treatment of PNR. We have not had any other outside conversations about this functionality except for ODOT and TransLink. I imagine it would be useful for a lot of agencies.
4. Nothing would change for folks who do not want these features.
5. The zone selected is the same as the zones selected for any other destination choices in the model. If you have a 2-zone model, then the PnR zone id would be an MAZ. 1-zone is TAZ. Dummy zones are allowed, they just need to be coded as a TAZ / MAZ in the landuse and skims.

[DavidOry]

@DavidOry some responses

1. ODOT is also planning to use this feature. I can't speak to whether it is a deal breaker for them or TransLink for production.
2. No -- I initially started development on this as an extension and it was quickly abundantly obvious that was not the best way to go.
3. No, but @stefancoe did mention in a meeting the other day that PSRC was interested in better treatment of PNR. We have not had any other outside conversations about this functionality except for ODOT and TransLink. I imagine it would be useful for a lot of agencies.
4. Nothing would change for folks who do not want these features.
5. The zone selected is the same as the zones selected for any other destination choices in the model. If you have a 2-zone model, then the PnR zone id would be an MAZ. 1-zone is TAZ. Dummy zones are allowed, they just need to be coded as a TAZ / MAZ in the landuse and skims.

@bwentl, @bettinardi: Can you speak to question 1?

[bwentl]

@DavidOry some responses

1. ODOT is also planning to use this feature. I can't speak to whether it is a deal breaker for them or TransLink for production.
2. No -- I initially started development on this as an extension and it was quickly abundantly obvious that was not the best way to go.
3. No, but @stefancoe did mention in a meeting the other day that PSRC was interested in better treatment of PNR. We have not had any other outside conversations about this functionality except for ODOT and TransLink. I imagine it would be useful for a lot of agencies.
4. Nothing would change for folks who do not want these features.
5. The zone selected is the same as the zones selected for any other destination choices in the model. If you have a 2-zone model, then the PnR zone id would be an MAZ. 1-zone is TAZ. Dummy zones are allowed, they just need to be coded as a TAZ / MAZ in the landuse and skims.

@bwentl, @bettinardi: Can you speak to question 1?

@DavidOry

My team at TransLink has received a number of requests related to Park and Ride policies and forecasts, and our current trip-based model is capable of modeling Park and Ride, so Park and Ride modeling is definitely a necessary component of a production-ready activity-based model for our region.

Currently, our alpha/beta ActivitySim model relies on a "best lot" choice model with a Convolution Matrix Algorithm from our trip-based model, where the choice of lot is fixed for given OD pair. The aggregate best lot approach to Park and Ride also creates a large set of skim matrices that our activity-based model relies on. This is due to the need to maintain separate skim matrices for inbound and outbound directions, and both cost related to the auto leg (like driving time) the transit leg (like transit ivtt) need to be tracked separately. To illustrate the extra skim data needed, 1152 out of 1386 skim matrices in our skim data is used for park and ride and related kiss and ride and TNC and ride modes - which means we can achieve over 80% reduction in our skim input data size.

[bhargavasana]

There appears to be some overlap with #712

[stefancoe]

@DavidOry Having this feature is highly desirable for PSRC. We are replacing Daysim, which has similar functionality, so we currently do not have Park-and-Ride lot choice, assignment, and skimming as part of Soundcast. We have implemented some Emme Park-and-Ride procedures outside of Soundcast to provides skims for Activitysim for initial estimation/calibration, but we would really like to avoid having to fold these into Soundcast. So, if timing works out, we would prefer to use this feature.

[bettinardi]

"Is having this feature necessary for TransLink (or any other agency) to adopt ActivitySim as their production model?"

Oregon needs a PnR solution to move forward (I think similar to translink and PSRC). The question is worded a little awkwardly. Oregon is moving forward with ActivitySim as their production model. We are developing a PnR for that model. It seems like the path that we are on is that there will be a series of ActivitySim like functionality to make that PnR work. We should have gotten ActivitySim awareness and blessing from the start. I don't like these ask for forgiveness after developments. I don't think it (asking for forgiveness) was intentional. I think we were trying to solve PnR, for an ActivitySim deployment and this is where we are now. If it can help others, we would love to offer the solution to the partnership, and have it formally adopted, and I believe we are open to taking feedback and making revisions such that it is something that the larger partnership wants to absorb.

[bhargavasana]

I would like to acknowledge that both TransLink and ODOT are working on this and that PSRC is very interested in implementing this.

@dhensle is this only one solution that is being applied for both TransLink and ODOT? Also, is there a repo-branch currently that has this new work?

[dhensle]

@bhargavasana yes, one single solution. Code currently exists here (although I may be doing some branch management between the two projects in the near future).

[joecastiglione]

• Do we need to bring this into one of the example models? If so, how?
• Are the properties of PNR capacity constraint understood generally? In the SF-CHAMP / Daysim implementation, my recollection is that we tried using PNR capacity constraint but it proved problematic.
• More generally, are the properties of the simulation-based location choice sufficiently understood? I think one agency recently reverted to "traditional" shadow pricing. What was their concern wrt simulation-based method?
• How are travelers who drive to a PNR location but do not park in the formal lot accommodated (if at all)?