SPD2000

Network Speed Calculator Documentation

Gregory T. Giaimo

The Ohio Department of Transportation

Planning Division

Office of Technical Services

July 2001

Contents

Introduction3

Program Operation4

Program Installation & Usage6

Link Data Requirements by Level of Detail Setting8

Parameters Coding & Default Values11

Appendix A. Total Travel Time Speed Table12

Appendix B. Running Time Speed Table13

Appendix C. Sample Parameter File14

Appendix D. Link Group Codes & Associated BPR Curves15

Appendix E. Standard Functional Class & Areatype Coding16

Appendix F. Program Source Code17

Introduction

Travel time is the most important attribute of a link in travel demand forecasting networks. Travel time on travel model networks is expressed in terms of speed to remove the effect of the link length. Traditionally, these speeds were developed from travel time runs which used 1/3 of the peak time plus 2/3 of the off peak time to develop the link speed. This "LOS C"speed was supposed to represent the average conditions of a roadway over a 24 hour period and was designed to be used in conjunction with an "all or nothing" or "capacity restraint" assignment procedure which required accurate initial speed estimates to produce good results. Over time, these speeds were further modified during the modeling process to yield better link volume assignment results.

In the summer of 2000, ODOT conducted a statewide travel time study (1) to provide information for developing update travel model link speeds. This was motivated by 3 factors. First the need to develop network speeds for the statewide model. Second, the fact that the MPO models will be completely revised corresponding to the 2000 Census. Third, the shift in traffic assignment methods from "all or nothing" and manually weighted capacity restraint to equilibrium methods. Equilibrium traffic assignment requires an estimate of free flow speed be coded on the links rather than the partially congested speeds coded previously. This speed acts as an upper bound to the equilibrium process which can go through large numbers of iterations producing congested speeds internally. It is therefore not as dependent on the initial estimate of speed as the older methods.

The following provides documentation of a program which will apply the speed tables developed from this study to a Tranplan format travel demand forecasting network. The speed table is based upon the functional class, area type, terrain type and number of lanes of the roadway. In addition, small adjustments based on HCM 2000 guidelines are made to account for the effects of lane width, median TWLTL's and number of lanes on freeways because these effects were not measured directly in the field. Once the free flow speeds are calculated, the program also develops a link group code for each link based on the functional class, areatype and free flow speed. This link group code is needed to use the family of BPR type curves recommended by the 2000 HCM for older software (such as Tranplan) which is unable to implement HCM procedures internally.

In addition, a supplementary program called CSPD2000 will be described as well. This program will update the old LOS C based network speeds based on a regression analysis of the posted speed by functional class/area type category. These speeds are useful for the building of the impedance matrix used for the initial run of the demand models prior to feedback of congested times from the assignment model.

(1) "Statewide Travel Time Study", Ohio Department of Transportation, May 2001

Program Operation

The source code for the SPD2000 program is included in Appendix F. This program uses the same input/output, lane width and truck and terrain type assignment algorithms as the capacity calculator program. Its operation can be summarized as follows:

  • Read Parameters
  • Read Speed Table
  • Read Link File Skipping LOD 3 Data if LOD set to 1
  • Make Width Directional if Necessary
  • Over-ride Truck and Terrain Type if Coded on Link
  • Approximate Number of Lanes if Not Coded on Link
  • Determine the Roadway Type Based on Area Type, Functional Class, Number of Lanes and Terrain
  • Round the Posted Speed to One of the Entries in the Speed Table
  • Calculate Speed Independently for Each Link Direction
  1. If a Freeway, Adjust Speed for Lane Width and Number of Lanes
  2. If not a Freeway, Adjust Speed for Lane Width and TWLTL
  • Check to Make Sure the Posted Speed for the Given Roadway Type is Within Range
  • Modify the Speed Based on the SPEEDMOD Field if SMOD = Y
  • Compute the Link Group of the Link

The speed tables used are shown in Appendices A and B. The total travel time speed table of Appendix A is to used at this time. The running time speed table of Appendix B is only for use if explicit intersection modeling is used. These speed tables indicate the roadway type categories that are assigned by the program. There are 19 different types assigned. The speed table speeds are given for posted speed values ranging from 25 MPH to 65 MPH in 5 MPH increments. As noted above, the link coded speed is rounded to the nearest value appearing in the table.

Once the speed table value is found it is modified based on the following table:

Functional ClassLane WidthModification

Freeway<11-6.6

Freeway11-1.9

Freeway>110.0

Centroid ConnectorAny0.0

Else<11-2.5

Else11-1.0

Else>110.0

Functional ClassTWLTLModification

FreewayAny0.0

Centroid ConnectorAny0.0

ElseYes+1.0

ElseNo0.0

Functional Class# LanesModification

Freeway2 (by direction)0.0

Freeway31.5

Freeway43.0

Freeway>44.5

ElseAny0.0

Note that the adjustments applied to non-freeways do not follow the HCM guidance, they were selected based on some rough estimates of the conditions that existed in the survey sample set versus the "ideal" conditions discussed in the HCM. The freeway values do follow HCM guidance, they have, however, been applied equally to rural and urban segment contrary to HCM guidance. This was done because the free flow speeds obtained in the study were much lower than the "ideal" free flow speeds given by the HCM. It was found that applying the # of lanes adjustment for a 5+ lane road in both rural and urban areas would give free flow speeds in better agreement with HCM ideal value. This points out that the lower free flow speeds obtained in the study were the result of most of the sample segments having only 2 lanes (by direction).

Once the speed table value is found it is checked to see if it is within range. A look at the speed tables in Appendices A and B shows some speed entries of zero and negative entries. Zero, values represent impossible posted speed limits for the given roads, in such cases a warning message will be given and the speed will be set based on the maximum possible speed limit for that roadway type. Negative values are speed calculated outside the range of values observed in the travel time study. These values are, however, possible and have generally been set using regression analysis with some manual adjustment to produce reasonable values. When one of these values is used a warning message will also be written and the value will be used as is (except not negative).

When comparing the speed tables given in the Appendices to those in the travel time study report (1), some slight discrepancies will be noted. Some adjustments were made to insure that illogical speed do not result in the model. The biggest change that will be noted, however, is that freeway speeds for rural and urban classes which were only observed at 65 MPH in the field have been carried down to a posted speed of 50 MPH (via educated guess work) to account for those situations that might arise. Another major change is that the on and off ramp categories have been combined into average ramps speeds to insure that the interchanges remain reasonably balanced. Another difference that will not be apparent from looking at the tables is that the township classifications are not used in populating the networks. Analysis showed that implementing the lane width factor accounted for most of the difference between township roads and other local roadways.

As mentioned above, the final thing the program does is assign link group codes for use in determining the proper BPR type curve to use in the assignment process. This is done here because this requires the free flow speed which isn't available until the SPD2000 program is run. Appendix D shows the various link groups and the associated BPR curve parameters. These curves have been designed to accompany the CAP2000 program which produces LOS E capacities.

CSPD2000

Operation of the CSPD2000 program is as follows:

  • Read input link file and categorize each link by areatype and functional class
  • Accumulate statistics for each class needed for regression analysis
  • Calculate regression equation by class, if unable or if regression slope is negative use the average
  • For each link with posted speed and no LOS C speed coded, calculate its LOS C speed
  • Output new link file
  • Output regression statistics

A few notes, the software will only populate links with a posted speed but no LOS C speed. As mentioned above, if regression analysis is impossible (for instance if there is only 1 posted speed within a category) or if the regression slope is negative, the program simply uses the average LOS C speed for all links in the category. Also note that since the program bases its speed estimate on the speeds already coded to the network, this program cannot be used on a network with no speeds coded, it is only meant to update networks with most LOS C speeds already coded. The program applies a minimum speed of 5 MPH. Area types of OBD and LAU are treated as urban and rural respectively. If a new link has a functional class/area type combination that doesn't currently have any links with populate LOS C speeds, the program first searches other area types for categories with the same functional class, it begins with urban then suburban, rural and cbd. If it can't find a populated category with the same functional class, it then holds the area type constant and searches other functional classes beginning with arterial, then collector, local, centroid, freeway, expressway, and ramp.

Program Installation & Usage

SPD2000 and CSPD2000 are supplied in a zipped file containing all necessary executables and batch files, a sample parameter file and the ODOT free flow speed table. This file will either be sent on floppy disk or via email. The zipped file should be copied to a directory that exists on the users PATH and unzip the file using WINZIP. The parameter file should then be copied to the users working directory and edited to cause SPD2000 to run as desired.

SPD2000 and CSPD2000 should be executed using the supplied batch file called NETPOP.BAT. This batch file translates the DBF network to a modified form of the old 80 character ASCII link file for use by SPD2000. NETPOP also runs programs for creating capacities and turn penalties. If these functions are not desired the batch file can be modified to remove the unwanted computations. To run NETPOP simply type:

NETPOP <inputlink.dbf> <inputnode.dbf> <capcalcpar.txt> <speedtable.txt> <outputlink.dbf> <outputturns.txt> <optionalinputturnprohibitors.txt>

In the above command line, specific file names should be inserted between the >, the file name extensions shown merely indicate the file type (DBASE or ASCII) the user is free to use whatever file name extensions they wish. To run NETPOP it is important that the following executable files exist in a directory in the users PATH or in the directory from which NETPOP is run: CAP2000.EXE, CSPD2000.EXE, DBFMRG2.EXE, DBFLNKA.EXE, DBF2ASCA.BAT, ASC2DBFA.BAT, ASCDBFA.EXE, SPD2000.EXE, TURN2000.EXE, LOG2000.EXE.

The various input files should generally exist in the directory from which NETPOP is run, it is possible to specifiy directory paths with the file names, however, this is not recommended because the number of command line arguments is quite large and there is a limit on the total number of characters that all command line arguments can contain.

The SPD2000 program can also be run directly by typing:

SPD2000 <inplink.txt> <outlink.txt> <capcalcpar.txt> <speedtable.txt> Y|N > LOGFILE.TXT

In this case the input and output link files will be ASCII Tranplan link files. The input file should be created using the ASC2DBFA routine without changing any of the settings in that batch file. The parameter file is can be the same one used for the capacity calculator. The only parameters used from that file are WDR, WFY, TER and LOD. These parameters behave exactly as they do in the capacity calculator because they are used for the same purpose, namely determining the lane width, number of lanes and terrain on each link. These items are then used to determine the appropriate row of the speed table. The parameters are discussed more in the parameters section.

The speedtable file is supplied with the zipped file. This file can be edited in a text editor if the user has other values they would like to use, however, the same row and column headings must be used. Two speed tables are supplied, ffspeedt.prn and ffspeedr.prn. The ffspeedr.prn file should only be used if intersection delay is being modeled explicitly (never in Tranplan) because it represents running speeds. The ffspeedt.prn table should be used in all other cases since this represents total travel time speed.

The Y|N option to SPD2000 tells the program whether or not to use link specific speed modifiers. This parameter is set to Y in the delivered NETPOP.bat file so if speed modifiers are not desired the batch file should be edited to change this to an N. Speed modifiers are stored in the SPEEDMOD field of the standard DBASE link file. These modifiers can be positive or negative and can be up to 3 digits. Any decimal places will be lost because the SPEEDMOD will be placed in the 4 character Tranplan SPEED2 field when the network is converted to ASCII prior to running SPD2000. If running DBF2ASCA manually, it is important that the 7th command line argument to DBFLNKA be set to 1 when running this prior to running SPD2000. Setting this option to 1 will cause SPEEDMOD to write to the Tranplan SPEED2 field without being multiplied by 100 thus allowing up to 3 digit speed modifiers (with a possible minus sign). This is the default setting in the DBF2ASCA.BAT file so it should not pose a problem. If it is desired to populate SPEED2 with a normal Tranplan readable speed, then DBF2ASCA.BAT must be edited to change this command line argument to a 0.

SPD2000 writes a number of messages to the screen. These include warning messages as described in the previous section as well as a summary statistics table showing the resultant speeds by roadway classification after the application of link specific modifiers and lane width/TWLTL/# of lane modifiers. This table is useful for checking how much the various speed modifications have altered the average network speeds from those present in the speed table. To save this output to a file, the redirection symbol and a filename should be given as shown in the above example.

CSPD2000 can also be run directly from the command line by typing:

CSPD2000 <inplink.txt> <outlink.txt> > LOGFILE.TXT

The ASC2DBFB.BAT program should be used to create the input ASCII link file in this case. The DBF2ASCB.BAT program can then be used to take the output file back to DBASE. The log file contains the regression parameters for each functional class/area type category.

SPD2000 and CSPD2000 need link specific data which is coded on the link file. The next section shows the various link data and the columns of the link file where the data is coded. As mentioned previously, the link and node files should be in the ODOT standard DBASE format. It is very important that prior to running SPD2000 and CSPD2000 the DBASE link file be changed as follows:

  • Recode the FUNCLASS field to the Ohio standard codes
  • Recode the AREATYPE field to the Ohio standard codes
  • Change field POSTTIME to SPEEDMOD
  • Move the old model speed out of the POSTSPD field (if its there) to PEAKSPD
  • Populate the POSTSPD field with posted speed limits
  • If the user has anything in the LNKGRP field, move it somewhere else
  • For consistency with the new Ohio standard, users might also want to rename the FACTYPE field FEDFUNC

SPD2000 and CSPD2000 should be run as part of the job stream for creating networks for traffic assignments and post-processing. Model speeds should not be hard coded. If the speeds on a link are incorrect, then the data that generates those speeds should be examined. If there is still a problem, then the SPEEDMOD field should be used to modify the speed as needed. Use of this field will allow easy identification in the future of areas where the speed had to be adjusted. Note, that the SPEEDMOD field will only effect the free flow speeds in the OFFPSPD field not the LOS C speeds in the PEAKSPD field. The speeds in the PEAKSPD field can be edited manually if desired, however, since they are meant to only provide first iteration estimates to the demand model (which should later be over-ridden through feed back from the assignment model) these are not as important and generally should not need to be modified.