The dependencies are listed in dependencies.yml, it's recommended to create a conda environment using this file.
Almost all required data is included within the data folder. However, the Ontario Road Network, which is required to compute inter-regional trips, must be downloaded from the following link. Extract the zip file into the following path data/ontario_road_network/.
There is some analysis and visualization in the Jupyter notebook. Trips can be generated by executing the notebook end to end but this is no longer recommended.
The faster and more modular way to generate trips is to first generate a pool of sample trips for each Origin-Destination (OD) pair that actually travels within the AOI. Then trips can be sampled from each OD trip pool to any given distribution of trips throughout the day. This process saves much time by not having to regenerate trips from scratch everytime a new trip distribution is needed.
To run:
python generate_trip_samples.py [config dir]
This takes about 4 hours on a Ryzen 2700x @ 3.7 GHz base, using single thread. Once the sample trips are generated, new trips can be dynamically written using the TripSampler in trip_sampler.py, by passing in a dictionary of trip distributions by OD pair, where each value is another dictionary of where key: time, value: average number of trips. The trip distribution is used to generate a Poisson Process, where the average number of trips is used as the rate parameter. Writing of new trips using TripSampler usually takes <1 minute.
To generate all the trips statically (as in all trips for the day, generated according to a fixed distribution, where each trip is generated uniquely), run:
python generate_all_trips.py [config dir]
The default configuration files are located in the configs folder. The default configuration files can be modified, or new configuration files can be made and passed into the program as so:
usage: generate_all_trips.py [-h] [--sim-net-config SIM_NET_CONFIG] [--trip-planner-config TRIP_PLANNER_CONFIG] [--tts-data-config TTS_DATA_CONFIG] [--traffic-regions-config TRAFFIC_REGIONS_CONFIG] config
Generate SUMO Trips from Toronto Transit Survey Data
positional arguments:
config Config folder
optional arguments:
-h, --help show this help message and exit
--sim-net-config SIM_NET_CONFIG
to change default simulation net config file
--trip-planner-config TRIP_PLANNER_CONFIG
to change default trip planner config file
--tts-data-config TTS_DATA_CONFIG
to change default tts data config file
--traffic-regions-config TRAFFIC_REGIONS_CONFIG
This is an optional step, as the raw trips generated can be fed into SUMO and SUMO will dynamically assign routes to vehicles when they are inserted based on the current edge weights.
Once trips are generated, DUAROUTER can be run to generate routes for SUMO. For the most part, using DUAROUTER results in naive assignment and will result in bottlenecks where cars greedily choose the same path. However, this does result in faster simulation runs as SUMO does not have to dynamically assign vehicle routes.
Run:
duarouter --unsorted-input --ignore-errors --repair true --repair.from true --repair.to true -n data/tts_sumo/pruned_osm.net.xml --route-files [path to trip files] -o [path to output routes] --routing-threads [num routing threads]
Duaiterate uses DUAROUTER and SUMO iteratively to create routes and run the simulation to update edge weights. This should converge to the dynamic user equilibrium with enough iterations. The problem is that this takes too long to run for the entire simulation.
python duaIterate.py -n data/tts_sumo/pruned_osm.net.xml -t data/generated_trips/tts_630_1030.xml -C duarouter--routing-threads 12 sumo--threads 12 duarouter--unsorted-input duarouter--repair duarouter--repair.from duarouter--repair.to
To run the simulation, a sample SUMO config is provided in data/tts_sumo/tts.sumocfg. The route file is the only new file that is added once trips are generated and routed for SUMO.
To obtain the region of downtown Toronto used for this traffic scenario, the OSMWebWizard tool provided by SUMO is used, following this tutorial. The converted OSM map and the generated scenario are placed into a new folder in the same location as the osmWebWizard.py script.
The osm.net.xml file was copied over to the scenario folder and due to various errors in importing the speed limits on various roads, the network file was preprocessed by hand using the NETEDIT tool provided by SUMO. Most road speed limits were assigned based on prior knowledge of Toronto road limits generally being 40-60 km/h, but the City of Toronto's Vision Zero Mapping Tool with the Speed Reduction filter was used to verify certain downtown road speed limits.
After encountering various traffic jams when running the full Toronto scenario on the converted network, it was noted that OSMWebWizard does not by default set Traffic Light Systems (TLS) as "actuated", a setting that is recommended by SUMO. To modify the TLS after the fact, the following steps were taken.
The simulation network loads the generated SUMO Network from the OSM map of Downtown Toronto. The AOI Downtown boundary is defined in the simulation_net.cfg and should not be modified unless the AOI is changed. The traffic network nodes and edges are pruned based on the defined boundary and a new SUMO network is generated using NETCONVERT utility from SUMO. (Details on how to prune are located in the Prune SUMO Network section of the README)
The TTS Data comes in a txt format that is copied from the database output of the TTS portal. This data has to be parsed and processed in tts_data.py. The data processing includes smoothing of the trip counts with a triangle filter, as the counts are very bursty at 30 minute intervals due to the nature of the survey data collection.
The configuration file allows the user to define the interval size for trips (default to 5 minute) and the filter width for smoothing the trip counts (defaults to 7 to take a 15 minute before/after weighted average of trip counts). Additionally, file paths are defined in the configuration file.
All traffic region geometry is handled within the Traffic Regions class. The Traffic Regions class contains GeoPandas Dataframes and Series for the traffic zones, planning districts, regions, and highways, as determined by the TTS defined zones and the Ontario Road Network.
The Region Graph is used to determine if trips from and/or to external regions to the AOI, actually travel through the AOI. The Region Graph class builds a multigraph of planning districts as nodes and trivial and/or highway roads edges. The edges represent planning districts that are adjacent and defines multiple edges between planning districts. Adjacent planning districts by default have trivial edges which represent any non-highway road, if there is a highway connecting them another edge is added for the highway that has a lower weight (representing greater speed/capacity).
The Trip Planner does the bulk of the lifting in actually generating trips for SUMO. The configuration file allows the user to define:
- the inflow and outflow nodes for highways intersecting the AOI (this shouldn't be touched for the most part)
- the average trivial and highway speed (in km/h)
- the speed minimum and maximum factors (cutoffs for the truncated normal distribution that speed is sampled from)
- speed deviation for the normal distribution
- trip start and end timings (for generating a smaller time period)
- the minimum percentage of a trip's length that has to intersect the AOI to be considered as passing through AOI (only for straight line trivial trips)
- The maximum distance to locate inflow/outflow nodes for a straight line trip (samples from the closest nodes)
- The number of closest nodes to consider when sampling inflow/outflow node (weighted based on capacity = road_speed * lanes)
- The path length when doing inter planning district travel to consider a trip not to take highways (path length of 3 means path of [origin, via, destination])
To generate all trips, the Trip Planner takes about 8 hours on a Ryzen 2700x @ 3.7 GHz base. Work is being considered to multi thread this.
Although not strictly something implemented in this library, pruning of the SUMO network after conversion from OSM proved to be a task that challenged us. The easy way to do it is actually to use NETCONVERT from SUMO and convert from a SUMO network to another SUMO network.
To prune the SUMO network within a boundary or from a list of edges refer to this documentation and look at the NETCONVERT documentation in the edge removal section.
The command used in this library (in the prune_network function of the class Simulation_Net) was:
netconvert -s osm.net.xml --keep-edges.input-file edges_to_keep.txt -o osm_pruned.net.xml