The Effective Integration of Analysis, Modeling, and Simulation Tools

APPENDIX B. DATA SCHEMA

This section describes a unified data structure that facilitates input/output data conversion in the short term and promotes data consistency and exchange in the long term.

The component diagram shown in figure 3 illustrates the relationship of the nine tables in the proposed database schema. A few notes regarding the component diagram are as follows:

• The arrow indicates the parent-child relationship. For example, a zone can have one or more links; a link can have nodes, demands, or performance measures; a node can have a signal, stop-control, or roundabout; etc.
  
  
• The signals and trajectory tables are currently applicable only to mesoscopic and microscopic resolutions.
  
  
• As previously mentioned, HCM-based tools fall between the mesoscopic and microscopic categories. As such, some table data are applicable to the HCM-based tools.
  
  
• The configuration table is independent of the other tables.
  
  

Advantages of the database schema are as follows:

• It is software neutral, meaning it can be applied using any software program.
  
  
• The database tables that are initially proposed can be expanded in the future.
  
  
• Software can be configured to read all or a subset of parameters in a table.
  
  
• A software vendor can add field parameters that are specific to its product.
  
  
• Links and nodes are geo-coded and thus are more easily integrate with GIS and other visualizers such as Google Maps^®.
  
  
• Since the data structure is transparently and openly defined, it can be readily scrutinized, tested, and enhanced.
  
  
• The database schema can serve as a platform to encourage the development of analysis tools and visualization tools, especially from small software vendors and researchers.
  
  
• The database schema moves the practice of integrated modeling towards a standard for how modeling data should be stored and shared.
  
  

One major disadvantage of such an overarching, unified data schema is its size, which has an adverse effect on computation speed and efficiency. The data structure is understandably large in order to accommodate analysis models in various resolutions. As such, a single intersection analysis using the HCM method would utilize only a small portion of the data structure.

A description for each of the components of the database schema is provided in the following subsections. The descriptions are general in nature, but the database schema can be implemented in XML or a database format.

DATABASE SYSTEM

The data hub will need to be able to handle a wide variety of data types, some of which are complex. Examples of simple and complex data types include the following:

Simple Data Types:

• Strings: Alphanumeric fields that are typically short (less than 200 characters) and contain descriptive or type data.
  
  
• Integers: Used for floating point numbers.
  
  

Complex Data Types:

• Coordinates: Used to specify geographic locations of points such as nodes. A series of coordinates is used to define a shape such as a link or a zone boundary. Coordinates are specified in a predefined system (e.g., latitude/longitude or UTM).
  
  
• Geometry: Needed to specify boundaries, in the case of zones, or paths, in the case
  of links.
  
  

In the proposed database schema, the data type definitions listed in table 6.

ZONES

Existing Practice

In the existing practice, zones are used in TDM and DTA. TDMs include TAZs that typically list the number of automobiles per household, household income, and employment. DTA models also adopt the TAZs from TDMs. In addition, DTA models like DynusT introduce super zones, which comprise of one or more zones for evacuation evaluation. Synchro^® also uses the zone concept to divide a network into zones to facilitate signal optimization or output for a portion of the network. Microsimulation software, most HCM-based tools, and field data do not use the zone concept.

Challenges

Generally, there are no obvious challenges to define zones for all resolutions. However, a few minor definition issues include the following:

• A link can be dissected by a zone boundary and as a result is physically located in more than one zone. One solution is to include Link_a in Zone_i if more than 50 percent of the link length is located within Zone_i. In rare cases where a link is evenly split between two zones, the link can be assigned to the zone with fewer links or smaller ID.
  
  
• When zones are manually defined by an analyst, it is possible that there are portions of a network that do not belong to any zone. A function should be included in the user interface (such as NeXTA) to check for and correct these gaps.
  
  

Proposed Structure

The data structure proposed for zones (see table 12) meets current AMS needs and provides the flexibility to expand in the future. In this structure, a zone can have many nodes and links. Specifically, a zone is the "parent" of nodes and links. For consistency, it is suggested that a zone is initially defined in accordance with TAZs and that a super zone or jurisdiction is a collection of zones.

Table 12. Proposed zones data structure.

The subarea cut table is a subset of the zones table. Each subarea table contains data and information about a smaller study area or a corridor as well as links to other tables that allow detailed analyses to be conducted. Subset table with sample fields for a subarea is illustrated in table 13.

Table 13. Subarea zone table with sample subarea fields.

The zone socioeconomic table maintains socioeconomic data for each TAZ. These data will change with each scenario. Table 14 shows some types of data that would go into a socioeconomic table. Note that different planning agencies have their own definitions of socioeconomic variables that are used for travel forecasting. Examples are as follows:

• Households can be divided into the following different groups:
  • Dwelling unit types (e.g., single family, multi-family, etc.).
    
    
  • Income categories (e.g., income quartiles).
    
    
  • Age of head.
    
    
  • Auto ownership category.
    
    
  
  
  
• Employment is often divided into different categories (e.g., manufacturing, service, retail, etc.).
  
  

Table 14. Socioeconomic zone table with sample subarea fields.

NODES

Existing Practice

A node is generally created at an intersection or where some roadway characteristics change(i.e., merge or diverge gore, change in free-flow or posted speed, change in horizontal or vertical alignment, etc.). Other reasons for the creation of nodes include the following:

• Specific software requirements: Some software tools require entry nodes, exit nodes, dummy nodes, or interface nodes to mimic a network. These nodes have minimal or no real-world properties.
  
  
• Software limitations: Some software tools include comprehensive link properties while others do not. For the latter, nodes must be inserted to break up the link in order to model changes in the link properties.
  
  
• Link statistics: Statistics are typically gathered and averaged over an entire link. This may lead to misrepresentation of the link performance, especially for long links. Where there is variation in the vehicle flow or congestion, nodes are often inserted to create shorter links (around 500 to 1,500 ft).
  
  
• TAZ centroids: Previous practice has been to have a single node for each TAZ. This node is ideally located at the TAZ centroid, such that connectors from the centroid to the road network are representative of average travel times from the TAZ to the rest of the transportation network. The newer activity-based models often require much finer-grained representation of connections of different TAZ subareas (or even individual land parcels) to the transportation network. Hence, the trend is to have multiple nodes to represent different subareas within each TAZ.
  
  

It should be noted that some software tools create nodes automatically and store them internally when links are created. Some tools define nodes as locations where statistics need to be collected, and they have no physical attributes.

Challenges

Some challenges when integrating different datasets include the following:

• Some software tools have limitations on the number of nodes and numbering scheme.
  
  
• Some software tools do not use nodes explicitly. PTV Vissim^® uses connectors to store properties that may often be associated with nodes.
  
  
• Some software tools generate nodes automatically.
  
  

Proposed Structure

Similar to the link table, the data structure proposed for nodes aims to replicate the physical real-world conditions as much as possible. The goal is to rely on software developers or conversion modules to aggregate the data into a format usable by specific software. Some suggestive guidelines for node creation and placement include the following:

• More than one node may be required to adequately represent connections between different subareas of the TAZ to the transportation network.
  
  
• Nodes should be used to represent signalized intersections, roundabouts, stop-control intersections, yield control intersections, major driveways, and merge/diverge areas.
  
  
• Intermediate nodes should be used to limit link length to 1,500 ft.
  
  
• For freeway merge and diverge locations, nodes should be placed where edge stripes meet.
  
  
• For intersections, nodes should be placed at the middle of the intersections. Node properties such as stop bar locations can be employed to delineate the intersections’ dimensions.
  
  
• Node locations should be geo-coded so that they can be displayed in Google Maps^®/Google Earth^® or synchronized with various GIS layers.
  
  

A normalized table structure for nodes is recommended as follows:

• Geographic features that will not change (i.e., node location) are kept in one table.
  
  
• Geometric features may change with different scenarios. For example, for some nodes, left turns may not be permitted during peak hours.
  
  
• Traffic volumes will change with scenarios and are therefore represented in a separate table.
  
  

Sample fields in the node tables include the following:

• Table 15 shows the base node table. The table is limited to defining the node location, node type, and the TAZ that contains the node.
  
  
• Table 16 shows the node geometry table. There is one record per approach for each node. Because node geometry may change with scenarios, separate records are required for each scenario.
  
  
• Table 17 shows the table for node volumes. There is one record per approach for each node.
  
  

The node volumes, node geometry, and signal phasing tables are used to develop MOEs.

Table 15. Sample fields in the base node table.

Table 16. Sample fields in the node geometry table.

Table 17. Sample fields in the node volume table.

LINKS

Existing Practice

A link is generally defined as a roadway segment with uniform geometry and traffic operation conditions. However, each software tool may provide its own guidelines to suit its needs. Depending on a software’s methodologies and procedures, link property requirements also vary. Additional differences are also introduced by the analyst as he/she molds the field data into a form required by the analysis software. Examples of link definitions and their properties are as follows:

• In CORSIM^TM, all links are directional and defined by the analyst with an upstream node and downstream node. Since a node does not have physical dimensions and link curvature is not accounted for, the analyst must often override CORSIM^TM estimated link length with an actual field value.
  
  
• In an HCM-based tool, a weaving link is defined by a point at the merge gore where the edge stripes are 2 ft apart and by a point at the diverge gore where the two edges are 12 ft apart. In other analysis tools, these two points are loosely defined by the analyst.
  
  
• In a TDM like PTV Visum^®, only major road segment are coded. As such, a link in PTV Visum^® may be split up into three PTV Vissim^® links to account for significant driveways or minor intersections.
  
  

Challenges

Some challenges when integrating different datasets include the following:

• TDM tools typically define bidirectional links, while others only work with directional links.
  
  
• Some software tools require entry links, exit links, or dummy links.
  
  
• Some software tools require more link properties than others. For example, TDMs do not typically ask for lane-add/lane-drop, turn lanes, storage, median, lane width, etc.
  
  

Proposed Structure

The data structure proposed for links aims to allow analysts to rely on software tools or conversion modules to mold the physical field data into a format usable by the software. Key features of the proposed link table include the following:

• Replicates the physical real-world data as much as possible.
  
  
• Complements or replaces formats that agencies use for roadway log/inventory.
  
  
• Geo-codes all links so that they can be displayed in Google Maps^®/Google Earth^® or synchronized with various GIS layers.
  
  
• Stores all link properties at the lowest common denominator and lets software tools aggregate the data to needed levels.
  
  

Sample fields in the link table are shown in table 18 through table 20. It should be noted that the fields can be defined to optimize data exchange among software platforms in the short term and progressively refined to replicate real-world conditions in the long term. Note that the table structure is normalized as with the node table structure. The tables are as follows:

• Table 18 shows sample fields in the link table, which defines the link type, begin and end nodes, the path followed by the link, and the functional class.
  
  
• Table 19 defines link characteristics related to capacity such as number of lanes, capacity, and free-flow speed. Note that there could be two link geometry records for each link depending on the directionality of the link. If the link is bidirectional, there will be separate records for node A to node B and node B to node A.
  
  
• Table 20 stores traffic volumes for a particular scenario.
  
  

Table 18. Sample fields in the link table.

Table 19. Sample fields in the link geometry table.

Table 20. Sample fields in the link volume table.

DEMANDS

Existing Practice

Different analysis resolutions require different traffic demand resolutions. Requirements for each of the four analysis resolutions are as follows:

• A traditional TDM typically outputs several types of trip tables. Production/attraction tables are intermediate person trip tables that are output from the trip generation and trip distribution process. O-D tables are person trip or vehicle trip tables that are used in the assignment process. Separate trip tables are produced by trip purpose and mode, and time-of-day trip tables are used for assigning passenger trips and vehicle trips to the transit and road networks. Different agencies have different time-of-day definitions. For example, a small agency might work only with daily trip tables, another agency might have a morning peak and an off-peak trip table, and a third agency may have separate trip tables for morning peak, afternoon peak, midday, and late night/early morning.
  
  
• Activity-based TDMs output individual trip records for individuals in a synthetic population that is intended to represent the population of the modeling region. Each trip record contains information that includes a weighting factor, travel mode, O-D, and some socioeconomic characteristics of the individual that could be used for more refined analyses (e.g., environmental justice analyses). Most activity models in use today rely on traditional network assignment procedures to get link volumes and level of service. As a result, these trip records are rolled up into traditional trip tables by mode and time of day.
  
  
• HCM-based tools typically analyze the peak 15-min volumes. An analyst may collect 1+ h of volume data during the peak morning and afternoon periods and then filter the data to isolate the heaviest 15-min interval for analysis.
  
  
• DTA models typically start with O-D matrices from a TDM and then adjust them to derive hourly or 15-min volumes.
  
  
• Microsimulation models often work with 15-min volumes that span the 1 to 2-h analysis period. Even though not frequently done, traffic variation every 1 or 5 min can be specified for each 15-min interval.
  
  
• Detailed traffic count data are kept for purposes of monitoring and validation.
  
  

In addition to the analysis practices mentioned, demand resolutions also vary in field data. For instance, many agencies collect and archive detector loop data. Raw data come in as time stamps which can then be aggregated to generate 1-min, 5-min, 15-min, hourly, 24-h, weekly, or monthly volumes. Due to processing speed and storage cost, not all of the data resolutions are stored nor are they retained for the same period of time.

Challenges

The brief summary in the previous section illustrates the difficulties encountered when attempting to integrate demand requirements for various modeling resolutions. Theoretically, traffic demands can be stored at the lowest common denominator (e.g., 20-s or 1-min volumes) to serve microsimulation analyses and then aggregated for other analysis resolutions. However, this approach is not currently practical for the following reasons:

• The original source of demand data for future years is from regional TDMs. Travel models output results by time period, which is typically at a very coarse resolution compared to that required by DTA and microsimulation models (e.g., a 3- to 4- h peak period). Current year traffic count data are typically used to break down travel model outputs into finer resolutions (i.e., 15 min or less).
  
  
• A large amount of 20-s or 1-min data can be unwieldy (i.e., difficult to store and work with).
  
  
• 20-s or 1-min data are not often collected and stored for all network links.
  
  
• Some link and node volumes are derived from land use data in TDMs. As a result, it is not possible to develop fine resolution volumes.
  
  

Proposed Structure

To satisfy various traffic demand levels, a demands table comprising of subsets for each modeling resolution is proposed. It is envisioned that demands in one subset may be derived from another subset, from analysis results, or from field data. Demand table fields are as follows:

• Table 21 shows the fields in the data table for activity model output. These tables are typically not used directly unless a more detailed analysis based on traveler socioeconomic characteristics is desired.
  
  
• Table 22 shows the fields in a data table for O-D model output from a traditional four-step model. These data are also produced by activity models as a precursor to the assignment phase of modeling.
  
  
• Table 23 shows the fields in a production/attraction table that is typical of an intermediate table in the traditional four-step modeling process.
  
  
• Table 24 shows the structure of a demand table for finer resolution analysis. This table is typically produced by breaking down travel model outputs at a coarser resolution (e.g., morning peak) using traffic count data.
  
  
• Table 25 shows the fields in the data table for traffic count data. These data may come from automated and manual field measurements.
  
  

Table 21. Demand for activity-based TDMs.

Table 22. O-D for assignment in regional TDM.

Table 23. Production/attraction trip from four-step model.

Table 24. Higher time resolution for DTA or operations analysis.

Table 25. Traffic count.

TRANSIT

Existing Practice

Transit is coded as part of a regional transportation network. Transit is typically coded as a set of transit lines. Each transit line record contains a code for the mode (e.g., bus, rail, etc.), a code for the individual transit operator, a list of nodes along which the line runs, the service headway (with provision for specifying different peak and off-peak headways), and a code for the speed, which can be entered either as a factor related to the auto speed on a link or as an absolute speed (the latter is the format for transit lines with a separate right-of-way). Transit information also includes a fare matrix, which specifies TAZ-to-TAZ fares. Travel modeling software is becoming increasingly sophisticated with regard to transit, providing more detail on transit characteristics such as line specification, transit speeds, allowance for transit vehicle capacity limitations, and specification of allowable transfers between different transit routes.

Automated vehicle location (AVL) and automated passenger counting (APC) are being implemented on larger systems. AVL provides real-time transit vehicle arrival information at each transit stop or station. APC provides information on individual vehicle boardings and alightings at individual stops.

Google^® has recently launched Google Transit^®, which provides real-time transit information for over 120 transit operators in more than 475 cities in 36 U.S. States and 7 Canadian provinces. Development of this new application has entailed development of a new database schema called General Transit Feed Specification (GTFS) to allow transit operators to provide their information to Google^® in a unified format. Because of its widespread and growing use, GTFS may provide a useful basis for defining the transit portion of the AMS database schema.

Challenges

Transit data are inherently complex. A full set of data on transit operations should include information on operator characteristics, route locations, stop locations, schedules, demand (e.g., demand by route and time of day and boardings and alightings by stop), and on-time performance versus schedule. Smaller operators do not collect all these data or may only collect them on a sample basis to fulfill Federal Transit Administration requirements for reporting to the National Transit Database.

Proposed Structure

The proposed structure consists of several tables that define transit routers and data on patronage by route. This structure is based in part on Google^® GTFS.

Table 26 contains information on individual stops (i.e., location, zone, amenities, and routes that serve the stop and boardings and alightings at the stop by route).

Table 26. Sample fields in the stop table.

Table 27 contains information on specific transit routes.

Table 27. Sample fields in the route table.

Table 28 identifies a set of zone-to-zone fares by transit operator. Fare information is used in the regional TDM as part of the demand forecasting process.

Table 28. Sample fields in the zone-to-zone fare table.

HOUSEHOLD TRAVEL SURVEYS

Existing Practice

Household travel surveys provide essential data on travel behavior for developing TDMs. Travel surveys are typically conducted by telephone for a sample of the population. Respondents are asked information about the household, persons in the household, vehicles in the household, and trips made by members of the household on a designated travel day. Some surveys collect data for multiple travel days.

A household travel survey is an expensive undertaking that is typically conducted at intervals of about 10 years by an MPO or a State transportation department. Current survey costs for a large-scale survey average $150–$200 per completed household sample.

The current trend has caused some household travel surveys to be activity-based where information is sought on activity schedules, whether at home or away from home. Trips are treated as special activities.

Challenges

Household travel survey datasets are complex and difficult to analyze. While they can be used to provide information for specific transportation studies, they are seldom used for these purposes because of the particular data analysis skills required to assemble and analyze the data. Household travel surveys data typically contain the following four types of files:

• Household file: Information on the household as a whole (e.g., location, vehicle ownership, income, etc.).
  
  
• Person file: Information on persons in the household (e.g., age, sex, relation to head of household, occupation status, etc.).
  
  
• Vehicle file: Information on vehicles in the household (make, model, year, mileage, owned or leased, etc.).
  
  
• Trip file (or activity file): A file of records on individual trips or activities. Each record contains activity type, begin time, and end time. If the record is for a trip, information includes mode, fare paid, type of parking, and vehicle occupancy.
  
  

Travel survey data typically require a large amount of time and effort for preprocessing. If the survey is activity-based, trip information must be selected from the activity file for use in travel modeling. Trip data are often further preprocessed. For example, if a person walks to transit, rides transit to a transfer point, transfers to another transit vehicle, and then walks to the destination, those are recorded as four separate trips in the trip file, but they must be linked together into a single trip (coded as a "transit, walk access" mode). Other types of trips may be linked to provide more accurate information (e.g., if a person makes a short stop on the way to work to buy coffee, the stop is sometimes linked, and the two trips are treated as a single home-work trip).

Proposed Structure

The proposed structure consists of a set of tables corresponding to the files in a typical household travel survey dataset (see table 29 through table 32). In addition, there would be a processed trip file that contains a set of trips that can be used directly for travel modeling or other travel analysis purposes.

Table 29. Sample fields in the household table.

Table 30. Sample fields in the person table.

Table 31. Sample fields in the vehicle table.

Table 32. Sample fields in the raw trip table.

An example processed trip table (table 33) provides information on trips that have been processed from the raw trip table. Note that the purpose field replaces O-D activity fields (e.g., if the trip record in the raw trip table had an origin activity of "home" and a destination activity of "work," then the trip would be coded as a "home-work" trip in the processed trip table).

Table 33. Sample fields in the processed trip table.

TRAVEL MODEL OUTPUTS

Existing Practice

TDMs produce a number of different types of data that can be used for further analysis. Example outputs include the following:

• Trip tables: Number of trips by O-D pair by mode, trip purpose, and time of period.
  
  
• Skim tables: Travel times between zones by mode and time period. Transit skim tables typically include subfields for in-vehicle time, access time, wait time, and transfer time.
  
  
• Assignment tables: Number of vehicles by type (and transit passengers) on links in the travel network and travel speeds by time period.
  
  

Challenges

Travel models produce a large amount of output data that are typically kept in a format proprietary to the individual software vendor of the travel modeling software. Most travel modeling software packages are capable of exporting data into other formats (e.g., text, database, or spreadsheet). There is currently no standard practice for managing outputs from different travel modeling software packages.

Activity-based models produce outputs of individual trips for each person in a synthetic sample on which the model operates. The individual records contain information on characteristics of the person and the household so that outputs can be summarized by socioeconomic characteristics for purposes of equity analysis. These records can also be summarized into traditional trip tables like those produced by trip-based TDMs.

Proposed Structure

The proposed structure consists of a set of tables corresponding to travel model outputs. For trip-based models, the output will consist of a set of trip tables, zone-to-zone skims, and link assignments. Examples are shown in table 34 through table 36.

Table 34. Sample fields in the trip table.

Table 35. Sample fields in the skim table.

Table 36. Sample fields in the link table.

As noted, activity-based models produce outputs of individual records by person. These can be aggregated by socioeconomic to provide detailed information for purposes of equity analysis, as shown in table 37.

Table 37. Sample fields in the activity-based model table.

MOES

Existing Practice

MOEs are typically compiled for a node, a link, a corridor, a zone, or an entire network. Depending on the analysis level, MOEs can be generic or comprehensive. Some common MOEs include the following:

• MOEs for nodes: V/C ratio, average delay, entering volume, etc.
  
  
• MOEs for links: V/C ratio, density, queue, delay, speed, travel time, number of stops, number of lane changes, vehicle-miles traveled, emissions, fuel consumption, etc.
  
  
• Path/corridor: Travel time, queue, delay, progression, vehicle-miles traveled, number of lane changes, number of stops, etc.
  
  
• Network: Average speed, total vehicle-miles traveled, total vehicle-hours of delay, total vehicle-hours of move time, total fuel consumption, total emissions, etc.
  
  

Challenges

Some challenges with MOEs include the following:

• Some link MOEs can potentially be aggregated to generate path and network MOEs. Space can be saved at the expense of computational speed.
  
  
• Emerging MOEs for reliability, safety, and sustainability have yet to be incorporated into mainstream AMS tools.
  
  

Proposed Structure

The MOEs table is proposed to comprise a number of subset tables, each of which contains MOEs for node, link, path, zone, and network respectively. Table 38 through table 41 show examples of these subsets.

Table 38. Subset table with sample MOE fields for nodes.

Table 39. Subset table with sample MOE fields for links.

Table 40. Subset table with sample MOE fields for path or corridor.

Table 41. Subset table with sample MOE fields for subarea and entire network.

SCENARIOS

Existing Practice

An analysis of scenarios, alternatives, or options is a common requirement in all transportation planning, operations, and improvement projects. A few analysis tools allow the analyst to set up scenarios within the base analysis; however, the majority of analysis tools requires the analyst to make a copy of the base analysis before experimenting with changes in the network, traffic control, or demands. The following examples highlight scenarios typically encountered:

• Modification of timing and phasing to optimize signal operation.
  
  
• Modification of existing traffic control device (e.g., replacing a stop control with a signal or roundabout).
  
  
• Addition of capacity to an existing link and a series of links.
  
  
• Addition of new link(s) to the network.
  
  
• Conversion of one-way to two-way operations or vice versa.
  
  
• Implementation of toll or road pricing on existing link(s).
  
  
• Evaluation of traffic control strategies at work zones.
  
  

Challenges

Modifications of properties of existing nodes or links can more easily be tracked than the addition of new links and nodes. When a new link or node is added, traffic assignment, volumes, traffic control, and zones can all potentially be affected. The problem becomes exponentially challenging when more than one link and node are added. Because links and nodes have different properties, two separate tables will be required to store changes made to both.

Proposed Structure

The purpose of the scenario table is to automatically keep track of modifications made to the base file while keeping the base file intact for comparison purposes. The proposed table has a subset table for scenarios related to links and another subset for scenarios related to nodes. For scenarios involving new links and nodes, the analyst can employ the traditional approach of making copies of the base analysis. (See table 42 and table 43). Typical scenario setup and work flow are envisioned as follows:

• The analyst can set up one or more scenarios. Changes to links will be stored in the scenario link subset table, and changes to nodes will be stored in the scenario node subset table. One scenario can include only the link subset, the node subset, or both.
  
  
• The analyst can run the base analysis by itself or with one of the scenarios activated.
  
  
• Instances of MOE tables will be generated for scenarios analyzed and to enable cross comparison of scenarios.
  
  

Table 42. Subset table with sample scenario fields for links.

Table 43. Subset table with sample scenario fields for nodes.

SIGNAL CONTROL

Existing Practice

Signal operations and settings are traditionally simplified before being entered in an analysis tool. In most analysis tools, the ring and barrier setup is coded as sequential phases. Timing parameters such as minimum initial, splits, etc. are simplified as green, yellow, and all-red, and most controller settings such as red rest, recall mode, gap, etc. are ignored.

Challenges

Signal control challenges include the following:

• The traditional approach to simplify the signal settings for analysis cannot adequately depict advanced features (e.g., complex overlap phasing, priority treatment, dedicated pedestrian, or bicycle phase).
  
  
• Most if not all signal controllers are built modularly. A fully loaded signal cabinet can have many advanced functions and features that a basic controller lacks. Capturing everything in the data structure can be overwhelming.
  
  
• Adaptive signal control is becoming increasingly popular. A variety of adaptive approaches already exist as well as controllers and their detection methods
  and requirements.
  
  
• Several standards for signal controller exist.
  
  

Proposed Structure

It is proposed that the data structure for signal control adopts the National Electrical Manufacturers Association standards and includes all typical settings that directly control the signal head’s display and functions. This is shown in table 44 and table 45.

Table 44. Signal control table with sample fields.

Table 45. Signal phasing table with sample fields.

VEHICLE TRAJECTORIES

Existing Practice

Vehicle trajectories can range from very detailed second-by-second lane-by-lane trajectory generated by microsimulation models to grossly estimated trajectories in macro- or HCM-based tools in order to estimate emissions and fuel consumptions. In microsimulation, trajectories are generated for individual vehicles and used in animation and estimation of the most detailed MOEs if needed.

Challenges

For a large network analyzed over a long period of time, the amount of vehicle trajectory data generated can be unwieldy.

Proposed Structure

Table 46 describes the structure for vehicle trajectory data.

Table 46. Vehicle trajectory table with sample fields.

CONFIGURATION

Existing Practice

Each analysis tool has certain assumptions and default parameters to carry out the analysis. Software may or may not allow the analyst to override these assumptions and defaults. Some of these settings are specific to software, some are specific to a theory employed by the software, and others are specific to a corridor or network being analyzed. Two examples are presented to illustrate challenges.

Example 1: Configurations for CORSIM^TM

Sample configuration parameters required by CORSIM^TM are provided.⁽¹⁰⁾ The listed parameters are for illustrative purposes and are not all-inclusive.

Configuration parameters common to microsimulation include the following:

• Initialization period: Random seeds and vehicle entry headway distributions.
  
  
• Analysis period: Start time, number of intervals, and interval duration.
  
  
• Analysis description: Analyst name, agency, analysis date, unique identification, project/scenario description, and link name.
  
  
• Output trajectory file: For each probe vehicle, a probe file from CORSIM^TM records its entrance and exit time, vehicle ID, path ID, as well as the node number sequence.
  
  

Configuration parameters specific to a car-following lane-changing theory include the following:

• Mean startup delay, mean discharge headway, and queue discharge distribution.
  
  
• Car following sensitivity and driver acceleration/deceleration.
  
  
• Acceptable gap distribution, start-up lost-time distribution, spillback probabilities, lane change behavior, driver familiarity, free flow speed distribution, and left-turn behavior.
  
  

Configuration parameters specific to CORSIM^TM include the following:

• Random seeds for freeway and arterial headways, vehicle types and properties, fuel consumption and emission rates, and pre-timed signal transition algorithm.
  
  
• Distribution of discharge headway, distribution of bus dwell time, distribution of interaction for pedestrian delay, short-term event, and interchange O-D.
  
  
• Format of cumulative reports.
  
  
• User interface including grid, project directory, color, and node numbering.
  
  

Configuration parameters specific to the analysis include the following:

• Analysis period: Start time, number of intervals, and interval duration.
  
  
• Analysis description: Analyst name, agency, analysis date, unique identification, project/scenario description, and background file.
  
  

Example 2: Configurations for DynusT

Sample configuration parameters required by DynusT include the following (the listed parameters are for illustrative purposes and are not all-inclusive):

• Simulation period, number of iterations, number of simulation intervals per aggregation, vehicle generation mode, and convergence threshold.
  
  
• Timing plans, left-turn capacity, two-way stop control capacity, four-way stop control capacity, yield control capacity, traffic flow models, and grade length passenger car equivalent.
  
  
• User interface including grid, color scheme, background file, various output files, software version, and unit (English/metric).
  
  

Challenges

Challenges include the following:

• Different model resolutions are based on different theories which have different configuration requirements.
  
  
• Software tools within the same resolution can be based on different theories.
  
  
• Software tools based on the same theory can have their own interpretation, assumptions, and default values.
  
  

Proposed Structure

As anticipated, configuration parameters vary significantly from one resolution to another and from model to model within one resolution. It is proposed to include the few common parameters among software packages in the configuration table and allow parameters specific to software to be added and stored on an as-needed basis (see table 47).

Table 47. Example configuration table.