First-Mile Last-Mile (FMLM)

The first-mile last-mile (FMLM) module extends the functionality of normal TNC operations to include trips to/from bus stations and rail stations. An FMLM trip/trajectory can consist of multiple legs of walking, riding an SAV, and riding transit. When a traveler takes an FMLM trip, the router finds the shortest path assuming average TNC wait time to start but then following travel times based on the auto network and prevailing condition. During the execution of the route, these travelers request a TNC ride and the TNC operator runs its algorithms for matching and sharing to get this request to its destination. The FMLM functionality can be turned on by specifying “Operator_1_use_fmlm” to be “true” for “Operator_1” in the tnc_fleet_model_file.

FMLM travel modes

A new mode is set up in the mode choice model called the TNC_AND_RIDE mode. TNC_AND_RIDE is the mode where the bus or rail is the main component of the transit travel and access or egress using a TNC vehicle forms a minor component. Note that the FMLM choices are not nested with any other choices in the mode choice model. For normal bus and rail trips, in which riders simply walk from/to stations, the station needs to be accessible by the walk threshold set in the MultiModalRouting.json file. However, FMLM-specific parameters in the MultiModalRouting.json file are available to control TNC access and egress.

Mode choice model

When the FMLM modes are considered and available for the mode choice model. Their utilities are calculated in the “Calculate_Utility_Specific” in “Mode_Choice_Methods.h”. Their utility functions incorporate different parts from other utility functions because no revealed data are available for calibrating the mode choice model for FMLM modes. Three different parts are included: 1) FMLM part that includes the alternative specific constants, travel cost of TNCs and rail. 2) demographic parameters and variables that are calibrated for the transit modes, 3) demographic parameters and variables that are calibrated for taxi modes. The utility functions of the two FMLM modes are calculated for different travel purposes: HBW, HBO, and NHB.

Multimodal Routing

The multimodal routing is used for modes involving transit segments. A multimodal route is calculated based on the multimodal shortest path, which is built based on the shortest link travel time from origin to destination, leveraging network links of any possible type (e.g., driving, walking, or transit links). The A* algorithm is used for calculating the shortest path. Basically, the algorithm finds new nearby nodes and updates the total cost from origin. The nearby nodes/links are found using a series of “Evaluate_Neighbor” functions in “Connection_Group_A_Star_Implementation”.

Adjustments and penalties are also incorporated to ensure a reasonable multimodal path, including the number of transfers, walking time, and driving distance. These are stored in “routing_data”: “routing_data.tncWaitCountThreshold” controls the total number of TNC legs that can exist in a multimodal trajectory. “routing_data.transitWaitCountThreshold” controls the total number of transit transfers that can exist in a multimodal trajectory. Transfers are allowed between different transit lines, and such transfers in between can involve either walking trips or not, to mimic the case when a person can transfer at the same station or walk to another nearby station for transfer.

“routing_data.fmlmMinDriveTimeSeconds” controls the minimum time that a TNC shortest path should take in the multimodal trajectory. This effort is to make the trajectory more realistic as well as reducing the computation burden.

Shifting back to non-FMLM modes

When a multimodal trajectory has been built, the trajectory is checked to see whether it is valid. Since the multimodal trajectory finds the best shortest path considering links of all possible modes. The trajectory may end up with no driving links or transit links. The trajectory is analyzed to see what kind of mode it should be, so the travel mode for this person is updated accordingly, to bus, rail, taxi or other non-motorized modes (i.e., walk mode for now). Changing the mode back to a personal car is not an option here.

Person mover following the FMLM trajectory

“Person_Mover_Methods.h” contains the detailed control methods for each person’s travel behavior. When a person is traveling using FMLM modes, “Movement_Event_ Controller” function will enter “Do_Multimodal_Movement”, which will further load events to schedule a person’s movement in the multimodal network. A person’s movement then changes based on the status of a person, when the person is in “arriving” status (i.e., TRAVELER_ARRIVING_SUBITERATION), “person_action_at_beginning_of_link” is evaluated. At this stage, the simulator updates a person’s and vehicle’s information, and check whether the next stage will change. When a person is waiting for a transit (i.e., TRAVELER_WAITING_SUBITERATION),“person_waiting_at_beginning_of_link” function is evaluated. When a person’s status is “rerouting” (i.e., TRAVELER_ REROUTING_SUBITERATION), “person_rerouting” function will be called due to excessive wait time for transit and the person will be shifted to other modes. Moreover, when the person is moving in transit (i.e., “TRAVELER_MOVING_SUBITERATION”), the “move_multimodal_person_to_next_link” function is also called to update the information.

The four statuses mentioned above apply to all the multimodal travel modes. When using FMLM modes, more details are checked in the “person_action_at_beginning_of_link” function. This function does a few things:

If the next link is a driving link but the travel mode is not FMLM, it is then a park-and-ride mode. In this case, an identified vehicle will be pushed to the network so that the person can drive to the transit station.

If the next link is a driving link and the travel mode is FMLM, then the next link in the trajectory that is not a drive link is looked up to obtain the trajectory of the TNC part of the FMLM trajectory. During the procedure, the origin and the destination of the TNC trajectory are also obtained. The request time of the FMLM service is also recorded. The next step is trying to assign a TNC to this FMLM rider. The assignment procedure is similar to the way that a rider is assigned to a TNC for the door-to-door service, however, when the rider cannot be matched to a TNC immediately, he/she will be waiting and always be evaluated 5 seconds later.

If the next link is neither transit link nor driving link, the person’s status is checked to see whether the person is on board now or not.

If the next link is transit link, meaning the person has just got on board of the transit. The responding information is then updated.

Feedback of wait time and access and egress time

To use feedback in the simulation run, the “tnc_feedback” should be turned to “true” in the scenario file. The wait time for TNCs, as well as the access and egress time to transit using TNCs are always written to the Result file for the simulations runs. However, when the simulation wants to read such information for a new feedback iteration, the “tnc_feedback” should be “true”. Another thing to mention here is the historical travel time is often read at the same time if the “tnc_feedback” is used, which means that “time_dependent_routing” in the input file should be turned to “true”.

If “tnc_feedback” is “false”, 10 minutes is used as the default for the access and egress time to transit. Default average wait time depends on the area type of the zones:

Currently, wait times for SAVs/TNCs/Taxis are in the SAEV-FMLM-MC branches and not in CAMPOchoice or SAEV-FMLM. In the Mode Choice Methods file one will find the if/else statement that either looks up the origin zone’s wait time for that hour from the Result file or uses the “avg_tnc_wait_time” value times 2 (so it is double the wait time shown in Figure 32). This is then added to the SOV skim travel time, which is adjusted with the SAV Fleet Model parameter accounting for VOTT adjustment with ridesharing (often around 0.70).

Output Analysis

The output of the FMLM can be checked in both the Demand file and Result file. In the Result file, the “Zone_FMLM_Acc_Egg_Times” table shows the access and egress travel time using TNCs between zone-based OD pairs.
The “ZoneWaitTimes” table shows the wait time for TNCs in every Zone. The “Traveler_Logsum” table shows the aggregated day-trip logsums of the mode choice model and destination choice model for every person.

In the Demand file, the “TNC_Trip” table contains the trip information of first-mile TNC and last-mile TNC trips, but the model has not differentiated these trips from normal TNC trips (those serving door-to-door). The “Trip” table shows the information of all modes. The TNC_AND_RIDE is mode 15, and TNC_AND_RAIL is mode 16. The “Path_Multimodal” table shows all the trips that were routed with multimodal routing, including those bus and rail trips, as well as trips of FMLM modes. One trip record presents the information of the whole trip, such as the origin, destination, and the travel time of different modes involved in the trip. The “Path_Multimodal_links” table then shows all route segments of the trips in “Path_Multimodal” table. By joining the trip id, one can extract the information of all TNC_AND_RIDE trip segments as follows:

SELECT t.*, pm.* FROM Trip t 
JOIN Path_Multimodal pm ON t.path_multimodal == pm.id
WHERE t.mode = 15;