Compass Version 1.0 DRCOG Travel Model User`s Guide

Compass Version 1.0 DRCOG Travel Model User`s Guide
Compass Version 1.0
DRCOG Travel Model User’s Guide
Denver Regional Council of Governments
Last Modified: 2-23-2004
Software and Hardware Requirements
Compass 1.0 was designed for TransCAD Version 4.5, build 181. We recommend
running it on that specific version of TransCAD, as older or newer versions may affect
the model results. Specifically, TransCAD 4.7 includes revisions to the transit Pathfinder
algorithm. Those revisions improve processing time, and fix a known problem with the
DRCOG drive-to-transit skimming procedure, but also significantly changes the model
calibration. Therefore, DRCOG is in the process of developing Compass 1.1, which will
be calibrated to work with TransCAD 4.7 and include other improvements as warranted.
Compass 1.1 is expected to be released in mid-2004.
The only specific hardware requirements for Compass 1.0 are those necessary to run
TransCAD. The full model uses about 6 GB of hard disk space. In addition, we
recommend that you have several additional GB of free hard disk space as both the model
and TransCAD create temporary files for several procedures.
The model was designed on a machine with a 1.8 GHz processor, 512 MB of RAM, and
an 80 GB hard disk. On this machine, one iteration takes about 10-12 hours of
processing time. In general, the limiting factor is the number of TAZs. With 2664 zones,
a single matrix contains about 7 million elements, which consumes about 28 MB of space
if stored as 4 byte floating numbers. These matrices quickly add up, especially when we
often deal with 10-20 at a time for various skims and trip tables. For some procedures
(setting distance-based fares, and converting drive-access trip matrices to PNR-toAttraction format) memory errors were encountered when trying to process the entire
matrices at once, forcing us to process these steps one row at a time. It may be possible
to encounter memory errors in other locations if the model is run on a machine with
significantly less memory. Likewise, if we move to machines with more memory, it may
be possible to re-optimize the code to process these steps all at once, significantly
improving execution time.
Installing the Model
After installing TransCAD, take the following steps to install Compass:
1. Copy the graphics files from the \bmp\ directory into:
C:\Program Files\TransCAD\bmp\
These files are icons used in the model dialog box. The model will run without
them, but they improve the appearance of the dialog box.
2. Open TransCAD, and select: ToolsàAdd-Ins Select “GIS Developers Kit” and
click OK.
Page 1
3. A dialog box will appear with five icons. The middle icon is “Compile to UI
Database”. Select this middle icon.
4. From the files included on the CD, select the source code file:
DRCOG_xxxxxxxx.rsc
5. Select the file to store the compiled program. The file to compile to is:
C:\Program Files\TransCAD\drcog_ui.dbd
If the file does not exist, create it.
6. In TransCAD, select: ToolsàAdd-Ins. Click “Setup”. Click Add. Fill in the
blanks as follows:
Type:
Description:
Name:
UI Database:
Dialog Box
DRCOG Model
DRCOG Model
C:\Program Files\TransCAD\drcog_ui.dbd
Click “OK”, and the model is installed.
Once the model is installed, you can open the model dialog box by going to ToolsàAddIns and selecting “DRCOG Model”. Remember that any changes to the source code will
not be reflected in model execution unless you repeat these steps to re-compile.
Working with Scenarios
We recommend copying the model files to a subdirectory of C:\drcog\. We recommend a
different sub-directory for each scenario you run. It is not necessary that you run these
models from a sub-directory of C:\drcog\, but it is important that the directory exist.
When the model is run, a file is created called scenario.arr, and the default directory for
this directory is C:\drcog\.
Having copied all of the model files from the CD to an appropriate directory, the next
step is to add a scenario telling the model where to find those files.
1. Open the model by going to ToolsàAdd-Ins, and selecting “DRCOG Model”.
2. Click on the “Scenario” button.
3. If the scenario has already been added, select the appropriate scenario, and click
“OK”. Skip these remaining steps, and run the model.
4. Give the scenario an appropriate name.
Page 2
5. Click the “Dir” tab, and select the appropriate directory.
6. File names can be changed by selecting a step (Initialization, Trip Generation,
etc.) and clicking on “Contents”. Doing this will open a dialog box showing the
files used in that step. You can switch between input and output files using the
radio buttons below the file list. You can change a file by selecting that file, and
clicking “File”. This will open a standard windows file selection dialog box, and
you can change the file used. The “Status” field indicates if the file exists, is
missing, or is in-use. Missing or in-use input files could cause problems. Also,
both scalar and list parameters are shown at the bottom. These can be changed in
the window that displays their value.
7. When you are done adjusting any file names or parameters, click “OK” to exit the
scenario dialog box, and you will be returned to the main model dialog box. You
will notice that the name of the scenario selected will appear in the Scenarios
Window.
Most of the model files and parameters are standard, and their names do not change from
one scenario two another. There are some exceptions to this rule, and it is important to
change these file names in the scenario manager if they are not set by default. The files
and parameters you need to pay close attention to include:
Highway and Transit Network Files:
Found at: Initialization à Input Files
1.
peak hour base database
2.
off-peak hour base database
3.
peak hour transit route system
4.
off-peak hour transit route system
5.
peak hour highway network
6.
off-peak hour highway network
7.
peak hour transit network
8.
off-peak hour transit network
24.
combined peak & off-peak highway geographic file
25.
combined peak & off-peak transit route system
Socioeconomic Zonal Data Set
Found at: Trip Generation à Input Files
1.
zone attribute table
Model Year
Found at: Trip Generation à Parameters
1.
Modeling forecast year (4 digits)
In running the model, there are four key model inputs that will actually be changed.
These include:
Page 3
•
•
•
•
combined peak & off-peak highway geographic file
combined peak & off-peak transit route system
zone attribute table
Modeling forecast year
Combined Peak & Off-Peak Highway Geographic File
This combined set of files is what actually gets edited when coding highway networks. It
contains only the basic link and node attributes provided by the user, and any auxiliary
attributes such as traffic counts that are not used in the modeling process.
When running the model, the “General Preprocess” step of “Initialization” copies this
geographic file into separate peak and off-peak highway geographic files. All of the data
in this combined file are copied. The “Peak DB Preprocess” and “Off-Peak DB
Preprocess” steps process these files to add link attribute fields that include peak and offpeak travel times, capacities, free-flow speeds, and other items necessary for running the
remainder of the model. These steps also compile the geographic files into peak and offpeak TransCAD network (.net) files. The .net files are not directly viewable by the user,
but are used by the shortest path and highway assignment algorithms. Having this
compiled .net file stripped of extraneous information greatly improves the processing
time associated with these steps.
Three important points should be taken away from this discussion:
•
•
•
The combined highway geographic file should be edited when coding highway
networks.
The peak and off-peak highway geographic files will be overwritten when the
“General Preprocess” step of “Initialization” is run.
Changes made to the highway geographic file will not be reflected in the shortest
path or highway assignment calculations unless “Peak DB Preprocess” and “OffPeak DB Preprocess” are run to compile to the .net files.
Combined Peak & Off-Peak Transit Route System
Like the combined highway file, the combined transit route system is the file that actually
gets edited when coding transit networks. The “General Preprocess” selects the routes
from the combined file that operate in the peak and saves them to the peak route system,
and selects the routes that operate in the off-peak and saves them in the off peak route
system. The “Peak DB Preprocess” and “Off-Peak DB Preprocess” steps compile these
route systems into transit network (.tnw) files. These transit networks are used for
calculating transit shortest paths and performing transit assignment.
With respect to transit route systems, remember:
Page 4
•
•
•
The combined transit route system should be edited when coding transit networks.
The peak and off-peak transit route systems will be overwritten when the
“General Preprocess” step of “Initialization” is run.
Changes made to the transit route system file will not be reflected in the shortest
path or transit assignment calculations unless “Peak DB Preprocess” and “OffPeak DB Preprocess” are run to compile to the .tnw files.
Zone Attribute Table
The zone attribute table contains the socioeconomic data by TAZ. In any cases where
different development scenarios are evaluated, the population, households, and
employment in this file should be changed. Socioeconomic data sets will generally be
provided by DRCOG for a specific year and development scenario. They should only be
changed when evaluating specific development alternatives.
The following 12 fields are inputs in the zonal attribute table, and need to be complete.
The remaining fields in the table are generated within the model. The first five fields
below are standard, and will not be changed between different scenarios.
ZONE ID:
DISTRICT:
DIATime:
TAZ_ID:
TAZ ID
district names used in k-factors.
pseudo travel time used for distribution trips to DIA.
TAZ_ID by RSA_ID (The 5 digit-ID used in economic
modeling).
ACREAGE:
zonal acreage (units of acres).
HH POP:
total household population, not including population
in group quarters.
LOW INC. HH:
number of households low-income (bottom 11%)
MED. INC. HH:
number of households medium-income (middle 64%)
HIGH INC. HH:
number of households high-income (top 25%)
PROD./DIST. EMP: total employment in production and distribution
RETAIL EMP:
total employment in retail.
SERVICE EMP:
total employment in service.
Modeling Forecast Year
The modeling forecast year is the year for which the model run is performed. The model
uses this in two ways:
•
External station volumes are factored up from a base year by applying a growth
factor for the appropriate number of years. These volumes are used to estimate
external-external and internal-external trips.
Page 5
•
The model forecast year is used with a lookup table to determine the number of
enplanements at DIA, which is used to forecast the traffic at DIA.
Model Stages and Steps
The model contains seven stages with a total of 27 steps that can be run individually, or
together. The stages and steps are summarized as follows:
Initialization
Area Type Model
Calculates the population and employment density within ½ mile of each zone
centroid, and uses that to determine the area type (CBD, Fringe, Urban, Suburban,
Rural). Fills that area type into the zonal data file.
Parking Cost Model
Based on the demand of vehicle trips to the CBD, determines the parking cost by
TAZ, and fills it into the zonal data file. Also determines parking cost for select
non-CBD TAZs.
General Preprocess
Splits combined networks into separate peak and off-peak. Calculates additional
fields in zonal data file.
Transit Access/Egress
Determines fraction of each TAZ within 1/3 mile of transit, and fills those values
into zonal data file.
Peak DB Preprocess
Creates additional fields in peak highway geographic file, processes peak transit
route system, and compiles them into .net and .tnw files.
Off-Peak DB Preprocess
Creates additional fields in off-peak highway geographic file, processes off-peak
transit route system, and compiles them into .net and .tnw files.
Page 6
Trip Generation
Calculate HH
Calculates the households in each TAZ by income group and household size.
Calculate PA
Performs trip generation, and balances attractions to productions.
DB Processing
Peak Highway Skimming
Computes peak (6:30-9:00 AM) highway skim, as well as HOV skim, and HOV
time savings.
Off-Peak Highway Skimming
Computes off-peak (9:00 AM – 3:00 PM) highway skim. HOV is not an option in
the off-peak.
Peak Transit Skimming
Computes peak walk-access and drive-access transit skims. Post-processes those
skims to determine distance-based fare, rail flags, and valid paths.
Off-Peak Transit Skimming
Computes off-peak walk-access and drive-access transit skims. Post-processes
those skims to determine distance-based fare, rail flags, and valid paths.
Trip Distribution
HBW Distribution
Trip distribution for home-based work trips, segmented into low-income, middleincome, and high-income, using a gravity model.
HNW Distribution
Trip distribution for home-based non-work trips, non-home-based trips, and
internal-external trips, using a gravity model.
Page 7
COM Distribution
Trip distribution for commercial vehicle trips, and for external-external trips.
Mode Split
Set Market Segments
Creates a matrix with flags indicating which cells are attracted by the CBD,
attracted by DIA, attracted by Boulder (excluding Boulder productions), and none
of the above.
HBW Modal Split
Mode choice for home-based work trips into Drive Alone, Shared Ride 2, Shared
Ride 3+, Walk to Transit, and Drive to Transit. Segmented by low, medium, and
high income.
HBNW Modal Split
Mode choice for home-based non-work trips into Auto, Walk to Transit, and
Drive to Transit. The auto trips are post-processed into Drive-Alone, Shared Ride
2, and Shared Ride 3+ based on the average household size of the production
zone.
NHB Modal Split
Mode choice for non-home-based trips into Auto and Walk to Transit. The auto
trips are post-processed into Drive-Alone, Shared Ride 2, and Shared Ride 3+
based on the average household size of the production zone.
Trip Assignment
Transit Assignment
First, for drive to transit trips, separates out the portion driving to the PNR lot
from the portion actually using transit from the PNR lot to the destination. Then
assigns the walk to transit trips, and the transit portion (from PNR to destination)
of the drive to transit trips. Does this for both the peak and the off peak.
Highway Time of Day
Page 8
Takes the mode choice matrices by trip purpose as input, converts from P-A to OD format, and uses factors to split into AM (6:30-9:00 AM), PM (3:00 – 7:00
PM), and Off-Peak O-D trip tables by vehicle occupancy.
Highway AM Loading
Preloads heavy trucks, then assigns passenger vehicles for three AM sub-periods
(6:30-7:00 AM, 7:00 – 8:00 AM, and 8:00-9:00 AM).
Highway PM Loading
Preloads heavy trucks, then assigns passenger vehicles for three PM sub-periods
(3:00-5:00 PM, 5:00-6:00 PM, and 6:00-7:00 PM).
Highway Offpeak Loading
Preloads heavy trucks, then assigns passenger vehicles for four off-peak subperiods (11:00 PM – 6:30 AM, 9:00 – 11:30 AM, 11:30 AM – 3:00 PM, 7:00 –
11:00 PM). Assigns only a single class of passenger vehicles, with no HOV
assignment.
Speed Balancing and Reporting
Combine Time Periods
Combines commercial and passenger vehicle flows, converts from hourly flows to
totals for the sub-period, combines sub-periods into AM, PM, Off-Peak, and MidDay totals, combines main periods into all day totals.
Speed Balance
Compares the resulting AM and Mid-Day periods speeds to the previous iteration,
if not converged, feeds the new speeds back into the peak and off-peak
geographic files, and starts the model again.
Report
The reporting procedure is not implemented in Version 1.0.
Page 9
Running the Model
Running Individual Steps
Each step can be run individually. After setting a scenario, if you click on the icon next
to each stage name, a dialog box will open allowing you to choose which steps in that
stage you want to run. You can do this for any of the stages, or you can click “Run All
Steps” at the top of the main model dialog box. Next to that box, is “Stop After Stages”
which will force the model to stop execution at the end of a stage. Clicking on the stage
name starts execution at that point.
As an example, say you wanted to run only an Off-Peak Highway Skimming. You would
take these steps:
1. Open the model, and set a scenario.
2. Leave “Stop After Stages” checked.
3. Click on the icon next to “DB Processing”, and uncheck all of the boxes except
for “Off-Peak Highway Skimming”.
4. Close that dialog box, and click on the words “DB Processing”
The model will execute the off-peak highway skimming step, and stop when it reaches
the end of the stage. If it is successful, it will give a message “Batch Routine
Successful”, and display some execution information when you click “OK”. Of course,
in this case, you will run into problems if you have not already run the initialization stage
to split the combined geographic file and compile the off-peak geographic file into a .net
file.
Running the Entire Model
To run the entire model, take these steps:
1. Open the model and set a scenario.
2. Uncheck “Stop After Stages”.
3. If you want to run speed balancing, click on the icon next to “Speed Balancing
and Reporting”, and check the “Speed Balance” Step. If you do not want to speed
balance, leave this box unchecked.
4. Click on “Initialization” to start the model at the beginning.
Page 10
The entire model stream will execute, and if you are speed balancing, it will continue to
iterate until the speeds have converged. Keep in mind that if it takes 12 hours to run one
iteration, and it takes 6 iterations to converge, you could be talking about 3 days of
execution time. Generally, this will not be the case, as you will be starting from speeds
that are almost converged.
The Area Type Model
Note that the area type model and the parking cost model are not run by default. After
running the Area Type model, DRCOG staff adjust the results by hand using our
planning judgment. In particular, we seek to maintain consistency between model years.
We do not want a zone that is urban in 2001 to become suburban or rural in 2010,
although it is OK for that zone to move up to fringe. Therefore, we recommend that
you do not run the area type model, as it will overwrite the adjusted values.
The Parking Cost Model
The parking cost model is also not run by default. You can run the parking cost model,
and should run it if you have a scenario that has significantly more development in the
CBD, or higher levels of service to the CBD. The parking cost model is an economic
model of supply and demand. The demand is the number of vehicles attempting to park
in the CBD, which we approximate as the HBW vehicle trip attractions to the CBD.
(Non-work trips tend to include shorter-duration activities, so we do not count them.)
The number of vehicle trips depends on the total person trip attractions to the CBD, the
number of those taking transit, and the average auto occupancy. The parking cost model
procedure opens the mode choice output matrix, and determines the CBD vehicle trip
attractions from that matrix. If an iteration of the model has not yet been run, and this
matrix does not exist, the parking cost model will crash. Therefore, you need to run a
model iteration before running the parking cost model. If the transit ridership or auto
occupancy to the CBD changes between iterations, the parking costs will change to, so it
is inherently an iterative process. If you are starting from a scenario that has been
iterated and converged by DRCOG, you can assume that the parking costs will not
change by very much, and skip that step. You cannot assume this if you make major
changes affecting the CBD.
The Dreaded Transit Skimming Bug
Unfortunately, TransCAD 4.5 has a bug that causes an illegal memory reference during
the drive to transit skimming procedure. During “Peak DB Preprocess” and “Off-Peak
DB Preprocess” the model creates highway skim matrices that store the travel time from
each TAZ to each PNR lot. These matrices store all of the information that would be
store in explicit drive access links, but in a matrix format instead of a link format. When
running the drive to transit skim, these matrices are used in place of explicit drive access
links, saving the user tremendous amounts of time that would be spent coding drive
Page 11
access links. The problem is that when this matrix is created, it is somehow incompatible
with the transit network files (.tnw files) that are also created in the DB preprocess step.
The bug has been corrected in TransCAD 4.7, but the model results change significantly
in TransCAD 4.7, which will force us to re-calibrate the model. We expect to finish the
re-calibration and release Compass 1.1 calibrated for TransCAD 4.7 in summer 2004.
While we were unable to fix the problem in TransCAD 4.5, we were able to find a way
around this problem. If the drive to transit skims are first run by hand for both the peak
and the off-peak, they will then work when run via the model. To run these by hand, take
these steps:
1. Run the Initialization stage to create the .tnw files and the origin to PNR skim
matrices.
2. Open the peak transit route system.
3. Go to Map à Layers, and show the node layer (not the stop layer).
4. While the node layer is the current layer, select the centroids. Do this by going to
Selection à Select By Condition, typing “id <= 2664”, and clicking OK. (The
centroid IDs are 1 through 2664).
5. Open the peak origin to PNR skim matrix (skim_PNR_pk.mtx), and make
“TIME” the current core.
6. Make the map active, with the node layer as the current layer.
7. Go to Transit à Multiple Paths, and select the peak transit network file.
8. A Transit Network Settings dialog box will open. Go to the Park & Ride tab,
click “Enable Park & Ride”, from the “Matrix File” drop-down, select “PNR
Skim”, and from the “Matrix” drop down, select “TIME”. Click OK.
9. A Transit Skims dialog box will open. Leave the input setting as the defaults, and
leave both “Create Parking Matrix” and “Skimming on Modes” checked. From
the Skim Variables list select: Fare, In-Vehicle Time, Initial Wait Time, Transfer
Wait Time, Transfer Time, Access Time, Egress Time, and Dwelling Time (fare,
and all seven of the time variables). From the Skim Modes list, select all of the
modes. Click OK.
10. An Output File Settings dialog box will open. Save the files in some temporary
location, and overwrite them if they already exist. You will not actually use these
files. Click OK.
11. A status bar will open that says “Initializing Matrix” for each matrix in the list in
step 9. Let these finish. When the status bar changes to “Computing Matrix
Page 12
(Row …”, click cancel. There may be a delayed response before it processes your
request. Because you do not need the outputs of this step, you do not need to wait
for it to finish.
12. Repeat with the off-peak files.
Having followed these steps, you have somehow corrected the incompatibility between
the origin to PNR skim matrix and the .tnw file. Now when you run the DB processing
stage, it will work (or start from Trip Generation if you have not run that yet). After
completing these steps, do not repeat the initialization step, as it will undo what you have
just done.
Speed Balancing
The decisions made throughout the model stream depend on the travel time between
TAZs, and are thus a function of link speeds. If the links speeds coming out of highway
assignment are significantly different from the link speeds assumed at the beginning of
the process, then the trip distribution and mode choice are based on invalid assumptions.
When this occurs, we need to speed balance by feeding a revised set of link speed into the
skimming process, and iterating the model until the input and output speeds match.
The speed balancing procedure in Compass 1.0 has changed considerably from what was
used in the old MinUTP model. The old model would average speeds by facility type
and area type, and feed the average speeds back. Thus it assumed that all urban freeways
operated at the same speed, which is clearly not true. The new model feeds back the
speeds on individual links, properly reflecting that it will take longer to travel inbound on
North I-25 during the AM peak than outbound. Because of this change, the speed
balancing procedure is much more sensitive, and network changes that may not have
required speed balancing in the past will now require it.
The “Speed Balance” procedure is a step under the “Speed Balancing and Reporting”
stage. It is not run by default, so you will need to check the box to run it. You may not
to run speed balancing by default, so you can examine the results at the end of each
iteration. If you do this, you can then re-start the model by running just the speed
balancing step.
Speed balancing operates on peak and off-peak speeds separately. The peak speeds used
are the average speeds for the entire AM peak period (6:30 – 9:00 AM). The off-peak
speeds used are the average speeds for the mid-day period (9:00 AM – 3:00 PM). When
speed balancing is run, it first checks for convergence by comparing the input speeds to
the output speeds. If no more than 1% of the links change speed by more than 10%, then
the speeds are considered converged. If the speeds are not converged, a new speed is
calculated for each link as the average of the input and output speed. These new speeds
are filled into the “AM_AB_SPEED” and “AM_BA_SPEED” fields of the peak
highway geographic file, and the “MD_AB_SPEED” and “MD_AB_SPEED” fields of
Page 13
the off-peak highway geographic file. The speed balancing procedure then restarts the
model at the “Peak DB Preprocess” step.
“Peak DB Preprocess” and “Off-Peak DB Preprocess” need to be run such that the new
speeds are properly reflected in the compiles .net and .tnw files. Unfortunately, because
these steps are re-run, the memory error in the transit skimming will again be
encountered. Therefore, you will need to run the steps above to correct that problem.
Viewing the Results
This section reviews some common model outputs that you may want to inspect after a
run. It is not meant to be a comprehensive list, just a starting point. Feel free to take
advantage of the capabilities of TransCAD to be creative in the way in which you view
and report model results.
Trip Generation
The trip generation results are stored in the file “pa_balan.bin”. For each zone, this file
shows the number of productions and attractions by trip purpose. You can join this file to
the table in the TAZ layer (taz2660.dbd, join to “ID”), and display the results graphically,
or inspect the values for specific zones. To get the total trips by purpose:
1. Open pa_balan.bin
2. Go to Dataview à Statistics
3. Select a temporary file in which to save the results. Do not overwrite anything
important!
4. The resulting table will show the count, sum, minimum, maximum, mean, and
standard deviation of each field.
Trip Distribution
The trip distribution matrices are stored in production-attraction format in the following
files:
HBW:
HNW, NHB, IE:
Commercial:
EE:
dst_hbw.mtx
dst_nwk.mtx
dst_com.mtx
dst_ee.mtx
Page 14
You can open and view these matrices as they are. To make them more understandable,
you may want to aggregate the results by area type or district. You can aggregate by area
type by taking these steps:
1. Open the trip distribution matrix, for example dst_hbw.mtx.
2. Open the zoneXXX.bin file.
3. Make the matrix active, and go to Matrix à Aggregate
4. Fill in the fields of the resulting dialog box as follows:
Dataview
Matrix ID Field
Aggregation Field
Rows
<name of zone view>
[Zone ID]
[Area Type]
Columns
<name of zone view>
[Zone ID]
[Area Type]
5. Click OK, and save the output file to a temporary location. Do not overwrite
anything important!
The resulting matrix will show the total productions and attractions by area type.
Mode Shares
The results of the mode choice models are stored in production-attraction format in the
following files:
HBW:
HNW:
NHB:
mod_hbw.mtx
modhbnw.mtx
mod_nhb.mtx
In the HBW matrix, all of the fields are person trips. The non-work matrices are more
complicated.
For HNW, “Auto_Shares”, “DriveAccTransit_Shares”, and “WalkAccTransit_Shares”
are the share of trips in each cell choosing each of those modes. “Auto”,
“DriveAccTransit”, and “WalkAccTransit” are person trips. A post-mode choice
procedure is used to split the auto trips into drive-alone, shared ride 2 (“Ride 2”), and
shared ride 3+ (“Ride 3+). These last three matrix cores are converted to vehicle trips by
the post-processor.
The NHB matrix follows the same format as the HNW matrix. “Auto_Shares” and
“Transit_Shares” are the share of trips in each cell choosing these modes. “Auto” and
“Transit” are person trips. “Drive Alone”, “Ride 2”, and “Ride 3+” are vehicle trips
calculated by the post-processor.
Page 15
The matrices can be aggregated like the trip distribution matrices. Also, you can
calculate the total trips using each mode by market segments. The matrix
Market_Seg.mtx has four cores with 0/1 flags specifying CBD attractions, DIA
attractions, Boulder attractions (excluding intra-Boulder), and all others. As an example,
you can calculate the HBW trips by mode to the CBD by multiplying the HBW mode
choice matrix by the market segment matrix. Again, be sure not to overwrite the results
onto an important file.
Highway Assignment Results
The highway assignment results are indexed by link ID and stored in these files.
AllDay.bin
All day results
AM.bin
PM.bin
OP.bin
MD.bin
6:30-9:00 AM
3:00-7:00 PM
All other times
9:00 AM – 3:00 PM (sub-set of the OP)
Am1.bin
Am2.bin
Am3.bin
Pm1.bin
Pm2.bin
Pm3.bin
Op1.bin
Op2.bin
Op3.bin
Op4.bin
6:30-7:00 AM
7:00-8:00 AM
8:00-9:00 AM
3:00-5:00 PM
5:00-6:00 PM
6:00-7:00 PM
11:00 PM – 6:30AM
9:00 AM – 11:30 AM
11:30 AM – 3:00 PM
7:00-11:00 PM
For each link, the tables show the vehicle flow in both directions and totaled, the travel
times and average speeds in each direction, the vehicle-miles traveled in each direction
and totaled, and the vehicle-hours traveled in each direction and totaled.
You will most often be interested in the all day totals. To get the total system VMT and
VHT, follow these steps:
1. Open AllDay.bin
2. Go to Dataview à Statistics
3. Select a temporary file in which to save the results. Do not overwrite anything
important!
Page 16
4. The resulting table will show the count, sum, minimum, maximum, mean, and
standard deviation of each field. The sum of Tot_VMT and Tot_VHT is the total
VMT and VHT in the system.
Also, you will often want to display maps of the traffic flows. To do this, take these
steps:
1. Open AllDay.bin
2. Open the highway geographic file (combined, peak, or off-peak will all work).
3. Click the “New Dataview” icon to display the table of attributes associated with
each link.
4. Go to Dataview à Join, and fill in the resulting dialog box as follows:
Name:
<use the default>
Joining from
Table:
PK_LINKS
Field:
ID
Joining to
Table:
Field:
AllDay
ID1
Click OK, and a joined dataview will appear.
5. Make the map active, and click on the “Automatic Labels” icon. In the dialog
box, select the field “AB_Flow / BA_Flow”, and adjust any of the display settings
as desired.
The all day traffic flows are now displayed on the links.
Transit Assignment Results
The transit assignment results are stored in the following files:
Tonf_pw.bin
Tonf_pd.bin
Tonf_ow.bin
Tonf_od.bin
Peak walk transit boardings and alightings
Peak drive transit boardings and alightings
Off-peak walk transit boardings and alightings
Off-peak drive transit boardings and alightings
Tasnt_pw.bin
Tasnt_pd.bin
Peak walk transit link flows
Peak drive transit link flows
Page 17
Tasnt_ow.bin
Tasnt_od.bin
Off-peak walk transit link flows
Off-peak drive transit link flows
Tasnw_pw.bin
Tasnw_pd.bin
Tasnw_ow.bin
Tasnw_od.bin
Peak walk walk link flows
Peak drive walk link flows
Off-peak walk walk link flows
Off-peak drive walk link flows
Generally, you will be most interested in transit boardings. The tables output by the
transit assignment procedures report the boardings and alightings for each route at each
stop. These results are probably not very useful unless aggregated, normally by route.
To do this, take these steps:
1. Open tonf_pw.bin.
2. Open the combined transit route system.
3. Click the “New Dataview” icon to display the table of attributes associated with
each route.
6. Go to Dataview à Join, and fill in the resulting dialog box as follows:
Name:
<use the default>
Joining from
Table:
Routes
Field:
ID
Joining to
Table:
Field:
tonf_pw
route_id
4. Click on the “Aggregate” tab within the join dataview dialog box. Select “One to
Many Join”. Aggregate the sum of “ON”, and none of the other fields.
5. The result will show the total boardings for each route. You can aggregate further
to total the boardings regardless of direction or pattern, but it may be easiest in an
external database.
6. Repeat for drive-access or off-peak as warranted.
Page 18
Working with Socioeconomic Data
To evaluate alternate development scenarios, you may need to modify the input data in
the zonal data set. You can change the household population, households by income
group, or employment by type to simulate the impacts of different developments.
As there are more TAZs in Compass 1.0 than in the old MinUTP model, you are less
likely to need to split TAZs further. If you do need to split TAZs further, keep the
following guidelines in mind:
•
The [Zone ID] in the zoneXXX.bin file corresponds to the ID in the taz2660.dbd
file, and also corresponds to the ID in the node layer of the highway geographic
file.
•
The zones and centroids are continuously 1 through 2664; 2628 through 2664 are
external stations.
•
Zones 9000+ in the taz2660 file are not within the transportation modeling area
and should be ignored.
•
Nodes 5000+ in the node layer of the highway geographic file are regular
intersection nodes. Nodes 2665 through 4999 are reserved for centroid IDs.
•
External stations are referenced in ee_base.mtx and in ExtStations.asc. If the IDs
of external stations are changed, these files need to be updated.
•
Several locations in the .rsc file select the centroids using the query “Select *
where id <= 2664”. These queries will need to be updated.
•
The area type model uses the file smooth05mi.bin. This file contains the fraction
of each zone within 0.5 miles of every centroid, and will be flawed if the zone
system is changed. Therefore, we recommend coding the area types by hand if
you split TAZs.
The previous list is not meant to be comprehensive, and we cannot guarantee your results
if a mistake is made while splitting TAZs.
Coding Highway Networks
Highway networks are coded using the combined highway geographic file. Link
geography should be edited using the map editing toolbox, and following the directions in
the TransCAD documentation. Be sure to snap any links to the appropriate intersections
to avoid leaving “stub” links. There is also a tool in TransCAD that can be used to check
the connectivity of the line layer.
Page 19
The following link attributes need to be updated when coding highway networks:
DIST
the length of the link unless curvature makes it longer
DIR
-1 B to A
0 two way
1 A to B
Facility Type 1 – Freeway
2 – Expressway
3 – Principal Arterial
4 – Minor Arterial
5 – Collector
6 – Ramp
8 – Centroid Connector
LANE
Number of through lanes in each direction
TOLL
0 – no toll
1 – toll road
6 – on-ramp to toll road
USE
0 – no HOV restrictions
1–
2–
3–
4–
5–
6–
7–
8–
9–
10 –
11 –
12 –
13 –
14 –
In addition, these speed fields may be filled in:
AM_AB_SPEED
AM_BA_SPEED
MD_AB_SPEED
MD_BA_SPEED
Page 20
These fields provide a starting point for the speed balancing process. If they are left
blank, a default speed is used as the starting point. Better starting speeds will allow the
model to converge in fewer iterations. Therefore, you can take these speeds from the
peak and off-peak highway geographic files from a similar model run.
TransCAD’s map editing toolbox allows you to set rules for determining how attributes
get allocated when links are split. You should set the rules as follows:
DIST
DIR
Facility Type
LANE
TOLL
USE
add
copy
copy
copy
copy
copy
Finally, note that some changes will need to be made to the highway geographic file
when coding transit networks. This includes adding any transit only links, and specifying
any Park-n-Ride lots in the node layer.
Page 21
RTD Transit Coding Manual
Introduction
RTD runs the DRCOG model. We model average weekday service that is determined by
fixed routes. Thus, we do not model special services such as RockiesRide, BroncosRide,
call-n-Rides, and Access-a-Ride. RTD has some 170+ fixed transit routes that are
modeled.
Transit trips are assigned in Production-Attraction format (P-A). This differs from auto
trips which are assigned in Origin-Destination (O-D) format. P-A format particularly
affects how the peak transit service is modeled.
Transit service that is modeled through the travel demand model is represented by fields
for the peak and off-peak time periods and mode in the *.rts file. There is an extra field
for early-late service. This field exists only for use in the Operations & Maintenance
(O&M) model (to be discussed later).
•
The Peak_Hdwy field represents the morning peak service, roughly from 6–8
AM. P-A format takes care of the afternoon peak service.
•
The Off_Peak_Hdwy field generally represents service between 10 AM–2 PM.
•
The Early_Late_Hdwy field generally represents service after 9 PM and before 6
AM.
•
The Route, Pattern, Direction, and Shadow fields exist to help others better
understand how the routes are named and do not play a role in the running of the
model. The Route_ID, Route_Name, and MODE fields do play a role in the
running of the travel demand model.
•
The Company, Service_Type, and Equipment_Type fields are for use in the
O&M model. The Company field is leftover from the MINUTP model and was
used there as input to the O&M model. It is not clear yet whether RTD will
continue using this field in the same way in TransCAD®, so it has been left
blank.
Service Changes
RTD Service Planners make service changes to the transit routes three times per year:
January, May, and September. We prefer to model service in January or September of
any given year because that is when school is in session. In May, service on some routes
is cut back to reflect that school is out.
All RTD transit routes and some non-RTD operated routes, e.g. LINK and HOP, are
published in a guide created for the bus drivers known as the Trailblazer. The Trailblazer
Page 22
is printed three times per year in conjunction with the service changes and gives specific
directions to bus drivers on how to travel on any particular route. In the back of the
Trailblazer you will find diagrams of various park-n-Rides, downtown Denver stops,
Union Station, and other RTD facilities. Learn how to read and use the Trailblazer. You
will find it along with the route schedules to be an invaluable tool when coding transit
routes. All transit schedules can be found on the internet at www.rtd-denver.com.
park-n-Rides, Transit Centers, Bus and Rail Stations
park-n-Rides, transit centers, and bus and rail stations are usually the first items to be
determined when coding transit networks. Existing park-n-Ride locations, transit centers,
and bus and rail stations should already be included in the route systems layer and are
found on the RTD Systems Map. The Systems Map also indicates all the existing routes
that go to these facilities. Future facility locations are often determined internally at RTD
based on fiscal constraints as outlined in RTD’s internal Transit Development Program
(TDP) and should already be included in future year networks. Corridor studies
determine their own park-n-Ride and station locations.
park-n-Rides are added in TransCAD® through a dummy variable by placing a 1 in the
PARKING field at the particular node location of the park-n-Ride. Also, be sure to
name the park-n-Ride in the appropriate field. There is no method to determine capture
areas for park-n-Rides in the TransCAD® model. Rather the approach taken in the
calibration of the model was to allow users to go on the highway network to get to parkn-Rides.
Existing rail stations are determined by the Systems Map and the Facilities and Properties
book and should already be located in the model. Future rail stations are determined first
by the appropriate EIS if one exists, such as with the T-REX project. Otherwise, other
corridor studies determine their own rail station locations. When a rail station is added to
the model, be sure to put a 1 as a dummy variable in the rail station field and enter the
station name in the appropriate field. The dummy variable for the rail station field does
not affect the running of the model but was included to make it easier to display rail
stations on maps.
Transit (Route Systems) Coding
All transit routes are based on actual schedules and routing. Calibration and validation of
the model required going through each route and schedule in the system and inputting
this information into the model.
To code routes you must determine their routing, headways, and stops. Many routes have
multiple patterns. In the MINUTP version of the DRCOG model some routes had
shadows which are determined by fares. Shadows have been eliminated in the
TransCAD® version of the model. A spreadsheet of routes has been created that details
all headways, patterns, and shadows, if appropriate, of routes.
Page 23
Know that RTD operates or contributes to almost all the bus service in the Denver metro
area. This situation is unusual since in most metro areas many different transit agencies
provide service to the entire area.
Be conscious of the RTD and community facilities that the routes were designed to
access such as park-n-Rides, rail and bus stations, malls, hospitals, sports facilities, etc.
Make your best effort to connect the appropriate routes to the zones containing these
facilities. You may even need to add centroid connectors and walk links to zone
centroids. If you do feel you need to add centroid connectors and walk links of any kind,
it is usually best to check with RTD first.
Routes running along US 36 and North I-25 usually use the North I-25 reversible, barrierseparated HOV lanes. It is important for anyone coding routes on or near this facility be
familiar with how this facility works! See below for a description and operation of this
facility.
US 36/I-25 Direct Connect and North I-25 HOV lane Description and Operation
The construction of the Direct Connect allows HOV users on US 36 to connect to the
reversible, barrier-separated HOV lanes on I-25 without entering the General Purpose
lanes on either roadway and vice versa during the peak period in the peak direction and in
the off-peak in the NB I-25 to WB US 36 direction. The construction on the Direct
Connect was supposed to be complete in December 2000 but instead was not finished
until May 2001.
Prior to 2001 US 36 had an all-day HOV lane in the EB direction only from Sheridan
Blvd. to just west of I-25. Thus, there was no HOV lane for those going in the WB
direction on US 36 any time of day. Because the Direct Connect did not exist, users on
the US 36 EB HOV lane in order to get to the I-25 HOV lanes had to leave the EB US 36
HOV lane, exit into the General Purpose lanes on US 36 and I-25, and then get back onto
the I-25 HOV lanes at 58th Ave. to go to downtown Denver via HOV. They could do
this only in the AM peak period in the peak direction which is SB on the I-25 HOV lanes.
The North I-25 HOV lanes still only operate SB in the AM peak.
At about 10 AM CDOT goes through the process of closing and sweeping the HOV lanes
so that their direction of operation can be reversed. At about Noon the north I-25 HOV
lanes open in the NB direction for carpools and off-peak service on buses bound for
Boulder and the north metro area. You can actually see this happening by looking at the
bus schedules for routes B and 120X. The North I-25 HOV lanes remain operating in the
NB direction until about 2 AM on weekdays that covers the PM peak period operation
too. Sometime in the early morning on weekdays the direction is reversed again to allow
travelers going SB into downtown in the AM peak to use the HOV lanes again. On
weekends the North I-25 HOV lanes remain operating NB through the entire weekend.
In the PM peak and off-peak you could and can still only travel the I-25 HOV lanes in the
NB direction. Since there was no WB US 36 HOV lane prior to 2001, there was no PM
Page 24
peak period or direction to deal with there. For users entering and exiting the I-25
reversible, barrier-separated HOV lanes from I-25, users still must enter or exit at 58th
Ave. A user could and can still enter the reversible, barrier-separated HOV lanes from
70th Ave. via a T-ramp, but only from 70th Ave. By the way, the I-25 HOV lanes are
two lanes south of 58th Ave. and one lane north of 58th Ave. to 70th Ave. and on through
the Direct Connect.
Now that the Direct Connect is complete, a user can travel along the US 36 HOV lanes to
the I-25 HOV lanes without getting in the General Purpose lanes. An HOV lane in the
WB direction was added to US 36 only as far west as Federal Blvd. The original intent
was to build the US 36 WB HOV lane all the way to Sheridan Blvd., but there was not
enough money to fix the 80th Ave. bridge so they stopped the WB HOV lane just short of
80th Ave. at Federal Blvd.
In order for a user to travel through the Direct Connect via the US 36 HOV lanes, the
user must enter and exit the US 36 HOV lanes west of the Pecos interchange. Users
cannot get on and off the US 36 HOV lanes east of the Pecos interchange because the
HOV lanes are reversible and barrier-separated at this point. Also, drivers getting on and
off US 36 from Pecos cannot get on and off the HOV lanes at this interchange either due
to the barrier-separation.
Additionally as part of the Direct Connect construction, the WB I-76 to WB I-270 to WB
US 36 connection was built. The EB US 36 to EB I-270 to EB I-76 connection was not
completed until later in 2003. The WB I-76/I-270/US 36 connection eliminated the need
to have a ramp going directly from WB I-76 to NB I-25, so this movement was removed.
Also, CDOT is currently constructing an entrance and exit to the I-25 HOV lanes north of
the US 36/I-25 Direct Connect.
Patterns and Headway Determination
Many routes have multiple patterns. Patterns are determined by where trips start and end
on a route.
•
To determine the headway and, if applicable, patterns of a route, look at where
trips start and end on the route. A pattern is a series of trips on a route with the
same start and end points.
•
For peak service, look at the morning peak period, generally from 6-8 AM, due to
P-A format (see above). The peak period for Local routes generally falls between
6-8 AM. The peak period for Express and Regional routes can occur a bit earlier.
•
For off-peak service, look at the trips generally between 10 AM-2 PM.
•
Count the number of trips within a two hour time period. Use the table below to
determine the headway. With many routes you will notice a common headway.
Page 25
•
Generally, we try to use headways that divide into 60 minutes evenly, e.g. 5, 7.5,
10, 15, 20, 30, 60; not 3.3, 5.7, 13.4, etc.
•
Try to understand the intent of the service planners when determining headways.
Number of Trips
1-2
3
4
5-6
7-8
8 or more
Headway (minutes)
60
40
30
20
15
“actual” (Calculate by dividing 120 minutes by the
number of peak period trips)
Shadows
Shadows of routes were created in the MINUTP® version of the DRCOG model to
represent segments of routes that charge lower fares. Many Regional and Express routes
charge different fares depending on where the rider boards on the route. For example, a
rider boarding the route B in Boulder and riding it to Denver pays a Regional fare. A
rider boarding the route B in Broomfield and riding it to Denver pays an express fare.
These fares are determined by looking at the paper schedule of a route.
Because determining the possible shadows of every route would result in an
unmanageably large number of shadow routes and relatively small gains in accuracy,
only those shadows where 15% of their total fares are collected in the lower fare
categories are coded. These shadows have already been predetermined in the model.
Refer to the spreadsheet to see what shadow lines have been coded. Headways for
shadow routes should be the same as the original route. Make sure to change the MODE
field when coding shadows.
In the latest version of calibrating the TransCAD® model, shadow routes have been
eliminated and replaced with distance-based fares in the model code. This action was
taken so that headways were not being overmodeled for routes with shadows using the
algorithms provided in TransCAD®.
Stops
RTD has a bus stop database, the Bus Stop Information System (BSIS), that can be used
to look up stops on a route, but only RTD internally has access to this database.
Regardless, for most routes stops can be accurately placed on routes by using the
Trailblazer, following the rules below, and looking at similar routes. Even if BSIS were
accessible to those outside RTD, many local streets do not exist in the model to
accurately place stops in the correct locations, especially for local routes. Thus, the
Page 26
guidelines below should be followed when placing stops on a route. If you have any
questions, do not hesitate to contact RTD.
Local routes: stop at all centroid connectors and street intersections, except in
downtown Denver and other parts of the metro area with a dense street system in the
model. Look at similar routes for help.
The stops in downtown Denver for bus routes traveling on 15th and 17th streets are based
on an XYZ naming system where a bus stops once every three blocks. This helps
manage the flow of buses through downtown. Certain bus routes stop at the "X" stops,
certain bus routes stop at the "Y" stops, and certain bus routes stop at the "Z" stops. The
Trailblazer details which downtown-oriented routes stop at the X, Y, and Z stops by
noting above the map of the route what type of stops are used in the upper right hand
corner of the page. Also, all Trailblazers are supposed to have a diagram of downtown
Denver in the back of the book with the other diagrams that details the XYZ stops on 15th
and 17th streets as well as other downtown Denver transit facilities. A table listing the
XYZ stops is also provided below.
Street
15th
X Stops
Tremont
California
Curtis
Y Stops
Glenarm
Stout
Arapahoe
Z Stops
Welton
Champa
17th
Lawrence
Champa
Welton
Arapahoe
Stout
Glenarm
Curtis
California
Tremont
Limited routes: stop at intersections with crossing routes and locations specified in
Trailblazer
Express and Regional routes: stops are usually specified in the Trailblazer
Usually, RTD does not put stops on a route at highway ramps unless a park-n-Ride exists
there and the route stops there. Sometimes a route will stop on the opposite side of an
interchange with a park-n-Ride to allow riders to get on and off and walk to the other
side, e.g. at the US 36/McCaslin interchange.
Loop routes unlike most routes will stop at the same places twice, but TransCAD® does
not allow routes to have two stops at the same node. However, TransCAD® will allow a
route to have one stop with multiple passes at the same node. Thus, in the case of Loop
routes, allow the stops to have two passes when it serves a location twice, etc.
Try to stack up stops on a route in TransCAD®. Thus, if, for example, ten routes stop at
the same park-n-Ride, make all the stop icons stack up so that the number “10” shows on
top of them. We want to give riders the best opportunity to transfer as possible.
Page 27
Roadway Layer Coding
Changes to the roadway network are normally under the purview of DRCOG, except
where consultants and others will need to modify the roadway network to model a future
alternative. DRCOG maintains the roadway layer. The following table breaks out the
function of each type of link.
Type
0
1
2
99
Purpose
Roadway base link for transit
Roadway link
Transit only—no walk or auto
Walk only—no transit or auto
98
Transit & Walk only—no auto
97
96
Walk Access to park-n-Rides
Drive Access to park-n-Rides
Use
Rail lines
e.g. Pedestrian overpasses, connect to
zone centroids
e.g. 16th St. Mall, Union Station
access
Not needed—replaced by Walk links
Not needed—replaced by new Drive
Access method
HOV Lane Coding
Rail Coding
Rail lines are coded using a combination of the roadway layer and the route systems
layer. Look at how other rail lines are coded to see how it is done. To code rail lines you
must:
•
Determine locations of rail stations and park-n-Rides.
•
Add links in the roadway network between each station.
•
Add 2 in the TYPE field. All rail links in the model are TYPE 2 indicating that
no one can walk or drive on these links.
•
Add distance and speed on each link to be inserted into the DIST and T_SPEED
fields respectively. Distances and speeds for rail lines are predetermined by
consultants prior to running the model.
•
All rail links are bidirectional and so receive a 0 in the DIR field.
•
After inserting links in the appropriate places with the appropriate attributes,
remember to code the rail routes in the Route Systems layer on these links with
the appropriate stops, headways, and mode.
Page 28
Modes
Transit routes are divided into Modes. Modes are differentiated mostly by their fares but
also other characteristics as found in the modes.dbf table. Changes in Mode shall be
made in the MODE field in the *.rts file. If changes are made in fares to a mode, the
modes.dbf and the modexfer.dbf tables both need to be changed. Check out these tables
to learn the different characteristics of the modes. Know that the TransCAD® model has
been calibrated in 1996 dollars.
Mode 4—Mall Shuttle and other free transit services.
Mode 5—Denver Local service and local shadow lines where appropriate
Mode 6—Limited service
Mode 7—Express, intra-Boulder County routes (J, M, N, Y) and express shadow
lines where appropriate
Mode 8—Regional service and regional shadow lines where appropriate
Mode 9—Rail service (light rail and commuter rail)
Mode 10—skyRide service
Mode 11—Longmont Local service
Mode 12—Boulder Local service
Error Checking
When coding transit routes in TransCAD®, get in the habit of Reloading your route
system under the Route Systems menu. Reload regularly after coding a few routes at a
time. Reload, Reload, RELOAD!!!! Reloading will output some errors in the route
system, but you will need to run other processes to get all errors. Errors in the Route
System are often outputted in the *s.err and *l.err files. The “s” stands for stops and the
“l” stands for links. Look at these files through a text editor. When all errors are
corrected in this file, the last few errors to be corrected will often be leftover in the file.
After reloading your route system, Verify your route system through the Route Systems
menu to output anymore errors. Check the warnings file for errors that must be corrected
in your routes. The Verify function also sometimes outputs messages that tell of links in
the roadway network that need attributes added.
Before creating your transit network, be sure to use the Tag Stops To Node function
under the Transit menu. This function will make sure that any stops that do not have a
node associated with them as found in the Near Node field in the Stops table will have a
node indicated with the stop. This function will reveal any duplicate stops at nodes.
Last, create your transit network under the Transit menu. If your transit network is error
free, you should be able to run this function without any problems.
Common Errors
Page 29
Many common errors in TransCAD® come from learning how to use the software and
become more obvious as to how to correct them as you get used to using the software.
Learn how to switch route editing methods. Errors that may be more difficult to fix that
only come with understanding how the transit network interfaces with the roadway
network are outlined below.
Problem: When coding a transit route, the route cannot recognize the street that you
are trying to put the route on.
Solution: The *.net file that the transit network runs on may not have been updated
to reflect the latest roadway network. Go to the Networks/Paths menu, then Create…
to create a new or updated *.net file. It is okay to create a new *.net file from scratch.
Problem: Stops at a particular node are being very difficult to delete.
Solution: TransCAD® uses a linear referencing system to track stops on a single
route. Depending on how much time you have to code route systems, sometimes
after working on a route systems for awhile the stops will be able to be deleted.
Alternatively, go to the stops table and select the records with the problem stops.
Then go to the Edit menu and the Delete Records function to delete the problem
stops. At this point it may be helpful to do a Reload to clear any problems. Then try
going back and adding stops again.
Problem: After a Route Systems Reload, an error message appears saying the
software is “Out of Memory.”
Solution: Reloading allows TransCAD® to reassemble the Route, Stop, and Link
layers into a unit that allows the transit network to interface with the roadway
network appropriately via the “Chunk” layer. Reloading creates the Chunk layer in
TransCAD®. To solve the problem, delete the “Chunk” layer whose files are *c.bin,
*c.bx, and *c.dcb as well as the *.rtg file. Open your route system again and you
should be forced into an automatic Reload.
Operations & Maintenance Model
RTD contracted with Manuel Padron & Associates in 2001 to create a spreadsheet
Operations and Maintenance (O&M) model based on the Cycle 9 2001 DRCOG
MINUTP model. The purpose of the O&M model was to eliminate the cumbersome task
of entering output data from the MINUTP model into a spreadsheet and equilibrating that
data which would be used to calculate reasonable O&M costs in future transit
alternatives. Because the O&M model has not been calibrated with the new TransCAD®
model, it cannot yet be used with this software.
Page 30
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising