The Effective Integration of Analysis, Modeling, and Simulation Tools

PORTLAND, OR, TEST APPLICATION RESULTS

INTRODUCTION

This section describes the test application on a step-by-step basis to demonstrate the use of the AMS data hub through NeXTA for a multi-resolution arterial analysis along the NW 185th Avenue corridor and surrounding subarea. Starting with an existing regional TDM, PTV Visum^® was imported to the data hub in NeXTA for network and demand adjustments, and an assignment was performed using DTALite. The model was then exported to Synchro^® for signal timing modifications and deterministic analysis and then brought back through the AMS data hub into PTV Vissim^® for microsimulation analysis. Because of the congested nature of this geographic area, the application examined a time period from 2 p.m. to 7 p.m.

The steps for this Portland arterial application are summarized in this section.

Step 1—Export Network from Regional TDM

Portland Metro maintains the Portland regional TDM in PTV Visum^®. This network was converted to a set of shape files before importing it into NeXTA. This was accomplished using the shape file export function in PTV Visum^®. It is recommended to import the full regional TDM (assigned or unassigned) into the AMS data hub through NeXTA to retain accuracy. This network export is accomplished using the following steps:

1. Load the Network in PTV Visum^® and Export the Network as Shape Files

First, the network was loaded in PTV Visum^® as shown in Figure 28 .

©PTV Group^®
Figure 28. Illustration. Portland regional TDM loaded in PTV Visum^®.

By using the function in PTV Visum^® to export the network GIS shape files, the network is split into components and saved as multiple separate shape files. Users should select the node, link, zone, zone centroid, and connector layers to ensure that the conversion process can successfully create a new network in the AMS data hub. Exporting to shape files in PTV Visum^® requires the GIS interface shape add-on module. An example of PTV Visum^® shape file export options is shown in Figure 29.

©PTV Group^®
Figure 29. Screenshot. Shape file export options in PTV Visum^®.

Intermediate Step—Change Map Projection to WGS84

PTV Visum^® exports the shape files in the network’s current coordinate or map projection system. To simplify the conversion process, it is recommended to change from the NAD83 system to the WGS84 system before being imported into NeXTA. This process was completed using projection tools in the ESRI^® ArcGIS software.

2. Export Demand Tables/Matrices

The zone matrices in PTV Visum^® are compatible with the demand definition in NeXTA. Users should save the matrix files from PTV Visum^® into the "Format O" option when preparing tables for export to NeXTA. Exporting the demand matrices for the Portland TDM produces 20 demand tables describing the number of trips between zones for different demand types (single-occupant vehicle (SOV), high-occupancy vehicle (HOV), heavy trucks, and medium trucks) for the time period between 2 p.m. and 7 p.m., as shown in Figure 30 and Figure 31.

©PTV Group^®
Figure 30. Screenshot. Saving demand matrices in PTV Visum^® to be imported into NeXTA.

©PTV Group^®
Figure 31. Screenshot. Matrix export options in PTV Visum^®.

Step 2—Import Network from Regional TDM

The second step in the AMS data hub network conversion process is to use NeXTA’s network import tool to convert the network shape files into the AMS data hub format. This process reads the spatial data stored in each specified shape file, along with the corresponding data stored in the database file (DBF) to create the input CSV files used by the AMS data hub in NeXTA. In order to interpret the DBFs for conversion, an INI file is used to map field names between the shape files and the standard data format used in NeXTA.

The network import process is divided into the following three internal steps:

1. Prepare INI Configuration File and Attribute Files for Conversion

The first step in converting the network is to create an INI configuration file in the folder containing the exported shape files. NeXTA uses this user-defined configuration file to associate/map fields in shape file DBF files to the AMS data hub schema data format, allowing NeXTA to read the network geometry from shape files and create an AMS data hub compatible .tnp file.

The configuration file is divided into different sections depending on the type of data to be imported. The first section describes general model attributes and import options. The remaining sections are used to describe the different types of network objects that can be imported. Separate sections are used to import links and nodes, with optional sections for importing zones, zone centroids, and zonal connectors. Once a configuration file is established for a regional travel demand format, it can be replicated for future imports from that format. Since the Portland PTV Visum^® model has the intersection control type defined, this is brought into the AMS data hub in NeXTA through this conversion file.

2. Use NeXTA’s Import Network Tool to Convert the Network

Next, the regional TDM (network, demand, control, etc.) was imported into NeXTA through the INI configuration file created to link the shape files to the NeXTA format (see figure 32 and figure 33).

Figure 32. Screenshot. Network import menu location in NeXTA.

Figure 33. Screenshot. Import configuration INI file in NeXTA.

After the successful conversion process, NeXTA displays a "File Loading Status" window as shown in figure 34.

Figure 34. Screenshot. File loading status window displaying import results.

The final imported Portland network is shown in figure 35, which has 2,162 zones, 39,770 links, and 14,721 nodes. It should be noted that control type (signal, stop, and yield) is imported from the Portland PTV Visum^® network into NeXTA.

Figure 35. Illustration. Portland regional network imported into NeXTA/DTALite.

3. Save the New Network as a New Project File

The network was saved as a new .tnp file, which is the native file type for NeXTA.

Step 3—Read Demand Data from Regional TDM

Similar to the INI file, the input_demand_meta_data.csv file is used by NeXTA to find and read the O-D/trip tables (matrix (MTX) files from PTV Visum^®) exported from the TDM. This metadata file requires several entries. The relevant entries include the following:

1. Specify the demand file name (e.g., sov_14_15.mtx) and format (e.g., column).
   
   
2. Specify the number of lines in the demand file to be skipped by NeXTA (eight for MTX file).
   
   
3. Indicate whether subtotals are present in the last column (zero for none).
   
   
4. Specify the loading start time and end time for the demand file (e.g., 840 to 900 or 2 p.m. to 3 p.m.).
   
   
5. Specify the demand types associated with the demand file (only demand_type1).
   
   

Step 4—Run Assignment with DTALite to Equilibrium

Before a subarea is created for more detailed analyses, DTA is recommended to ensure equilibrium network path flows and thus reasonable trips entering the subarea.

DTA was performed with a DTALite assignment engine (directly accessed in NeXTA). Simulation settings should be edited in the input_scenario_settings.csv file prior to initiating the assignment engine (e.g., selecting simulation from one of the NeXTA toolbars).

DTALite is fairly efficient. For the Portland regional network with 15 simulation runs for about 1,100,000 vehicles, DTALite took 1 h13 min to complete on an Intel^® Core I7 2760QM (2.4–3.5 GHz quad core) with 32 GB RAM. This resulted in an average travel time of 26.18 min and an average trip length of 7.72 mi.

Step 5—Cut a Subarea within the Larger Model for More Detailed Analysis

For the 185th Avenue arterial network, a smaller focused subarea was defined by the highway interchange at the north and the light rail crossing to the south, encompassing 16 signalized intersections. NeXTA greatly simplifies the subarea creation process by automatically extracting necessary nodes, links, zones, and O-D tables when creating a subarea.

The subarea creation process is divided into the following four internal steps:

1. Create a Subarea Boundary in NeXTA

A subarea boundary was drawn around the NW 185th Avenue evaluation area used for this test case using the create subarea tool in NeXTA. After drawing the boundary, the links and nodes within the boundary were highlighted by NeXTA, as shown in figure 36. The highlight allows a visual assessment of the boundary, and adjustments can be made if needed.

Figure 36. Illustration. Subarea boundary selection for NW 185th Avenue subarea.

2. Use NeXTA’s Subarea Cut Tool to Clip the Network

The subarea cut tool automatically removed all of the network objects (nodes and links) outside of the subarea boundary and extracted links, nodes, zones, O-D pairs, and subarea path records. The resulting subarea network is shown in figure 37.

Figure 37. Illustration. Clipped subarea for the NW 185th Avenue subarea.

3. Convert Zonal Connectors to Side Streets Within the Subarea

This tool converts the zonal connectors to side streets within the network. It replaces zone centroids with additional nodes so that no paths can be routed through a zone centroid. While DTALite cannot use paths through zone centroids, other analysis software such as Synchro^® and PTV Vissim^® does not make such distinctions. Executing this command ensures that the resulting network is compatible with Synchro^® and PTV Vissim^®. The resulting network created by using this tool is shown in figure 38.

Figure 38. Illustration. Results from converting zonal connectors to side streets in the
NW 185th Avenue subarea.

4. Save the New Subarea Network as a New Project File

The last step is to save the new subarea network in a new project file.

Intermediate Step—Import or Approximate Signal Timing in NeXTA

Prior to adjusting demand (time shift and/or absolute adjustment) for the purposes of calibration (ODME), accurate or a reasonable approximation of signal timing should be established in NeXTA if the DTA engine to be used explicitly considers signal timing in its assignment (DynusT, DynaSmart, Dynameq, etc.). Since a typical TDM does not contain signal information, NeXTA can approximate signal phasing and timing using the HCM’s QEM, which is described in step 8. NeXTA can also import data from Synchro^® if signal timing already exists in this format.

Because the DTALite simulation engine is not dependent on signal timing to influence node or turning movement capacities, this step can occur later prior to exporting from the AMS data hub to Synchro^® or PTV Vissim^®.

Step 6—Prepare Field Data for ODME

ODME is a part of the calibration process to match link counts to simulated volumes. NeXTA’s ODME model reads field data from the input_sensor.csv file, which must be prepared before executing the ODME process. This input file uses a flexible format for reading multiple types of observed data in the network, including link volume, occupancy, speed, and travel time field data for specific locations and time periods, allowing for time-dependent ODME applications.

The NW 185th Avenue subarea field data were prepared from link volume counts collected at 21 locations on freeways and arterials in the subarea model, with hourly and 15-min link volume counts. Their locations are represented as green squares in figure 39.

Figure 39. Illustration. Subarea field data sensor locations for ODME in NeXTA.

Step 7—Run ODME Using Field Data for Calibration

To enable the ODME mode in NeXTA, the input_scenario_settings.csv file and the ODME_Settings.txt file must be set up. These files specify the number of iterations, the amount of adjustment allowed per iteration, the calibration time period that can be a portion of the simulation period, and weight on historical O-Ds.

For this example, the assignment engine was specified to run for five iterations to arrive at a relatively stable operating condition. The ODME module was then used to adjust path flows over the following 75 iterations. The ODME module in DTALite was set to adjust 5 percent of the O-D demand after each iteration, allowing the model to run to completion faster without sacrificing solution quality. Time-dependent link volume/count data were used for calibration, allowing for more detailed O-D flow refinements.

Two plots shown in figure 40 and figure 41 compare the observed and simulated link volumes/counts at the subarea sensor locations. The initial equilibrium assignment (before ODME) produced link volumes that were relatively similar to the observed link volumes with R² = 0.55, although under- and over-estimation was observed at multiple locations. After running ODME for 80 iterations, the under- and over-estimation was reduced, and the R² value improved to 0.79 over all observations.

Figure 40. Graph. Results before ODME for NW 185th Avenue subarea.

Figure 41. Graph. Results after ODME for NW 185th Avenue subarea.

Step 8—Export to Synchro^®/PTV Vissim^® for Signal Optimization and/or Microscopic Analysis

After the ODME process, the NW 185th Avenue arterial subarea was employed to assess operations and impacts of adding new links to the network. It was also exported to Synchro^® and PTV Vissim^® for further analysis. Since a typical TDM does not contain signal information, NeXTA can approximate signal phasing and timing using HCM’s QEM. This approach was used in this test application before exporting the network to Synchro^®. The procedure for exporting a subarea network for microscopic analysis is divided into the following three steps:

1. Use QEM to Estimate Initial Signal Phasing and Timing

An automated QEM spreadsheet is used to generate initial signal phasing and timings for the subarea network. NeXTA writes the geometry and volume information to the spreadsheet, the spreadsheet calculates appropriate phasing and timing data, and then NeXTA reads that phasing and timing data back into its files.

2. Export to Synchro^® Using UTDF CSV Format

NeXTA is capable of writing its network data in the UTDF format that is compatible with Synchro^®. The NW 185th Avenue study area is shown in Figure 42 after being imported into Synchro^®. The Synchro^® model was used to optimize the signal operation and produce traditional HCM-based delays and levels of service for intersections and arterials.

©Trafficware^® LLC
Figure 42. Screenshot. NW 185th Avenue subarea network imported into Synchro^®.

3. Export to PTV Vissim^® Using ANM Format

The NW 185th Avenue study area was also exported into PTV Vissim^® via the ANM format. The imported network in PTV Vissim^® is shown in Figure 43.

©PTV Group^®
Figure 43. Illustration. NW 185th Avenue subarea network imported in PTV Vissim^®.

SUMMARY

The Portland test application successfully demonstrated the seamless transfer between common AMS tools to facilitate from an established regional TDM to DTALite for mesoscopic analysis, Synchro^® for deterministic and signal timing analysis, and PTV Vissim^® for microscopic analysis.

The AMS data hub enables a host of time saving analysis features relative to the arterial multi-modal network. The following are key features highlighted as benefits of the AMS data hub:

• Import signal timing files from Synchro^® or automatically create signal timing parameters via QEM as a reasonable starting point for intersection capacity for DTA, deterministic, and microsimulation analyses.
  
  
• Quickly import existing TDM into multiple DTA platforms (e.g., DTALite and DynusT).
  
  
• Embedded tools and functionality in NeXTA to support the multi-resolution process through the AMS data hub including the following:
  • Visualization tools to quickly and easily compare link counts to simulated volumes (R² correlation).
    
    
  • CSV format to allow easy user modification of settings and data sources.
    
    
  • Easy demand adjustment tools to shift by time of day factoring or a full O-D matrix adjustment in ODME. This is particularly useful in model calibration, which can take the majority of time in AMS tools. This represents the potential for very large time savings.
    
    
  • MOEs and other visualizations in NeXTA to observe DTA level results (i.e., V/C ratio, queuing, travel time, reliability, etc.) in a time-dependent setting, which supports a new generation of performance measurements for system management (i.e., hours of congestion, travel time reliability, etc.).
    
    
  
  
  
• Export functionality to Google Maps^® and Google Earth^® allows for easy sharing of results in a common visualization package.
  
  

Much like the Tucson, AZ, application, this effort did not concentrate on generating actual results from the converted model. Instead, it focused on the functioning links created through the AMS data hub.

This Portland test application achieved its primary goal to demonstrate the usefulness of the AMS tool in solving real-world problems. NeXTA has overcome many issues to reach this level of integration; however, one challenge a typical user faces is becoming familiar with the NeXTA file format that comprises of many CSV files and entry fields and being able to set up CSV files manually. This can be overcome through training and through developing a more robust relational or object-oriented database system.

Beneficial NeXTA features noted during the test application include the following:

• Streamlining the conversion from a regional TDM to a DTA model: During the conversion, NeXTA predicted signal locations and assigned default signal parameters to these locations for the entire network. This automation function was a huge time saver since the signal information was not available in the Tucson regional demand model and needed to improve accuracy of the DTA network.
  
  
• Automating the creation of subarea: Once the subarea boundary was defined for the NW 185th Avenue corridor, NeXTA created all the necessary files for the subarea to function as an independent network. Preparation of the O-D matrix for the subarea would have been tedious, if not impossible, if it have been done manually.
  
  
• Automating the calibration of a DTA model via ODME: Once segment traffic counts were entered into the sensor input file, NeXTA/DTALite compared simulated volumes against field counts after each iteration and automatically adjusted vehicle paths and the O-D matrix. Other DTA packages would have required several steps and user intervention to achieve desirable results.
  
  
• Exporting a network to Synchro^® and PTV Vissim^®: NeXTA successfully converted the NW 185th Avenue subarea network into a Synchro^® network and PTV Vissim^® network. Many agencies still insist on the traditional HCM capacity analyses and level of service results. The linkage to Synchro^® (and similar HCM-based software) is beneficial to satisfy this requirement in a cost effective manner.
  
  
• Providing a comprehensive list of MOEs and visualization functions: NeXTA was used to visualize multiple MOEs, including time-dependent volume, speed, density, and queuing for individual links. NeXTA’s visualization tool for visually comparing observed traffic volume (from the sensor file) to simulated traffic volume over different time intervals was helpful in quickly assessing ODME calibration performance. Figure 44 shows an example of this application in which the blue line width displays the simulated link volume, and the purple cross-hatched line width displays the observed link volume on links with sensors (represented as green squares).
  
  

Figure 44. Illustration. Comparison of observed and simulated link volumes in the
NW 185th Avenue subarea in NeXTA.