Multimodal Routing, Assignment, and Simulation

Multimodal Routing, Assignment, and Simulation#

This section describes the multimodal network representation, intermodal routing, dynamic traffic assignment, and agent-based multimodal simulation modules.

Multimodal Network Representation#

POLARIS utilizes tree types of graphs, and the algorithms above operate on of these:

  • Highway graphs:

    • Static network graph: It is used by the point-to-point and skim routing algorithms for roadway vehicles, where the link-related and node-passing-related costs are NOT chaniging over time. When this graph is built, the time-dependent graph is not built.

    • Time-dependent network graph: It is used by the point-to-point and skim routing algorithms for roadway vehicles, where the link-related and node-passing-related costs are chaniging over time. When this graph is built, the static graph is not built.

  • Multimodal graph: This graph consists of links that comprise the roadway network, the transit network, the walking network, and the biking network. The nodes in this graph either connect the links of the same network or serve as a transfer node between networks. This graph supercedes the highway graph (static or time-dependent).

This section describes the process of adding transit and active transportation modes to an existing POLARIS network that originally only includes roadways. Transit models in POLARIS are typically created by importing GTFS data, which is provided by transit agencies. GTFS data includes information about stops, routes, trips, and schedules. Before being used in the model, the data undergoes transformations and consistency checks to ensure accuracy. An overview of the transit-related tables and their connections is provided in the schema below.

schema

The stop/station data is converted into the Transit Stops table, which represents the transit nodes in the multimodal network. Any two consecutive stops belonging to the same same service trip in the stop_times.txt becomes a transit link.

Transit routes can be represented as a sequence of stops or links, but many large transit agencies use the concept of Transit Patterns as show in the example figure below. These are unique sequences of stops served by a route, such as full-route patterns (1 & 4), short-turning patterns (2 & 5), or express service patterns (3 & 6). Patterns help optimize operations by focusing on high-demand origin-destination pairs. Interested readers can find the references to research that utilizes the concept of Transit Patterns.

patterns

Some agencies specify service patterns in GTFS using shape IDs, but many do not. To address this, unique stop sequences are identified for each route by analyzing trip data, generating distinct patterns. Routes are recorded as unique rows in the Transit Routes table, while patterns are stored in the Transit Patterns table. The Transit Pattern Links table lists link sequences for patterns, and the Transit Links table provides additional link details. Each [from node, to node, pattern ID] tuple represents a unique link. Transit Patterns play a crucial role in the POLARIS data model.

Using the calendar and calendar dates files along with service_ids, it is possible to determine active trips on a specific date, e.g., a typical weekday. These trips are listed as single-row entries in the Transit Trips table, with their schedules detailed in the Transit Trips Schedule table. A transit pattern with k rows in the Transit Pattern Links table will have k+1 rows in the Transit Trips Schedule table, corresponding to the number of stops.

The POLARIS transit data model also includes fare information, which is almost a direct import from the GTFS database. Interested readers are encouraged to refer to GTFS reference for further details.

In study areas with multiple agencies, the data importer consolidates information into a Transit Agencies table, assigning each agency a unique integer ID: agency ID. Routes and stops are linked to their respective agencies via this ID, and affiliations are managed through foreign key references. For example, each trip is tied to a unique pattern, each pattern to a unique route, and each route to a unique agency. Additionally, x_id represents a unique integer primary key in POLARIS, while x refers to the original ID from the GTFS database.

The POLARIS transit data model includes tables for walk and bike (micromobility) access to transit, created through post-processing. The process integrates four sub-networks: driving, walking, transit, and micromobility. Initially, driving and transit networks are separate, with driving nodes and links forming the base. Walking links are generated by copying driving links, removing non-walkable links (e.g., freeways), and adding additional walking links if needed. The walking and driving networks are then connected using common nodes. Next, transit and micromobility nodes are projected onto walking links, generating new nodes at the projection points, bisecting the links. Virtual walking links connect the new nodes to original transit nodes, linking walking, driving, and transit networks. This process is repeated for micromobility, fully integrating all four sub-networks.

network

Finally, POLARIS transit networks can be fully edited through a comprehensive Python API that allows:

  • Modifying existing transit pattern sequences using the existing stops,

  • Defining new transit patterns for a given route using the existing stops,

  • Adding new stops,

    • Using those stops to create new routes,

      • In case of bus rapid transit (BRT) routes, dedicating lanes to BRT,

    • Using those stops to create new patterns for existing routes,

    • Using those stops to modify existing patterns,

  • Removing stops and then correctly updating all the pattern and trip schedule information,

  • Updating frequencies,

    • Manually or using certain rules applying to certain agencies, routes, time- windows etc.,

    • Using optimization techniques

  • Updating speeds.

Interested readers are encouraged to read the following unpublished paper for more details.

Intermodal Routing#

For intermodal routing, see routing documentation.

Simulation-Based Dynamic Traffic Assignment#

Capturing the circular relationship between routing decisions and network conditions is vital for network models. Dynamic Traffic Assignment (DTA) models address this by accounting for temporal changes in network conditions. Simulation-based DTA, while less analytically rigorous, excels at modeling space-time traffic flow, vehicle interactions, and travel costs on routes and links. POLARIS employs a simulation-based DTA framework for traffic assignment. For further details

Simulation-based transportation models use an iterative process involving finding shortest paths, assigning travelers, simulating traffic, and recalculating paths. Since travel times cannot be expressed analytically as a function of link loads, these models use specific techniques to decide whether travelers stay on existing paths or switch to newly identified shortest paths. Unlike the random selection in the method of successive averages (MSA) method, gap-based approaches prioritize travelers with larger gaps, i.e.significant differences between experienced and routed travel times, making them more likely to switch paths. This method has proven to be highly effective.

The POLARIS DTA framework enhances the gap-based approach by incorporating information mixing. It uses the gap between routed and experienced travel times from the previous iteration to guide reassignment decisions. Additionally, POLARIS averages historical and current traffic conditions into an expected value for each traveler, weighted using a modified two-parameter Weibull survival function. This weight is personalized based on the traveler’s relative gap and the iteration number, a unique feature of the framework.

Interested readers are encouraged to read the following Agent-Based Dynamic Traffic Assignment with Information Mixing paper for modeling and this unpublished paper for a broader literature review.

Agent-Based Multimodal Simulation#

This subsection focuses on the movement of travelers and vehicles from a transit-centered perspective. For traffic simulation, i.e. the simulation of roadway vehicles see Capacity Based Model.

After being assigned a route, travelers move through the network one link at a time. Likewise, transit vehicles navigate the network according to their pre-assigned GTFS schedules or based on mixed-traffic conditions. The flowchart below illustrates the interaction between the person and transit vehicle submodules.

transit_simulation

The link-by-link actions for a given traveler are:

  • Walking/biking/driving

  • Waiting for a transit or TNC vehicle

  • Boarding a transit or a TNC vehicle

  • Traveling in a transit or TNC vehicle

    • Standing

    • Seating

  • Alighting

  • Being rejected to board

  • Re-routing

  • Picking (undocking) a micromobility vehicle

  • Dropping (docking) a micromobility vehicle

The link-by-link actions for a given transit vehicle are:

  • Moving

    • In the transit network

      • According to the GTFS schedule if train or mixed-traffic setting is off

      • Signalled by its twin in the traffic layer, if it is a bus and mixed-traffic setting is on

    • In the driving network

      • If it is a bus and mixed-traffic setting is on, it signals its twin on the transit layer

  • Accepting travelers to board

    • Making them stand

    • Making them take a seat

  • Letting travelers alight

  • Rejecting travelers due to capacity

The parallel movement of buses in the transit and driving network layers relies on the Transit Pattern Mapping table. The routing algorithm evaluates transit links for decision-making but updates their travel times based on traffic conditions.

See the image below for simulation details. Transit nodes and links (blue) operate alongside driving nodes and links (black), with trigger points (black-and-blue) linking the two layers. A blue bus agent begins its trip at the first transit node per the GTFS schedule. If mixed-traffic is off, it strictly follows the schedule. Otherwise, as the black twin bus moves through the driving network and crosses trigger points—representing transit stop locations on driving links, the blue twin advances to its corresponding transit node. Passengers board and alight via the blue twin, moving along the transit network layer.

Buses_in_Network

Interested readers are encouraged to read the following unpublished paper for more details.

Key articles by the team#

Important

Please refer to the the following papers for more details:

  • Auld, J., Hope, M., Ley, H., Sokolov, V., Xu, B., Zhang, K. (2016). Polaris: Agent- based modeling framework development and implementation for integrated travel demand and network and operations simulations. Transportation Research Part C: Emerging Technologies 64, 101–116. DOI: 10.1016/j.trc.2015.07.017.

  • Verbas, O., Auld, J., Ley, H., Weimer, R., Driscoll, S. (2018). Time-dependent inter- modal a* algorithm: Methodology and implementation on a large-scale network. Transportation Research Record 2672, 219–230. DOI: 10.1177/0361198118796402.

  • Auld, J., Verbas, O., Stinson, M. (2019). Agent-based dynamic traffic assign- ment with information mixing. Procedia Computer Science 151, 864–869. DOI: 10.1016/j.procs.2019.04.119.

  • Verbas, O., Cokyasar , T. , Camargo, P. V. d., Gurumurthy, K. M., Zuniga-Garcia, N., & Auld, J. (2025). Modeling transit in a fully integrated agent-based framework: Methodology and large-scale application. Available at https://arxiv.org/abs/2408.05176.

References#

  • General Transit Feed Specification (2025). https://gtfs.org/documentation/schedule/reference/.