social-transit-network-analysis

Preprocessing tools for analyzing the input network for a research project of mine dealing with a public transit design model with social access objectives (see project home page here). This is meant for use in analyzing the network after preprocessing with social-transit-solver-single, with which this repository shares a large amount of code.

Specifically, this is a set of programs meant for performing the following tasks:

• Loading Factor Calculation (C++)
• Stop-Level Metrics (C++)
• Candidate Express Route Generation (Mathematica)
• Solution Log Editing (Python)
• Solution Analysis (C++)

These procedures are explained in more detail below. They are so specific to my applications that I would not expect them to be useful to anyone outside of my research group, but they are being provided here for anyone interested.

Data Folder

This program reads input files from a local data/ folder. The following data files should be included in this folder:

• arc_data.txt
• gravity_metrics.txt
• final.txt
• initial_flows.txt
• initial_solution_log.txt
• node_data.txt
• objective_data.txt
• problem_data.txt
• solution.txt
• transit_data.txt
• user_cost_data.txt
• vehicle_data.txt

Most of these correspond to the standard network input files used by the other programs that are part of this project, except for gravity_metrics.txt and initial_flows.txt, which are produced by the preprocessor social-transit-solver-single, and except for final.txt and solution.txt, which are produced by the main solution algorithm social-transit-solver. See the other repositories' READMEs for format details.

Output Folder

This program writes output files to a local output/ folder. The following files are produced:

• arc_data.txt
• initial_flows.txt
• initial_solution_log.txt
• line_metrics.txt
• node_data.txt
• stop_metrics.txt
• transit_data.txt

The contents of these files will be explained below for their relevant sections.

Loading Factor Calculation

This is part of the main C++ program meant for helping to tune the assignment model parameters. We are currently using a frequency-based user assignment model from Spiess and Florian (1989) which makes use of a tuning parameter alpha to penalize overcrowding. This program outputs the loading factor of each individual arc, expressed as the initial flow:capacity ratio for each arc (with both flows and line capacities being calculated from the network's initial fleet assignment).

This program outputs no files, but prints the maximum and average loading factors to the screen. Seeing values significantly in excess of 1.0 indicates that alpha should be increased (although it should be noted that loading factors of up to 1.25 or so are generally assumed to be reasonable during rush hour).

Stop-Level Metrics

This is part of the main C++ program meant for help in selecting candidate express routes. Our assumption is that a "good" express route would make it easier to get from a low-access area to a high-access area, and so as a preliminary step we calculate the accessibility metrics of the transit stops, themselves. This is done with essentially the same code as the main solver, except that we treat transit stops as population centers rather than considering the population centers separately.

Two files are output by this program. The first is stop_metrics.txt, which simply contains a list of all stop node IDs along with their accessibility metric. The second is line_metrics.txt, which contains effectively the same information as the first file, but partitioned by line and sorted by access metric value in order to make it easier to find the highest and lowest few metrics for any given line.

Candidate Express Route Generation

This is a Mathematica notebook separate from the main C++ program for use in generating candidate express routes. We have chosen to use Mathematica simply because its built-in graph functions make evaluating connectivity much easier.

The general idea behind express route generation is, for each line, to pick a subset of the original stops consisting of only the highest few and lowest few accessibility metrics from the line_metrics.txt file. The line arcs of the express route are generated by finding the shortest paths between the corresponding stops in the original line, with a small amount of travel time deducted for each stop skipped.

The network definition files (arc_data.txt, initial_flows.txt, node_data.txt, and transit_data.txt) are all updated to include the express routes, each of which is assumed to begin with a fleet size of 0. The updated files are placed in the output/ folder in order to preserve the original versions.

The parameters for the express route generation process are defined and explained in the notebook file.

Solution Log Editing

This is a set of Python functions for editing solution logs between trial sets. Includes the following functions:

• log_merge(log_in1, log_in2, log_out): Accepts file paths to two existing solution logs and an output file path. Merges the two input logs into a single output log by combining all entries.
• feasibility_update(log_in, user_cost, log_out): Accepts file paths to a solution log file, user cost data file, and an output file path. Reads the initial user cost, percentage increase, and user cost component weights from the user cost file and uses it to re-evaluate the feasibility of all solution log entries.
• solution_expand(log_in, log_out, elements): Accepts file paths to an existing solution log file and an output file, as well as a number of elements. Generates a copy of the solution log with the specified number of 0's appended to the solution vectors. For use in converting an initial solution log into one usable by the express route version.
• solution_contract(log_in, log_out, elements): Accepts file paths to an existing solution log file and an output file, as well as a number of elements. Generates a copy of the solution log with the specified number of elements truncated from the solution vectors. If any truncated element is nonzero, the log entry is dropped since the corresponding solution is no longer feasible. For use in converting an express route log to one usable in the initial version.
• clear_unknown(log_in, log_out): Accepts file paths to an existing solution log file and an output file. Generates a copy of the given solution log with all unknown entries (feasibility status -1) dropped.
• lookup(log, sol): Accepts a solution log and a solution string and returns the solution log row.
• rewind(iteration, event_in, event_out, memory_in, memory_out): Accepts an iteration number, event log input/output paths, and memory log input/output paths. Alters the event log and memory log in order to rewind the search process to the specified iteration.

Solution Analysis

This is part of the main C++ program for analyzing the main solution algorithm outputs. Basic statistics are compiled for the solution log, and the final solution is processed to show which elements have changed by the most.