• Row-oriented file format for tabular data
• Human readable
• Compatible with many tools and languages (including Excel!)
• Used in METROPOLIS2 for most input and output files (comma separator only)
• Recommended only for small-scale simulations, especially when using Excel

• Column-oriented file format for tabular data
• Binary file (= non human-readable)
• Built-in compression: smaller file size than CSV
• Very fast
• Compatible with Python (polars or pandas libraries) and R (arrow package)
• Used in METROPOLIS2 for most input and output files
• Recommended format for large-scale simulations and people working with R or Python

• One bottleneck at the entry and exit of each link
• Bottlenecks can be in two states: open or closed
• Bottlenecks are open by default and open bottlenecks can be crossed immediately
• When a vehicle cross a bottleneck, the bottleneck gets closed for a duration \[ \text{closing time} = \frac{\text{Vehicle PCE}}{\text{Bottleneck flow}} \]
• When a vehicle reaches a closed bottleneck, it is pushed to the back of the bottleneck queue
• When a closed bottleneck re-opens, the vehicle at the front of the queue can cross
• Question: bottleneck flow of 1200 PCE/h; a truck (3 PCEs) is crossing it; what is the closing time?
• Answer: 3 / (1/3) = 9

• Departure times [1, 3.5, 6]
• Arrival times [3, 7, 11]

• Each 2 seconds, a car is starting from node 1.
• One out of two cars is going to node 3, the other is going to node 4.
• Bottleneck capacity is large for edges 1 and 2 but small for edge 3.

• The bottleneck flow of a link is multiplied by the number of lanes
• The space available on the link is multiplied by the number of lanes (relevant for spillback only)

• When spillback is enabled, the road network can reach a state where some vehicles are permanently stuck
• The maximum pending duration defines the maximum amount of time a vehicle can be in a pending state
• After the maximum pending duration elapses, pending vehicles are forced onto the next edge

• edge_id: Identifier of the edge (positive integer, unique)
• source: Identifier of the source node (positive integer)
• target: Identifier of the target node (positive integer)
• speed: Free-flow speed on the edge (m/s)
• length: Length of the edge (m)

• bottleneck_flow: Maximum inflow and outflow of the edge (PCE/s)
• When the variable is omitted, the inflow and outflow are not limited

• overtaking: If `True`, vehicles can overtake other vehicles in the bottleneck queues if they are going to different edges
• Default value is `True`

• lanes: number of lanes available to vehicles on the edge (in the current direction)
• If omitted, the number of lanes is set to 1
• Non-integer values can be used

• With speed_density.type = "FreeFlow" (or when omitting the variable, the speed on the link is always equal to the free-flow speed
• With speed_density.type = "ThreeRegimes", the "Three Regimes" speed-density function is used and the following parameters need to be set: speed_density.min_density, speed_density.jam_density, speed_density.jam_speed and speed_density.beta

• constant_travel_time: time penalty that is added to the edge's travel time, in seconds
• Travel-time on the edge is (excluding the waiting times): \[ \text{constant\_travel\_time} + \frac{\text{length}}{\text{speed}(\text{density})} \]
• This penalty can represent delays which happen even under free-flow conditions (e.g., waiting at traffic lights, stopping at a stop sign)
• The default value is zero

• The METROPOLIS2 Routing algorithm cannot handle edges with the same source and target (parallel edges)
  
• Possible workaround if required:
  

• vehicle_id: Identifier of the vehicle (positive integer, unique)
• headway: Head-to-head length between two vehicles (m, used to compute edge's density)

• pce: Passenger-car equivalent for the vehicle (non-negative number)
• Used to compute the closing time of bottlenecks
• Default value is 1

• The "Multiplicator" speed function type can be used to increase / decrease the speed of vehicles by a multiplicative coefficient
• The "Piecewise" speed function type can be used to specify speed limits (e.g., vehicles limited to 90 km/h)
  
• Warning: lists are only supported for the Parquet format so the "Piecewise" type does not work for CSV

• Cars are allowed on all edges
• Motorcycles are only allowed on edges 1 and 2
• Trucks are allowed on all edges but edges 3 and 4
• Warning: lists are only supported for the Parquet format so the road restrictions do not work for CSV

• The parameters JSON input file contains configuration values for the simulation (e.g., path to the input files, simulated period, learning model)
• A part of the file is dedicated to road-network parameters
• The remaining parts will be covered during the next sessions

• recording_interval: time, in seconds, between two breakpoints in the edge-level travel-time functions (Mandatory; Recommendation: 5, 10 or 15 minutes for large-scale networks)
• approximation_bound: for a given travel-time function, if the difference between the maximum and the minimum travel time is smaller than this value, the function is represented as a constant function for optimization (Default: 0; Recommendation: between 0 and 5 seconds)

							{
								[...]
								"road_network": {
									"recording_interval": 300.0,
									"approximation_bound": 1.0,
									"spillback": true,
									"backward_wave_speed": 4.0,
									"max_pending_duration": 60.0,
									"constrain_inflow": true,
									"algorithm_type": "Best",
								},
								[...]
							}
						

• spillback: whether spillback congestion (queue propagation) is enabled (Default: TRUE; Recommendation: TRUE for more realistic congestion modeling)
• backward_wave_speed: speed at which the space taken by vehicles propagates backward upon exit (Default: instantaneous propagation; Recommendation: default or 15 km/h = 4.17 m/s)
• max_pending_duration: maximum amount of time a vehicle can stay in a pending state (Mandatory; Recommendation: between 30s and 5m, larger values are more realistic but generate more congestion)

							{
								[...]
								"road_network": {
									"recording_interval": 300.0,
									"approximation_bound": 1.0,
									"spillback": true,
									"backward_wave_speed": 4.0,
									"max_pending_duration": 60.0,
									"constrain_inflow": true,
									"algorithm_type": "Best",
								},
								[...]
							}
						

• constrain_inflow: whether bottlenecks limit vehicle inflow in addition to vehicle outflow (Default: TRUE; Recommendation: TRUE, set to FALSE to replicate MATSim behavior)
• algorithm_type: routing algorithm to use for profile queries, "Best", "TCH", or "Intersect" (Default: "Best"; Recommendation: "Intersect" for a smaller running time, "TCH" for a smaller memory consumption)

							{
								[...]
								"road_network": {
									"recording_interval": 300.0,
									"approximation_bound": 1.0,
									"spillback": true,
									"backward_wave_speed": 4.0,
									"max_pending_duration": 60.0,
									"constrain_inflow": true,
									"algorithm_type": "Best",
								},
								[...]
							}
						

• METROPOLIS2 relies on time-dependent Contraction Hierarchies algorithms
• Pre-processing phase: nodes are "contracted" from least "important" to most "important"; contracting a node entail removing it and the adjacent edges, while creating shortcut edges to maintain fastest paths
• Two types of queries:
  • Earliest-arrival query: Retrieve the earliest arrival time (= the minimum travel time) and the corresponding path, for a given origin-destination pair and departure time from origin
  • Profile query: Retrieve the travel-time function, for a given origin-destination pair (minimum travel time for all possible departure times)

• Input: Origin (Cergy); Destination (Saint-Denis); Departure-time (8 a.m.)
• Output: Arrival time: 9:10 a.m.
  

• Input: Origin (Cergy); Destination (Saint-Denis)
• Output:
  

• The routing algorithms of METROPOLIS2 can be used independently from the simulator: "Run routing" button on the GUI version or "routing_cli" executable on the CLI version
• Four input files:
  • Parameters (JSON)
  • Queries (CSV or Parquet)
  • Edges (CSV or Parquet)
  • [Optional] Edges' travel-time functions (CSV or Parquet)
• Three output files:
  • Earliest-arrival query results (CSV or Parquet)
  • Profile query results (CSV or Parquet)
  • Running times (JSON)

• Similar format than the Edges input file of METROPOLIS2
• Column travel_time: constant travel time on the edge

• When all the edges' travel-time functions are constant, the time-dependent routing algorithm is equivalent to a static routing algorithm
• The travel_time values can be set to something else (e.g., edge's length) and the algorithm will minimize with respect to this metric
• To compute the length of the shortest path, set the values to the edges' length and run earliest-arrival queries with a departure time of 0