1. Why do we need this new framework?
The previous transit modeling framework needed a re-evaluation for two reasons. First, the Florida Model Task Force voted to migrate to the FSUTMS-Voyager platform in 2004. Voyager's transit module, Public Transport (PT), is quite different from Tranplan in its format and operation. So different, in fact, that maintaining the existing framework in its entirety was not a viable option.
Second, the Federal Transit Administration's (FTA's) oversight of forecasts related to the New Starts program over the past five years have provided a number of adjustments to transit model "state of the practice" concepts. Modeling insights gained from FTA indicate that many ideas initially considered good practice in fact have many bad or undesirable properties during forecasting. In fact, they may render the model results inexplicable. Consequently, FTA has released recommended model properties and other findings to the modeling community in the hopes that future modeling systems will avoid these practices (or continuing them in some cases). The previous framework did not include some of these model properties, making them vulnerable to FTA scrutiny. Re-evaluating the transit modeling framework offered the opportunity to develop a new system with these properties in mind.
2. How was this framework developed?
The new framework was developed with four goals in mind: (1) maintain the existing standards to the extent possible, (2) meet user and planner needs, (3) maximize the features and capabilities of Voyager and PT and (4) be consistent with all known New Starts/Small Starts & FTA guidance.
The initial draft of the framework was developed in summer 2006 and was based on all PT-related work experience at the time. It was refined as the result of consultations with the FDOT staff, Federal Transit Administration (FTA), Citilabs, and the Model Task Force Working Group. Many enhancements and features were made to the PT programs throughout the development process. The latest draft framework was tested using simple network setups. The results of those tests were shared with the FTA in November 2006, when the framework was formalized.
3. What are the key differences between this framework and the previous one?
It should be noted that other than the differences outlined here, the new framework is essentially the same as the previous one. A major goal was to maintain the existing framework elements to the extent possible.
The most obvious difference is that it uses the PT and FSUTMS-Voyager software instead of FSUTMS-Tranplan. PT uses a leg-based storage system, where a leg is defined by a boarding and alighting node. FSUTMS-Tranplan is uses a link-based storage system, where a link simply had to have two nodes. This subtle difference is the main reason for the re-evaluation of the previous framework; the link-based access and transfer connectors were incompatible with PT.
Other key differences include:
- Stronger integration with the highway network; transit-only links and station data are coded directly onto the highway network, which is now effectively a transportation network,
- Fixed-guideway (e.g., rail) stations are micro-coded, with separate nodes for bus and rail platforms,
- A new mode numbering system has been developed,
- The AUTOCON program has been revised to include station-specific costs in addition to drive-access time,
- Many areas will notice a new mode choice modeling structure,
- New mode choice coefficients and transit path-building weights,
- A new REWALK program that effectively replaces WALKCON, and
- A new transit assignment program TAREPORT that mimics FSUTMS-Tranplan's TADLOD and reporting procedures.
4. What documentation is available on this new framework?
In addition to this FAQ, there are several new documents related to this framework. All are available on FSUTMSOnline, specifically at https://www.fsutmsonline.net/index.php?/transit_modeling/ comments/new_fsutms_transit_modeling_framework/
There are two companion documents that summarize the new transit modeling system for FSUTMS-Voyager. The Theoretical Framework document describes the theoretical underpinnings and coordination between the modeling elements. It mentions some of the key features of PT and summarizes the rationale for some of the new procedures and practices. In contrast, the purpose of the Application Framework is to describe how the elements of the FSUTMS-Voyager Transit Model are applied in PT and FSUTMS-Voyager. It contains many of the details and specifics, including settings for many of the PT control statements and keywords.
There are documents of the three FORTRAN programs. Each describes the program's history and purpose, logic and input and output files. The format of the input and output files is also provided.
The workbook of slides from the June 2007 Transit Modeling Workshop are also available for download. This was the first workshop that detailed the new framework.
5. Are there any programs or routines available? If so, where?
There are several programs and routines available. All are available on FSUTMSOnline, specifically at https://www.fsutmsonline.net/index.php?/transit_modeling/ comments/new_fsutms_transit_modeling _framework/
While many of the traditional customized programs have been converted to FSUTMS-Voyager scripts, some programs had to be maintained and/or revised to address unique needs. Summary documentation has been created for each program that describes the program's history and purpose, logic and input and output files. The format of the input and output files is also provided. At this time, there are three customized programs:
- AUTOCON develops the drive-access connectors,
- REWALK coordinates the walk-access connectors generated by PT with the percent walk data produced by GIS procedures, and
- TAREPORT reads the PT-generated loaded link files and produces two transit assignment reports
It is hoped that these programs can be converted to scripts in the near future. Efforts are now underway to convert REWALK to a scripted application. AUTOCON and TAREPORT likely require additional enhancements to Voyager and/or PT software before they can be easily converted.
There are sample factor files and scripts for transit paths for almost all models. There is a set for Tier A areas, those with modest transit service, and a set for Tier B and C areas, which are more robust service.
There is also a full-fledged transit model setup for Olympus, FDOT's training model. It includes a sample setup for transit speeds, access connectors, paths/skims, mode choice and assignment.
6. What do I have to do (or what should I do) before implementing the new framework?
Zone sizes and connectors take on a heightened sensitivity with the conversion of Florida models to FSUTMS Cube-Voyager, as the Public Transport (PT) module strongly relies on a well-developed zone system with centroid connectors truly representative of access/egress capabilities. The new transit framework uses PT to generate all walk- and transfer-access connections (or access legs). Unlike its Tranplan-oriented predecessor, PT only uses the centroid connectors when generating the access legs. The new 1/2 mile maximum for walk-access effectively requires that zones served by transit need to have connectors less than 1/2-mile long. Zones with longer connectors will not be connected to transit, regardless of the proximity or frequency of the transit service. Consequently, it is recommended that all agencies perform a review of zone sizes and centroid connectors before actively migrating to the new transit framework.
Central Office is releasing a white paper on rules for subdividing TAZs in the very near future to provide insights on how best to subdivide zones.
7. How do I implement this framework if I am transitioning from FSUTMS-Tranplan?
It is difficult to provide an exact step-by-step approach because of the slight variations between all models. The following steps should be performed at a minimum:
- Review traffic analysis zone (TAZ) sizes and centroid connectors,
- Review all documentation on the new framework available at
- Convert the transit network. It may be desirable to tweak the coding to conform with PT,
- Make the necessary modifications to the transportation network,
- Develop new percent walk files using the new 1/2-mile standard,
- Develop Voyager procedures for computing transit speeds,
- Develop procedures for access connectors and apply the connector programs (i.e., REWALK and AUTOCON),
- Develop procedures for paths and skims,
- Make modifications to the mode choice model,
- Develop transit assignment procedures, and
- Calibrate and validate the transit model.
8. I've heard that some parts of the transit network need to be coded on the highway network? Could you explain what needs to be done?
Yes, there are several parts of the transit network that need to be coded onto the highway network, which is now called the transportation network since it incorporates both transit and highway elements. Transit-only links are coded directly on the transportation network. Previously, they were coded in a separate ASCII file and processed during the transit network building process. Information previously contained in the STATDATA file is now placed in node fields. Fixed-guideway stations will likely need to be micro-coded, requiring separate nodes for the different platforms and a connector link to join them.
9. What is station micro-coding? Why do why need to do it?
Station micro-coding is showing separate nodes for distinct vehicle platforms. The most common situation occurs at a rail (or some other type of fixed-guideway) station. The rail platform is typically separated from the bus boarding area. In many cases in Florida, the fixed-guideway platform is elevated while the bus boarding area is at the street-level.
Both boarding areas were coded at the same node in the previous framework (n.b., this was common practice nationwide for dozens of years). During the development of this framework, the Federal Transit Administration recommended that stations having distinct platform locations be represented as two different nodes connected by a link that represents the time it takes to transfer between the two platforms. The purpose is to represent all known path characteristics (transfer time in this case) on the network and the path/skim. Otherwise, the transfer time will manifest itself in the mode choice bias constants. These cannot reflect any known path characteristics, as they are intended to capture only those unobservable characteristics such as ride quality, safety/comfort, and perception of the system and/or mode.
10. Are there new auto-transit speed "curves" with the new framework?
The new framework does not specify new auto-transit speed relationships at this time. Recent data collected in Jacksonville and Tampa indicates that transit speeds are much faster in proportion to the auto speed than represented in the original curves. However, that data consists of records comparing time-of-day transit speeds to time-of-day auto speeds. This data cannot be applied directly to Florida models, as they relate time-of-day transit speeds to 24-hour auto speeds. While efforts are underway to assess the usefulness of the Jacksonville and Tampa data, it is recommended that more areas should be collect similar data before statewide recommendations can be finalized.
11. How is the new version of AUTOCON different the version I've been using in my model?
The new version of AUTOCON generally follows the same logic as previous versions. The biggest change is that the connector cost (i.e., time value of the connector) includes all station-specific characteristics in addition to the drive-access time. The cost includes station parking cost, station access time, origin terminal time, auto operating cost and drive-access time. In addition, all of these elements are weighted, reflecting their value in relation to transit run time.
Another change relates to the station range, the allowable distance that all potential centroids must meet. In previous versions, the program enacted a "hard" range. This meant that if a station range was 10 miles, centroids 9.9 miles away were considered candidates while centroids 10.1 miles away were dismissed. In alternative analyses and FTA user benefit analyses, it was possible to have a zone considered a candidate in one alternative and not one in another even though the differences in distance were trivial. This new version considers centroid beyond the range as viable candidates, but driving time outside the range is weighted much more heavily than driving time inside the range. This is essentially a continuous slope rather than the hard "cliff" in prior versions.
There are also several minor differences, such as reading the TRANSIT.MAS file (instead of PROFILE.MAS), an expanded modal priority structure and reading new percent walk files.
12. If I want to keep my existing mode choice model program, what changes need to be made to implement it in the new framework? I'd like to keep the changes to a minimum if possible.
All existing mode choice models in Florida use the short-/long-walk methodology used in the previous framework. Short-walk was defined as 1/3 of a mile and long-walk had a range up to one mile. This means that separate mode choice computations are performed for seven access markets (short-walk origin/short-walk destination, short/long, long/short, long/long, auto access/short, auto access/long and no access). The new framework uses a single walk area of 1/2 mile. It computes mode shares across three access categories (can walk, must drive and no access). The code will have to be modified to read the streamlined percent walk data (PCWALK), correctly execute computations across the three access categories, and report trips from those categories.
The new AUTOCON program incorporates all station-specific information on the connector, which was done originally to accommodate multi-pathing. In addition, all information on the connector is weighted to in-vehicle time. Mimicking the same functionality, many existing mode choice models perform a transit station lookup to apply the station-specific information (e.g., station parking cost and access time) to the utility equation for auto-access utilities. These models also determine the auto operating cost for the trip using the highway skims. These features cannot be used if the new AUTOCON program is being applied.
Consequently, a number of relatively small changes must be made to your existing mode choice model code. Drive-access time coefficients should be set to the transit run time coefficient as it is already reflected weighted disutility. All code related to adding station-specific data to the utilities should be commented out; otherwise the mode choice model will double-count station-specific attributes. The station parking costs on the auto-access connector reflect standard HBW and HBO calculations, which means they are divided by two to reflect half of the trip. These costs are typically full value for NHB trips, which may not have a "return" leg. The other half of the parking costs will have to be added to (technically subtracted from) the disutility for NHB trips. Since separate KNR connectors are not required as part of the new framework, an adjustment to the weighted station access time will have to be made for KNR utilities.
Some models have an additional 50% impedance factor for KNR auto-access time. This is impossible to exactly replicate with the new framework. It can be mimicked by multiplying the total auto-access cost by the same amount, although that would be a stronger penalty than applied previously. A better way is to develop separate KNR connectors. This is not currently available in the new AUTOCON program, although it may be in the near future.
Almost all Florida mode choice models assign the auto portion of drive-access transit trips. This was accomplished by performing the station look-up. Having the total cost on the connector makes this procedure prohibitive. However, a similar procedure can be easily designed in framework by developing a post-processing routine in Voyager that reads transit trip and station-to-station matrices.
The new framework specifies mode choice structures and coefficients. You may want to make changes as you transition to PT and Voyager. If you desire to maintain your existing coefficients, you need to make sure that the path weights are consistent with those coefficients. Also, please be careful about using the nesting coefficients if you are not using a similar nested structure.
There are other minor changes that can be made at your discretion. These include reading transit fares from the transit skim file instead of a separate file (FSUTMS-Tranplan required a separate fare file), expanding the number of transit skim tables read by the mode choice model, and reading the TRANSIT.MAS parameter file.
13. Who should I contact if I have further questions?
Please contact Mr. Yongqiang Wu of FDOT Systems Planning Office by phone at 850) 414-4931 or email at Yongqiang.Wu@dot.state.fl.us.