TREDIS is organized with a structured hierarchy:

1. PROJECT -- First, the user defines a project in terms of the location where improvements (or other changes) are proposed and period of years for the changes to take place. Users may define as many different projects as desired for analysis.

2. SCENARIOS – For each project, the user then sets up scenarios that describe the project cost and resulting travel conditions (trips, speeds, etc.) expected in a future year. Users may define as many scenarios as desired, but at least two are necessary for impact analysis.

3. COMPARISON CASE – After setting up scenarios, the user defines a comparison case by designating one scenario as the “Base Case” and another as the “Alternative Case.” Users may define multiple cases, by selecting different combinations of scenarios to be compared.

4. REPORTS – The system reports are provided for each comparison case, and they include (1) “audit reports” to confirm that scenario input values are appropriate, (2) “intermediate calculation” reports direct travel costs and market access changes, (3) “total impact” reports for each case, broken down by industries, regions, modes and benefit/cost measures, and (4) supplementary data on study area factors affecting the results. This sequence of steps helps users to assess the validity and reasonableness of results.

This hierarchy provides several advantages:

The system allows for multiple study regions, if desired to assess the spatial distribution of impacts and benefits. The system also allows for multiple time periods, if desired to distinguish daily or seasonal peak congestion from off-peak conditions. However, the number of study areas and time periods are designated at the project step, allowing the system to enforce consistency in area and period data among all scenarios for that project.

The system allows for induced trips, shifting trips among modes, shifting among time periods and even shifting trips among origins and destinations. However, it checks for differences between scenarios in the number of trips by mode and purpose, and enforces consistency at the comparison case step by requiring users to designate the reason for all changes in those measures. This allows the system to account for the correct benefit value of any induced shifts.