Web-Based Screening Tool for Shared-Use Rail Corridors (2014)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

1 Web-Based Screening Tool for Shared-Use Rail Corridors This research was motivated by the Passenger Rail Investment and Improvement Act of 2008, which instructs the Federal Railroad Administration (FRA) to seek partnerships between freight and passenger railroads with a view to developing new passenger rail services that would support a growing economy and help relieve highway congestion. Objective The objective of the research was to develop a Web-based tool to enable states and pas- senger rail operators to perform preliminary feasibility screening of proposed shared-use passenger and freight rail corridor projects. The goal of the tool was to assist in preliminary analysis as defined in FRA’s Rail Corridor Transportation Plans: A Guidance Manual (1). Research Approach The research reviewed rail corridor analysis methodologies for approaches that were suit- able for a preliminary analysis tool. The research examined data requirements and analyzed the potential gaps in data availability and strategies for bridging them. Following the gap analysis, the researchers prepared five candidate case studies, from which three were selected by the project panel. The team developed a tool design and implemented it along with a users manual. The three case studies were conducted using the tool. Summary of Findings Findings are summarized according to the major research headings of methodology, gap analysis, and case study. Methodology Findings • Parametric tools, while requiring minimal data, are not sufficiently robust for corridor screening assessment. • Optimization-based tools are overly complex for corridor screening. Issues relating to algorithm performance and efficiency, combined with the need to customize programming for each corridor, render tools of this type unsuitable. • The main advantage of topological approaches is their ability to identify directly the bottleneck section(s) of a rail line, pointing directly to the locations where infrastructure additions may be the most needed. S U M M A R Y

2• Probability-based delay equations tend to be too simplified to produce a credible corridor- specific screening assessment. • The approach of adding a siding wherever a conflict occurs is a reasonable first-cut assessment of infrastructure needs on light-density corridors. • The proposed conflict identification methodology is both quantitative and rigorous and is applicable to all corridors regardless of density. The methodology does not require an experienced rail analyst, and it qualifies as an effective element in a corridor screening tool. • Simulation is the key validator of a screening assessment. The data requirements for a simulation are the same as those of the conflict identification methodology. Given robust train movement and dispatching algorithms, simulation provides essential information regarding operational feasibility and, therefore is a critical component of the screening assessment. This capability is provided as a core feature of the Shared Use (SU) tool and has been demonstrated in the case studies. Gap Analysis Findings • Table 3-2 summarizes the availability of infrastructure data and their sources. • Table 3-4 summarizes the availability of traffic data and sources. • Unit cost data is available from other studies, but will require adjustments for inflation and regional conditions. Case Study Findings • Three case studies were conducted based on the panel’s selection from five candidate corridors. The three case studies were: Kansas City to St. Louis; Baltimore to Wilmington; and Chicago to Milwaukee. • Case Study 1: St. Louis to Kansas City – The conflict identifier (CI) successfully identified the same required infrastructure as did the detailed comparison analysis. This demonstrates the tool’s ability to perform as intended on a heavily used, shared freight corridor with difficult terrain and challenging operational constraints. – Simulations after improvement demonstrated that the proposed solution was feasible for expanded shared-use operations and warranted further study. • Case Study 2: Baltimore to Wilmington – This case study was undertaken as a “double-blind” exercise without a validation benchmark. For the “do minimum” case, the CI showed that existing operations can be handled over the existing infrastructure with minimal conflicts. – Simulation demonstrated that removing intercity passenger traffic freed sufficient capacity for round-the-clock freight operations. Findings warranted further study. • Case Study 3: Chicago to Milwaukee – The CI showed the same required infrastructure as the detailed comparison analysis. – Simulation demonstrated the feasibility of projected shared-use operations. Findings warranted further study. Highlights of the Shared Use (SU) Approach The Web-based screening tool named Shared Use (SU) is implemented to facilitate analy- sis workflows and in accordance with a design suited for implementation as a Web browser- based tool.

3 SU Workflows SU is designed for preliminary screening of proposed projects that introduce new passenger service to existing freight or shared-use corridors. The tool is intended to be used very early in the planning process, where it offers a rigorous, systematic approach for establishing a framework or starting point from which more detailed discussions and analyses can follow. The methodology is consistent with the requirements of the FRA Guidance Manual (1) and the analysis is limited by the level of data that is either publicly available or that can be obtained by state DOTs for screening capacity needs. A key consideration in the design of the tool was structuring it to accommodate a typical analyst’s workflows. Figure S-1 illustrates the SU tool workflow. These are described in the body of the report in Section 3.5.1. SU Approach The SU tool follows the overarching system architecture, or design approach, that is displayed in Figure S-2. The basic design has the user connect remotely over the Internet; the tool has four main components. These components are • Data development module, • Modes of use (module for submitting analysis), • Core analytic engine, and • Results review module. Figure S-1. SU workflows.

4WEB-BASED TOOL CORE ANALYTIC ENGINE Train Performance Calculator Traffic Control Model MODES OF USE CONFLICT IDENTIFIER SIMULATION DATA DEVELOPMENT Train Builder and Scheduler Other Data Developer Scenario Builder INTERNET Track Infrastructure Data Entry and Visualization RESULTS String Charts Speed/Performance Charts Feasibility Metrics Average train speed by type of train Average wait by type of train Percentage of trains meeting reliability criteria by type Other summary metrics Figure S-2. SU approach.

5 Web-Based Tool Implementation The Web-based tool was implemented on a Web content management system (CMS). A Web CMS is a bundled or stand-alone application to create, manage, store, and deploy content on Web pages. Web content includes text and embedded graphics, photos, video, audio, and code (e.g., for applications) that displays content or interacts with the user. A Web CMS may catalog and index content, select or assemble content at runtime, or deliver content to specific visitors in a requested way, such as other languages. Web CMSs usually allow client control over HTML-based content, files, documents, and Web hosting plans based on the system depth and the niche it serves. The Web CMS permits the integration of custom-designed components, which provide the SU functionality. User Interface The user interface is a standard Web page hosted on the FRA datacenter. From the home page, access to the system is limited to users who are registered and authorized by the system administrator. The home page is shown in Figure S-3. After login, users can access all of the system’s features through the main menu. The SU menu structure is shown in Figure S-4. SU includes a rich Internet application (RIA) called the Track Charting App that enables users to visualize and modify rail infrastructure data directly on a graphical user interface. A sample screen shot from the Track Charting App is shown in Figure S-5. Figure S-3. SU home page.

6Shared Use Menu Tab or Page Features Figure S-4. SU menu structure.

7 All of the features of the Web-based tool and their use are explained in the users manual available on the FRA website. Database The data for SU analyses, inputs, and outputs, are stored on the system database, which is implemented on an instance SQL Server. Users may choose to archive their data to a local computer and restore them to the system database for use with a future session with SU. Runtime Console Application After users have prepared their data for running an analysis on SU, they submit an analysis job to the SU job queue. A separate console application runs on the server that polls the database and job queue for submitted jobs and executes jobs based on submittal time (first submitted, first executed). The actual runtime logic for SU analyses is implemented in the console application. Figure S-5. SU Track Charting App.