U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590
Federal Highway Administration Research and Technology
Coordinating, Developing, and Delivering Highway Transportation Innovations
|This report is an archived publication and may contain dated technical, contact, and link information|
|Publication Number: FHWA-HRT-13-036 Date: August 2013|
Publication Number: FHWA-HRT-13-036
Date: August 2013
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.
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 .
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.
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.
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).
After the successful conversion process, NeXTA displays a "File Loading Status" window as shown in figure 34.
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.
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.
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:
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.
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.
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.
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.
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®.
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.
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 R2 = 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 R2 value improved to 0.79 over all observations.
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.
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.
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:
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: