En-Route Parking Search

When a vehicle is traveling on the network, the en-route parking search module determines whether and where the vehicle should park. This process models the real-world behavior of drivers searching for parking as they approach their destination—potentially cruising, rerouting, and settling for alternatives when their preferred parking is unavailable.

The en-route parking search is triggered only for single-occupancy vehicle (SOV) trips when parking simulation is enabled in the scenario settings.

The figure below shows the complete decision flow for the en-route parking search, from urgency check through the two search stages to the fallback.

Parking Urgency

At each link traversal, the vehicle checks whether the driver has an “urgency” to park. This urgency is computed by the person and represents the driver’s growing desire to find parking as they approach their destination. If the driver already has a planned parking lot (assigned by the pre-trip parking choice model), or if the destination zone is flagged as an internal zone with no simulation, the urgency check is skipped entirely.

When urgency is triggered, the vehicle begins actively searching for parking. If the driver does not yet feel urgent, the vehicle continues along its current route.

The urgency model is meant to be behavioral and person-specific. At this time a random search along the trajectory is used, but with targeted survey data, that will be updated in the future.

Search Process

The parking search follows a two-stage process, attempting to find parking first on the current link and then in the broader vicinity.

Stage 1: Current Link Search

The vehicle first checks parking associated with its current link:

1. Free parking: For each activity location on the link, the vehicle iterates through available free parking facilities. If a facility can accept a reservation for the anticipated parking duration, the vehicle claims it.

2. Paid non-garage parking: If no free parking is found, the vehicle checks paid parking facilities, excluding garages (which are handled by the pre-trip choice model). Again, the first facility that accepts a reservation is selected.

If parking is found on the current link:

• The vehicle’s movement plan destination is updated to the parking facility’s drive link.

• The walk link for the parking-to-destination leg is recorded.

• An en-route reroute is triggered for parking search purposes, truncating the remaining trajectory and computing a new path to the parking facility.

• The parking facility is stored as the driver’s planned parking lot.

Stage 2: Nearby Parking Search

If the vehicle has reached the end of its trajectory without finding parking (either the pre-trip choice failed or the planned lot was unavailable), it performs a broader spatial search:

The vehicle queries the network’s spatial index for nearby parking, cycling through the following types:

1. Unmetered on-street parking

2. Metered parking

3. Generic location-based parking

For each type, up to a configurable number of candidates are returned, sorted by distance. The search respects a maximum cruising distance threshold and can use either approximate or exact distance computation depending on the scenario configuration.

For each candidate within the distance threshold, the vehicle attempts to reserve a spot. On success:

• The movement plan is updated to route toward the parking facility.

• An en-route reroute is triggered.

• The planned parking lot is set.

Fallback: No Parking Found

If no parking can be found after both stages, the vehicle logs a parking record with Parking_ID = -1, indicating that the vehicle arrived at its destination without successfully parking. The record captures the destination link, location, vehicle, person, and time. This fallback ensures that failed parking searches are visible in the output data for analysis of parking supply adequacy.

Parking at Destination (Unload)

When a vehicle reaches its destination link, the unload process checks whether the person has a planned or assigned parking lot:

1. If a planned parking lot exists (from either pre-trip choice or en-route search), the facility’s parking operation is invoked. This formally parks the vehicle, records the event, and sets the vehicle status to parked.

2. If no parking lot is assigned (parking simulation is disabled or the destination is not simulated), the vehicle simply arrives at the destination normally.

After parking, the person agent transitions to walking from the parking facility to their final activity destination, using the walk link associated with the parking facility.

Interaction with En-Route Switching

The parking search integrates with POLARIS’ general en-route switching framework. When a parking location is identified:

• The cause for switching is set to parking search.

• The router computes a new shortest path from the vehicle’s current link to the parking facility’s link.

• The trajectory is updated in-place, replacing the remaining portion of the original route.

This means parking search can occur alongside other en-route switching decisions (e.g., congestion-based rerouting), with parking search taking priority when triggered.