Adding TNCs to ActivitySim

In response to Phase 5 Task 5. ActivitySim currently supports one zone system and so the approach to adding TNC assumes zone-to-zone skims and trips. In addition, ActivitySim is currently concerned with the generation of synthetic travel diaries (i.e. travel demand) and so considerations of supply side TNC modeling (such as deadheading) are not included.

Review of Existing ABM Approaches

The major AB modeling platforms in use today are:

• DaySim as represented by the PSRC SoundCast model and SFCTA SF-CHAMP model.
• CT-RAMP as represented by MTC Travel Model 1.5. The ARC, SANDAG, and Oregon DOT models are also versions of CT-RAMP.
• TourCast as represented by the MetCouncil model.
• CT-RAMP 2 as represented by the Ohio 3C and MAG models.

DaySim

A PaidRideShare (PRS) (e.g. Lyft, Uber) tour and trip mode was added in its own nest. DaySim does not have a taxi mode. DaySim has a PRS to transit access mode.

The tour and trip mode model utility for PRS is:

• Mode specific constant
• Generalized time
• Extra cost per mile (in addition to any toll costs) (applied for the travel group as a whole)
• Fixed cost per trip (applied for the travel group as a whole)
• Effects of the person’s age group
• Density coefficient applied to the number of jobs and households within the buffer around the trip or tour origin microzone/parcel, and it is a proxy for areas where TNC vehicles are most likely to be available

PRS can use either the SOV, HOV2 (default), or HOV3+ skims depending on the settings. DaySim randomly assigns a passenger occupancy to each trip based on input percentages by tour purpose.

PRS to transit is an additional transit access mode like drive-transit or kiss-n-ride. It uses the same PRS utility, but with PRS to transit specific settings in order to vary the coefficients in the context of transit access/egress. There are calibration constants by access mode, tour purpose, and auto availability level.

For more information see the DaySim documentation.

CT-RAMP MTC 1.5

A Taxi\TNC nest (called Mobility As a Service) was added to the TM1.5 tour and trip models. Within the nest are traditional taxi, single-party TNC (e.g. uberX), and shared TNC (e.g. uberPOOL). TM1.5 does not model TNC\taxi to transit.

The taxi\TNC utility is illustrated in this table and consists of:

• In-vehicle time
• Wait time (simulated from lognormal distributions by tour/trip origin land use density)
• Tolls
• Bridge toll
• Fare (Initial cost + cost per mile * distance + cost per minute * time)
• Alternative-specific constant
• In-vehicle time multiplier for shared TNCs to reflect out-of-direction travel to pick-up or drop-off additional customers

Taxi\TNC uses the HOV2 skims. There are calibration constants by tour type and auto availability level.

For more information see the TM1.5 documentation, UECs, and properties files.

The SANDAG multiple zone system CT-RAMP model, as well as the in-development MTC Travel Model Two, include a similar TNC design + TNC to transit.

TourCast

The Metropolitan Council's Tourcast model does not currently include TNCs as a travel mode. The Houston-Galveston Area Council is currently developing a TNC mode for their Tourcast model. TNCs in the H-GAV Tourcast model would be both a primary mode and an access-egress mode for transit. The mode choice model variables for TNC will include fares, in-vehicle time, and wait times (which will vary by area or zone). The TNC mode will not include parking costs and would use HOV skims.

CT-RAMP 2

• Includes taxi mode with utility = ivt_time + constant_fare + cost_per_mile * distance
• No wait time
• TNC mode applies modifiers to taxi mode
• Auto ownership uses an accessibility measure by TNC mode as well. The accessibility by TNC coefficient was asserted.

Suggested Approach

Replicate the TM1.5 approach for the ActivitySim example model. The ActivitySim example model is MTC TM1 and so there are many benefits to updating it with features from TM1.5:

• Utilization of a proven and validated approach
• Using existing expressions and settings to avoid errors
• Getting closer to the MTC production model so an MTC migration to ActivitySim is easier
• In addition, the TM1.5 approach includes basically everything in the DaySim approach except TNC to transit.

Some additional questions:

• How important is TNC to transit? It was < 1% of TNC trips in the SANDAG travel survey.
• How important is taxi? It was < 0.1% of trip modes in the SANDAG travel survey, but it is already in TM1.5 so let's just add it as well.
• What data is available to help answer these questions and validate the revisions?

No Python code is expected to be modified under the suggested approach. Adding new modes to tour and trip mode choice is done through revisions to the model step expression files and settings files.