Skip to contentUnited States Department of Transportation - Federal Highway Administration FHWA Home
Research Home
REPORT
This report is an archived publication and may contain dated technical, contact, and link information
Publication Number: FHWA-HRT-13-036
Date: August 2013

 

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:

Advantages of the database schema are as follows:

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:

Complex Data Types:

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:

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.

Field

Description

Type

Notes

Zone ID

Zone identification number

Numerical

None

Zone name

Zone name

Alphanumeric

None

Boundary

Geo-coded boundary

Geometric

<coordinate> (x1, y1) (x2, y2) (x3, y3) ...</coordinate>

Super zone

ID of the super zone that the zone belongs

Numerical

None

Jurisdiction

Jurisdictional code and/or name that the zone belongs

Alphanumeric

#-Jurisdiction_name

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.

Field

Description

Value

Notes

Subarea ID

Subarea or path identification number

Numerical

None

Zone ID

Zone identification number

Numerical

None

Zone name

Zone name

Alphanumeric

None

Boundary

Geo-coded boundary

Alphanumeric

<coordinate> (x1, y1) (x2, y2) (x3, y3) ...</coordinate>

Node ID

IDs of all nodes within zone i

Numerical

Nodea, Nodeb, Nodec...

Link ID

IDs of all links within zone i

Numerical

Link_a, Link_b, Link_c, Link_d...

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:

Table 14. Socioeconomic zone table with sample subarea fields.

Field

Description

Data type

Example

Notes

Zone ID

Zone ID

Integer

12345

Link to zone table

Scenario ID

Scenario ID for this zone (e.g., year, land use alternative, etc.)

String

21A

Link to scenario table

Population

Zone population for year and alternative

Double

1,500.00

 None

Households

Number of households

Double

520.00

Many agencies have separate forecasts of households by socioeconomic group (e.g., income quartile, auto ownership, etc.)

Employment

Zone employment for year and alternative

Double

2,300.00

Agencies typically have separate data items for employment by sector (e.g., manufacturing, retail, service, etc.)

Median Income

Median income in zone

Double

40,000.0

None

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:

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:

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:

A normalized table structure for nodes is recommended as follows:

Sample fields in the node tables include the following:

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

Table 15. Sample fields in the base node table.

Field

Description

Data Type

Example

Node

Node number or ID

Integer

1234

Longitude

Longitude

Double

37.77138056

Latitude

Latitude

Double

-122.4386917

Node type

Facility type of node (e.g., freeway, arterial, ramp, rail line, bus line, etc.)

Enumeration

Rail station

Zone

ID of containing TAZ

Integer

221

Table 16. Sample fields in the node geometry table.

Field

Description

Data Type

Example

Scenario

Scenario ID

String

21A

Node

Node number or ID

Integer

1234

Approach direction

Direction of approach traffic (e.g., N would indicate northbound traffic)

Enumeration

N

Lanes—left

Number of left turn lanes

Integer

1

Lanes—left thru

Number of shared through left-turn lanes

Integer

1

Lanes—left thru right

Number of shared left-through-right lanes

Integer

1

Lanes—thru

Number of through lanes

Integer

2

Lanes—thru right

Number of shared through right-turn lanes

Integer

1

Lanes—right

Number of right-turn lanes

Integer

0

Permitted Right Turn on Red

Right turn on red permitted

Boolean

F (false)

Free right

Free right turn permitted

Boolean

T (true)

Table 17. Sample fields in the node volume table.

Field

Description

Data Type

Example

Scenario

Scenario ID

String

21A

Node

Node number or ID

Integer

1234

Approach direction

Direction of approach traffic (e.g., N would indicate northbound traffic)

Enumeration

N

Left turn

Number of left-turn lanes

Double

1

Through

Number of shared through left-turn lanes

Double

1

Right turn

Number of shared left-through-right lanes

Double

1

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:

Challenges

Some challenges when integrating different datasets include the following:

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:

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. Sample fields in the link table.

Field

Description

Data Type

Example

Notes

Link ID

ID of link

Integer

12345

Key to link to other link tables

Name

Name of link (e.g., road name)

String

51st Ave

 None

Link type

Type of link

Enumeration

Freeway, rail, or arterial

 None

A_Node

Node ID at one end of link

Integer

2433

 None

B_Node

Node ID at other end of link

Integer

1876

 None

Hpms_ID

Highway Performance Monitoring System (HPMS) link ID

String

12A456

Include this if the link is part of the HPMS sample

Pavement type

Type of pavement

Enumeration

Asphalt

 None

Area type

Area type of link

Enumeration

Central Business District

 None

Functional class

Functional class of link

Minor collector

25.59

Includes road functional classes and transit links (e.g., rail line)

Grade

Percent grade on node

Double

2.20

 None

Super elevation

Super elevation for curved links

Double

2.00

 None

Path

X, Y coordinates that define path of link

Geometry

 None

Could alternately be defined as an XML field if DBMS does not support geometry data type

Length

Link length

Double

0.35

None

Table 19. Sample fields in the link geometry table.

Field

Description

Data Type

Example

Notes

Link ID

ID of link

Integer

12345

Link to link table

A_Node

Begin node of link

Integer

34554

Taken together, node A and
node B indicate flow direction

B_Node

End node of link

Integer

56672

None

Scenario ID

Scenario ID for link geometry

String

21A

Link to scenario table

Lanes

Number of lanes

Integer

2

None

Capacity

Capacity in vehicles per hour

Integer

1400

None

Speed_FF

Free-flow speed

Double

25.0

None

Speed post

Posted speed

Double

25.0

None

Volume

Link volume

Double

186.02

None

Speed

Link speed output from TDM

Double

16.30

None

Table 20. Sample fields in the link volume table.

Field

Description

Data type

Example

Notes

Link ID

ID of link

Integer

12345

Link to link table

A_Node

Begin node of link

Integer

34554

Taken together, node A and
node B indicate flow direction

B_Node

End node of link

Integer

56672

None

Scenario ID

Scenario ID for this link geometry

String

21A

Link to scenario table

Lanes

Number of lanes

Integer

2

None

Capacity

Capacity in vehicles per hour

Integer

1400

None

Speed_FF

Free-flow speed

Double

25.0

None

Speed Post

Posted speed

Double

25.0

None

Volume

Link volume

Double

186.02

None

Speed

Link speed output from TDM

Double

16.30

None

V to C

V/C ratio

Double

0.95

None

Density

Traffic density on link (vehicles/mi)

Double

30.22

None

DEMANDS

Existing Practice

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

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:

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. Demand for activity-based TDMs.

Field

Description

Data Type

Example

Notes

Household ID

Household ID number from synthetic sample

Integer

1001

None

Person ID

Person ID number from synthetic sample

Integer

3

None

Weight

Weighting factor for this person

Integer

2

None

Trip No

Trip number

Integer

2

None

HH_Income

Household income of person in synthetic sample

Double

60,000.00

These are examples of household
and person characteristics; other characteristics (e.g., ethnicity) could also be included

Person age

Age of person in synthetic sample

Integer

44

None

Person sex

Sex of person

Enumeration

Male

None

Activity origin

Activity at origin

Enumeration

Home

None

Activity destination

Activity at destination

Enumeration

Work

None

TAZ_Origin

Origin TAZ

Integer

2433

None

TAZ_Destination

Destination TAZ

Integer

1876

None

Time begin

Begin time of trip

Date and time

15:05

None

Time end

End time of trip

Date and time

15:40

None

Mode

Travel mode

Enumeration

Bus

None

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

Field

Description

Data Type

Example

Notes

Scenario ID

ID of particular scenario

String

21A

Link to scenario table

Time period

Time period in which trip takes place

Enumeration

Morning

Definitions will depend on agency definitions of time periods

Trip purpose

Trip purpose category

Enumeration

Home to work

Definitions will depend on agency definitions of trip purposes

Mode

Travel mode

Enumeration

Auto driver

Definitions will depend on agency definitions of modes

TAZ_Origin

Origin TAZ

Integer

2433

None

TAZ_Destination

Destination TAZ

Integer

1876

None

Trips

Number of trips

Double

23.59

None

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

Field

Description

Data Type

Example

Notes

Scenario ID

ID of particular scenario

String

21A

Link to scenario table

Time period

Time period in which trip takes place

Enumeration

Morning

Definitions will depend on agency definitions of time periods

Trip purpose

Trip purpose category

Enumeration

Home to work

Definitions will depend on agency definitions of trip purposes

Mode

Travel mode

Enumeration

Auto driver

Definitions will depend on agency definitions of modes

TAZ_Production

Production TAZ

Integer

2433

None

TAZ_Attraction

Attraction TAZ

Integer

1876

None

Trips

Number of trips

Double

23.59

None

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

Field

Description

Data Type

Example

Notes

Scenario ID

ID of particular scenario

String

21A

Link to scenario table

Time

Time for trips in appropriate time resolution
(e.g., 15 min)

Enumeration

Morning

Time resolution will depend on application

Vehicle type

Type of vehicle

Enumeration

Auto, HOV, light truck, etc.

Definitions will depend on agency definitions of vehicle types

TAZ_Origin

Origin TAZ

Integer

2433

None

TAZ_Destination

Destination TAZ

Integer

1876

None

Trips

Number of trips

Double

23.59

None

Table 25. Traffic count.

Field

Description

Data Type

Example

Notes

Link ID

ID of link

Integer

12345

Link to link table

A_Node

Begin node of link

Integer

34554

Taken together,
node A and node B indicate flow direction

B_Node

End node of link

Integer

56672

None

Scenario ID

Scenario ID for this link geometry

String

21A

Link to scenario table

Vehicle type

Type of vehicle counted

Enumeration

Auto, truck
(by class), motorcycle, etc.

Not all agencies will have classification counts by vehicle type

Time

Time of observation

Date and time

2

None

Volume

Travel volume

 Integer

1000

None

Speed

Free-flow speed

Double

25.0

None

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.

Field

Description

Value

Stop ID

ID number of stop

Integer

Stop description

Description of stop

Alphanumeric

Stop location

Stop location (latitude, longitude)

Point

Stop TAZ

TAZ of stop

Integer

Stop type

Indicates whether bus stop or transit station

Enumeration

Has bench

Indicates whether stop has bench

Boolean

Has shelter

Indicates whether stop has a shelter

Boolean

Boardings

Average boardings at stop

Numeric

Alightings

Average alightings at stop

Numeric

Table 27 contains information on specific transit routes.

Table 27. Sample fields in the route table.

Field

Description

Value

Operator

Name of transit operator

Alphanumeric

Route ID

ID number of route (operator-specified)

Alphanumeric

Route description

Description of route

Alphanumeric

Mode

Type of transit (e.g., commuter rail, heavy rail, light rail, rapid bus, express bus, local bus, etc.)

Enumeration

Average headway

Average headway in minutes by time period (e.g., morning peak, midday, afternoon peak, or evening)

Numeric

Stop sequence

Sequence of stop IDs that define the route

Vector of stop IDs

Hours operation

Hours of operation

Numeric

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.

Field

Description

Value

Operator

Transit operator name

Alphanumeric

Route ID

Individual route ID

Alphanumeric

Origin zone

Origin TAZ

Numeric

Destination zone

Destination TAZ

Numeric

Time of day

Time period (e.g., morning peak, midday, and afternoon peak)

Enumeration

Normal fare

Amount of fare

Numeric

Discount fare 1

Discounted fare for category 1 (e.g., handicapped)

Numeric

Discount fare 2

Discounted fare for category 2 (e.g., youth)

Numeric

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:

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.

Field

Description

Value

Household ID

ID of household (used to link to person and trip files)

Numeric

Location

Household latitude and longitude

Point code

N_Persons

Number of persons in the household

Numeric

N_Veh

Number of vehicles in the household

Numeric

Income

Household income

Numeric

Zone

Zone where household is located

Numeric

Table 30. Sample fields in the person table.

Field

Description

Value

Household ID

ID of household

Numeric

Person ID

ID number of person

Numeric

Relation

Relation to head of household

Enumeration

Age

Age

Numeric

Sex

Sex

Enumeration

Occupation status

Occupation status of person (working, student, retired, homemaker)

Enumeration

Work loc

Zone where workplace is located

Numeric

Handicapped

Whether person has a handicap that limits ability to use transit

Boolean

Table 31. Sample fields in the vehicle table.

Field

Description

Value

Household ID

ID of household

Numeric

Make

Make of vehicle

Alphanumeric

Model

Vehicle model

Alphanumeric

Body type

Vehicle body type

Enumeration

Year

Model year of vehicle

Numeric

Mileage

Miles on vehicle at time of survey

Numeric

Owned

Is vehicle owned, leased, or provided by company

Enumeration

Fuel

Fuel type of vehicle (e.g., gas, diesel, or hybrid)

Enumeration

Table 32. Sample fields in the raw trip table.

Field

Description

Value

Household ID

ID of household

Numeric

Person ID

ID of person

Numeric

Trip no

Trip sequence number

Numeric

Orig act

Activity at origin

Enumeration

Dest act

Activity at destination

Enumeration

Orig zone

Origin zone

Numeric

Dest zone

Destination zone

Numeric

Date

Date of travel

Date

Time begin

Begin time of trip

Time

Time end

End time of trip

Time

Mode

Travel mode

Enumeration

Park type

Type of parking (street, lot, structure, etc.)

Enumeration

Park cost

Parking cost

Numeric

Park cost basis

Parking cost basis (monthly, hourly, etc.)

Enumeration

Fare

Transit fare

Numeric

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.

Field

Description

Value

Household ID

ID of household

Numeric

Person ID

ID of person

Numeric

Trip no

Trip sequence number

Numeric

Purpose

Trip purpose

Enumeration

Orig zone

Origin zone

Numeric

Dest zone

Destination zone

Numeric

Date

Date of travel

Date

Time begin

Begin time of trip

Time

Time end

End time of trip

Time

Mode

Travel mode (composite mode that covers both main mode and type of access)

Enumeration

Park type

Type of parking (street, lot, structure, etc.)

Enumeration

Park cost

Parking cost

Numeric

Park cost basis

Parking cost basis (monthly, hourly, etc.)

Enumeration

Fare

Transit fare

Numeric

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:

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.

Field

Description

Value

Purpose

Trip purpose

Enumeration

Mode

Travel mode

Enumeration

Time period

Time period (e.g., morning peak, midday, etc.)

Enumeration

Orig zone

Origin zone

Numeric

Dest zone

Destination zone

Numeric

Trips

Number of trips

Numeric

Table 35. Sample fields in the skim table.

Field

Description

Value

Time period

Time period

Enumeration

Mode

Travel mode (e.g., SOV, HOV, transit, etc.)

Enumeration

Orig zone

Origin zone

Numeric

Dest zone

Destination zone

Numeric

Trave time

Travel time in minutes

Numeric

Acc time

Access time (for transit)

Numeric

Wait time

Wait time for transit

Numeric

Xfr time

Transfer time for transit

Numeric

N_Xfr

Number of transfers for transit

Numeric

Table 36. Sample fields in the link table.

Field

Description

Value

Link ID

Link ID (to link with Link table)

Numeric

Time period

Time period

Enumeration

Speed

Speed

Numeric

Vol SOV

SOV volume

Numeric

Vol HOV

HOV volume

Numeric

Vol truck

Truck volume

Numeric

Transit vol

Transit passengers

Numeric

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.

Field

Description

Value

Person ID

Synthetic sample number

Numeric

Age

Age of person

Numeric

Sex

Sex of person

Enumeration

Income

Household income category

Enumeration

Weight

Expansion factor for person trip record

Numeric

Orig zone

Origin zone

Numeric

Dest zone

Destination zone

Numeric

Act orig

Activity at origin

Enumeration

Act dest

Activity at destination

Enumeration

Time begin

Begin time of trip

Time

Time end

End time of trip

Time

Mode

Travel mode

Enumeration

Fare

Transit fare paid

Numeric

Park cost

Parking cost

Numeric

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:

Challenges

Some challenges with MOEs include the following:

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.

Field

Description

Value

Notes

Node ID

Node number or ID

Integer

None

Intervals

Number of analysis intervals with analysis period

Integer

None

vc

V/C ratio averaged for analysis period and each time interval

Numerical

Avg_vc, vc_t1, vc_t2...

Delay

Average delay for analysis period and each time interval

Numerical

Avg_d, d_t1, d_t2...

Enter_vol

Total entering volume (vehicles per hour)

Numerical

Total_vol, v_t1, v_t2...

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

Field

Description

Value

Notes

Link ID

Link ID

Integer

None

Intervals

Number of analysis intervals with analysis period

Integer

None

vc

V/C ratio averaged for analysis period and each time interval

Numerical

Avg_vc, vc_t1, vc_t2...

Delay

Average total delay for analysis period and each time interval

Numerical

Avg_d, d_t1, d_t2…

Delay_mvt

Average movement delay for analysis period

Numerical

d_LT, d_TH, d_RT, d_Turn1, d_Turn2

Delay_lane

Average lane delay for analysis period

Numerical

d_Lane1, d_Lane2, d_Lane3…

Delay_control

Average control delay for analysis period and each time interval

Numerical

Avg_control, control_t1, control_t2…

Delay_stop

Average stop delay for analysis period and each time interval

Numerical

Avg_stop, stop_t1, stop_t2…

Density

Link density (veh/m)

Numerical

Avg_density, den_t1, den_t2…

Queue

Average number of queued vehicles

Numerical

Avg_q, q_t1, q_t2, q_t3...

Lane Change

Number of lane changes for analysis period and each time interval

Numerical

Lchange, Lchange_t1, Lchange_t2, Lchange_t3...

Emissions

Total emissions by vehicle type for analysis period

Numerical

E_veh1, E_veh2, E_veh3…

Fuel

Total fuel consumption by vehicle type for analysis period

Numerical

F_veh1, F_veh2, F_veh3…

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

Field

Description

Value

Notes

Path ID

Path ID as defined in Zones table

Integer

None

Intervals

Number of analysis intervals with analysis period

Integer

None

Delay

Average total delay for analysis period and each time interval

Numerical

Avg_d, d_t1, d_t2…

TT

Average path travel time for analysis period and each time interval

Numerical

Avg_TT, TT_t1, TT_t2...

Lane change

Number of lane changes for analysis period and each time interval

Numerical

Lchange, Lchange_t1, Lchange_t2, Lchange_t3...

Stop

Number of stops for analysis period and each time interval

Numerical

Stops, stop_t1, stop _t2, stop_t3…

Stop_time

Average stop time per vehicle

Numerical

StopTime, stoptime_t1, stoptime _t2, stoptime_t3…

Veh-miles

Total vehicle-miles travelled

Numerical

None

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

Field

Description

Value

Notes

Zone ID

Path ID as defined in Zones table

Integer

"All" for all zones

Delay

Total vehicle-hours of delay for analysis period and each time interval

Numerical

d, d_t1, d_t2…

Del_Mile

Average vehicle delay per mile

Numerical

d-mile, d-mile_t1, d-mile_t2, d-mile_t3…

Move

Total vehicle-hours of move time for analysis period and each time interval

Numerical

Move, Move_t1, Move_t2…

Speed

Average vehicle speed in zone

Numerical

Speed, Speed_t1, Speed _t2, Speed _t3…

Emissions

Total emissions by vehicle type for analysis period

Numerical

E_veh1, E_veh2, E_veh3…

Fuel

Total fuel consumption by vehicle type for analysis period

Numerical

F_veh1, F_veh2, F_veh3…

Veh-miles

Total vehicle-miles traveled

Numerical

None

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:

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:

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

Field

Description

Value

Notes

Scenario ID

Scenario ID

Alphanumeric

None

Scenario_Type

Scenario types

Alphanumeric

Pricing/Work_Zone/Incident/VMS

Indifference

Indifference band (DTA)

Numerical

None

Threshold

Threshold bound (DTA)

Numerical

None

Pre-trip

Pre-trip assignment (DTA)

Alphanumeric

Random/best

Link ID

Link number or ID

Integer

None

Effective_t

Effective time (start and end)

Alphanumeric

Start_time, End_time

Toll_dist

Distance-based toll ($/lane-mile)

Alphanumeric

$_LOV, $_HOV, $_Truck

Toll_link

Link-based toll ($/link)

Alphanumeric

$_LOV, $_HOV, $_Truck

WZ

Characteristics of work zone

Alphanumeric

Lane_closed, speed_limit, discharge, length

Incident

Characteristics of incident

Alphanumeric

Lane_closed, length

VMS

Variable message sign

Alphanumeric

Speed/Detour/Congestion/…

Meter

Ramp metering

Alphanumeric

Stop_bar, method, max_rate, min_rate, lanes

Parking

On-street parking

Alphanumeric

Location, length, duration, and frequency

VMS = Variable message sign.
LOV = Low-occupancy vehicle.

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

Field

Description

Value

Notes

Scenario ID

Scenario ID

Alphanumeric

None

Scenario_Type

Scenario types

Alphanumeric

Signal/stop-control/
closed

Indifference

Indifference band (DTA)

Numerical

None

Threshold

Threshold bound (DTA)

Numerical

None

Pre-trip

Pre-trip assignment (DTA)

Alphanumeric

Random/best

Node ID

Node number or ID

Integer

 None

Effective_t

Effective time (start and end)

Alphanumeric

Start_time, End_time

Signal

Phasing and timing parameters

Alphanumeric

None

Stop

Stop control

Alphanumeric

Stop_Approach1 (Y/N), Stop_Approach2 (Y/N)…

Roundabout

Roundabout control

Alphanumeric

None

Closure

Intersection closed, detour required

Alphanumeric

None

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:

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.

Field

Description

Data type

Example

Notes

Scenario ID

Scenario ID for this zone (e.g., year, land use alternative)

String

21A

Link to scenario table

Node ID

ID of nodes with signal control

Integer

12345

Link to Node table

Control type

Signal controller mode (e.g., pre-timed, actuated, coordinated, or adaptive)

Integer

1

1: pre-timed;
2: actuated;
3: coordinated;
4: adaptive

Offset

Signal offset for signals in coordination

Double

15.0

None

Yield

Reference point for yield

Double

30.0

None

Reference

Reference phase for coordination

Integer

2

None

Table 45. Signal phasing table with sample fields.

Field

Description

Data Type

Example

Notes

Node ID

ID of nodes with signal control

Integer

12345

Link to signal table

Interval ID

Time interval where entries below are applicable

Integer

1

Interval duration is defined in another table

Phase ID

Phase 1 through 8 in the dual ring barrier control structure

Integer

2

None

Link ID

Subject approach of movements in Phase ID

Integer

2

Link to link table

Movement

Phase movements (left, through, right, diagonal 1, or diagonal 2)

String

L1

L, T, R, 1, or 2

Min Green

Minimum green time for phase ID

Double

15.0

None

Max Green

Maximum green time for phase ID

Double

30.0

None

Veh Ext

Vehicle extension

Double

3.0

None

Time before reduce

Duration before gap reduction

Double

7.0

None

Time to reduce

Reduction amount

Double

15.0

None

Min gap

Minimum gap

Double

3.0

None

Yellow

Yellow or amber interval

Double

4.0

None

All red

All-red interval

Double

2.0

None

Recall

Recall mode

Integer

1

0: No; 1: Yes

Walk

Pedestrian "Walk" phase

Double

10.0

None

Don’t walk

Pedestrian "Don't Walk" phase

Double

15.0

None

Ped calls

Pedestrian activation

Integer

1

0: No; 1: Yes

Dual entry

Dual entry indicator

Integer

1

0: No; 1: Yes

Inhibit max

 Allows controller to "gap out" but not "max out"

Double

 45

 None

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.

Field

Description

Value

Notes

Veh ID

Vehicle ID

Integer

None

Path

Series of links that the vehicle traverse

Integer

Link_a, Link_b, Link_c, Link_d...

Veh type

Vehicle type

Alphanumeric

Car/HOV/Truck/Bus/BRT/…

Speed

Average vehicle speed per link

Numerical

Speed_a, Speed _b, Speed _c...

T time

Average vehicle travel time per link

Numerical

TT_a, TT_b, TT_c, TT_d...

Accel

Average link-based vehicle acceleration

Numerical

Acc_a, Acc _b, Acc _c, Acc _d...

Decel

Average link-based vehicle acceleration

Numerical

Dec_a, Dec_b, Dec_c, Dec_d...

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 CORSIMTM

Sample configuration parameters required by CORSIMTM are provided.(10) The listed parameters are for illustrative purposes and are not all-inclusive.

Configuration parameters common to microsimulation include the following:

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

Configuration parameters specific to CORSIMTM include the following:

Configuration parameters specific to the analysis include the following:

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):

Challenges

Challenges include the following:

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.

Field

Description

Value

Notes

Analyst

Name of analyst

Alphanumeric

None

Description

Analysis or project description

Alphanumeric

None

Background

Aerial or computer-aided design file as background

Filename

None

Unit

English or metric units

None

None

History

Log of analyses conducted

Alphanumeric

<date>date1, date2...</date>, <time>time1, time2...</time>, <software>name1, name2...</software>

TDM

General parameters

None

None

DTA_sim

General parameters

Alphanumeric

<starttime>hh:mm:ss</starttime>, <duration>min</duration>, <initial>min</initial>, <converge>#</converge>

Micro_sim

General parameters

Alphanumeric

<starttime>hh:mm:ss</starttime>, <period>#</period>, <duration>seconds</duration>, <initial>min</initial>

Micro_multi

Parameters related to multiple runs

Alphanumeric

<runs>R</runs>, <seed>seed1, seed2..., seedR</seed>

DynusT_2Way

Two-Way Stop-Control capacity

Numerical

<Major0>LT, TH, RT</Major0>, <Major100>LT, TH, RT</Major100>...

DynusT_LT

Left-turn capacity

Numerical

<gc0.3><Opp1>N1, N2, N3, N4, N5, N6, N7</Opp1>,<Opp2>N1, N2, N3, N4, N5, N6, N7</Opp2>, <Opp3>N1, N2, N3, N4, N5, N6, N7</Opp3></gc0.3>, <gc0.4>#</gc0.4>...

CORSIM_network

Network properties

Numerical

<seed>hdwy, response, netsim</seed>, <hdwy_dist>#</hdwy_dist>,

CORSIM_veh

Vehicle type characteristics in CORSIMTM

Numerical

<veh1>perf, length, occ, hdwy, jerk, decel1, decel2, s_car, s_HV, s_transit, s_hov, f_car, f_HV, f_transit, f_hov, </veh1>, <veh2>…</veh2>...

Vissim_veh

Vehicle type characteristics in PTV Vissim®

Numerical

<car>width, occ, color, max_accel, des_accel, max_del, des_del</car>, <hov>…</hov>,

Vissim_behavior

Driving behavior parameters in PTV Vissim®

Numerical

<urban>min_ahead, max_ahead, Obs_veh, min_back, max_back, inattention, inattention_prob, <model>standstill, safety, multi_safety</model>, <lanechange>…</lanechange>... </car>, <fwy>…</fwy>, <footpath>…</footpath>

 

ResearchFHWA
FHWA
United States Department of Transportation - Federal Highway Administration