0% found this document useful (0 votes)

224 views271 pages

FSP Manual

This document provides instructions for setting up and running the FSP and XFSP programs for analyzing traffic data. It discusses downloading and examining the car, loop, and incident data files. It describes the directory structure and file formats used as input for the programs. It also explains the run file parameters that are used to configure execution and provides examples of running the programs with different parameter settings.

Uploaded by

Zongru Zhan

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

224 views271 pages

FSP Manual

Uploaded by

Zongru Zhan

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 271

FSP for the FSP Project 1.

1 The Analysis Software

Karl Petty
FSP Project Department of Electrical Engineering and Computer Science University of California, Berkeley Berkeley, CA 94720 c 1994, Karl Petty Mailing for bug reports:
pettyk@eecs.berkeley.edu

This manual is for the FSP and XFSP programs June 4, 1995

Contents
1 Introduction 13 2 Setting Up And Running The fsp Program 17 2.1 Setting Up The fsp Program : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 17
2.2 Running The Program : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 21

3 Setting Up And Running The xfsp Program 23 3.1 Introduction To The xfsp Program : : : : : : : : : : : : : : : : : : : : : : : : : : 23 3.2 Support Software For The xfsp Program : : : : : : : : : : : : : : : : : : : : : : 23
3.3 Installing The Support Software : : : : : : : : : 3.3.1 Step 1: Creating The Directory Structure 3.3.2 Step 2: Downloading The Software : : : : 3.3.3 Step 3: Installing Tcl 7.3 : : : : : : : : : 3.3.4 Step 4: Installing Tk 3.6 : : : : : : : : : : 3.3.5 Step 5: Installing Expect 5 : : : : : : : : 3.3.6 Step 6: Finishing Up : : : : : : : : : : : : 3.4 Installing The xfsp Software : : : : : : : : : : : 3.5 Running The xfsp Software : : : : : : : : : : : : 3.5.1 The Layout Of The xfsp Window : : : : 3.5.2 Using The Fileselector : : : : : : : : : : : 3.5.3 Using Setup Files : : : : : : : : : : : : : : 3.5.4 Running The fsp Program : : : : : : : : 3.5.5 Using The xfspview Program : : : : : : 4.1 The Study : : : : : : : : : : : : : : : : : : : : : 4.2 Downloading The Data : : : : : : : : : : : : : 4.2.1 Downloading Via The World Wide Web 4.2.2 Size of the Data : : : : : : : : : : : : : 4.3 The Car Data : : : : : : : : : : : : : : : : : : : 4.4 The Loop Data : : : : : : : : : : : : : : : : : : 4.5 The Incident Data : : : : : : : : : : : : : : : : 3

: : : : : : : : : : : : : : : : : : : : :

25 26 26 27 28 28 29 29 31 32 32 33 33 34 37 37 40 40 41 45 48

4 The Data

: : : : : : :

CONTENTS
5.1 The Car Data : : : : : : : : : 5.1.1 Key Presses : : : : : : 5.1.2 Car Placement : : : : 5.1.3 Just Plain Bad : : : : 5.1.4 Car Position Plots : : 5.2 The Loop Data : : : : : : : : 5.2.1 Loop Data Drop Outs 5.2.2 Over/Under Counting 5.2.3 Bad Initialization : : : 5.2.4 Bad Traps : : : : : : : 5.3 The Incident Data : : : : : : 5.3.1 Bad Placement : : : : 5.3.2 Bad Duration : : : : :

5 Problems With The Data

: : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : :

55 55 56 57 57 58 58 61 63 63 64 64 68

6 Program Input: Directory Structure and File Formats

6.1 The Input Directory Structure : : : : : : : : : : : : : : : : : : : : 6.1.1 Car Input Directory Structure : : : : : : : : : : : : : : : : 6.1.2 Car Con guration File Formats : : : : : : : : : : : : : : : : 6.1.3 Loop Input Directory Structure : : : : : : : : : : : : : : : : 6.1.4 Loop Con guration File Formats : : : : : : : : : : : : : : : 6.1.5 Incident Input Directory Structure and Con guration Files 6.2 The Output Directory Structure : : : : : : : : : : : : : : : : : : : 6.2.1 Loop Output Directory Structure : : : : : : : : : : : : : : : The Basic Idea : : : : : : : : : How To Use The Parameters : Parameters To The Run le : : Default Parameters Values : : : Summary Of Parameter Values

72 72 73 74 75 78 79 79

7 Program Input: The Run le

7.1 7.2 7.3 7.4 7.5

: : : : :

: 81 : 81 : 82 : 109 : 109

8 Run le Parameters To xfsp Strings 121 8.1 xfsp Windows To Run le Parameters : : : : : : : : : : : : : : : : : : : : : : : : 121 9 Program Input: The Incident Filter 127
9.1 The Incident Filter Format : : : : : : : : : : : : : : : 9.2 Fields Of The Incident Filter : : : : : : : : : : : : : : 9.3 Incident Filter Examples : : : : : : : : : : : : : : : : : 9.3.1 Example 1: Examining Incident Fields : : : : : 9.3.2 Example 2: Accidents With Little Processing : 9.3.3 Example 3: Red Cars With Lots Of Processing 9.3.4 Example 4: Tow Truck Incidents : : : : : : : :

: : : : : : :

: 127 : 128 : 128 : 131 : 132 : 133 : 134

CONTENTS

10 Program Input: The Loop Detector Tests

10.1 Generating The Tests : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 139 10.2 Listing Of The Various Tests : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 143 10.3 The Default Values For The Loop Tests : : : : : : : : : : : : : : : : : : : : : : : 148 11.1 Generating The Loop Speeds : : : : : : : 11.2 Fixing The Loop Data : : : : : : : : : : : 11.2.1 The oop Files : : : : : : : : : : : 11.2.2 The gloop Files : : : : : : : : : : : 11.2.3 The hloop Files : : : : : : : : : : : 11.3 The Loop Delay Files : : : : : : : : : : : 11.3.1 The Run le Parameters Needed : : 11.3.2 Extra Loop Files : : : : : : : : : : 11.4 Fixing The Incident Data : : : : : : : : : 11.5 Finding The Delay For Each Incident : : : 11.5.1 Incident Delays By Distance : : : : 11.5.2 Incident Delays By Bounding Box 12.1 12.2 12.3 12.4 12.5 12.6 12.7

139

11 Program Input: Cross Data Analysis

: : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: 152 : 154 : 155 : 156 : 157 : 157 : 158 : 159 : 160 : 161 : 161 : 163 : 168 : 169 : 170 : 170 : 171 : 172 : 173 : 174 : 175 : 176 : 177 : 179 : 179 : 181 : 182 : 184 : 185 : 186 : 188 : 188 : 189 : 191

151

12 Examples With The Run le

General Parameters : : : : : : : : : : : : : : : : : : : : : : : : : : : : Example 1: Just Car Data : : : : : : : : : : : : : : : : : : : : : : : : : Example 2: More Car Data : : : : : : : : : : : : : : : : : : : : : : : : Example 3: Lots Of Car Data : : : : : : : : : : : : : : : : : : : : : : : Example 4: General Loop Data Example : : : : : : : : : : : : : : : : : Example 5: Complicated Loop Data Example : : : : : : : : : : : : : : Example 6: Computing The Delay WRT The Average : : : : : : : : : 12.7.1 The First Pass: Standard Values : : : : : : : : : : : : : : : : : 12.7.2 The Second Pass: Calculating The Delay : : : : : : : : : : : : 12.7.3 The Final Step: Moving The Files To A Safe Place : : : : : : : 12.8 Example 7: Generating The Contour Plots : : : : : : : : : : : : : : : 12.9 Example 8: Fixing The Incident Locations : : : : : : : : : : : : : : : : 12.9.1 Step 1: Generating The First Plot : : : : : : : : : : : : : : : : 12.9.2 Step 2: Generating The Location Fix File : : : : : : : : : : : : 12.9.3 Step 3: Adjusting The Incidents : : : : : : : : : : : : : : : : : 12.9.4 Step 4: Adjusting One Last Time : : : : : : : : : : : : : : : : : 12.10Example 9: Fixing The Incident Durations : : : : : : : : : : : : : : : 12.10.1Step 1: Using The Probe Data To Correct The Durations : : : 12.10.2Step 2: Using The Runtime File To Correct The Durations : : 12.11Example 10: Calculating The Incident Delay With Space-Time Boxes 12.11.1Step 1: Figuring Out The Bounding Boxes : : : : : : : : : : : 12.11.2Step 2: Incident Delays From The Bounding Boxes : : : : : : :

167

CONTENTS
13.1 GNUPLOT : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 193 13.2 XGRAPH: An Alternative : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 194 a 13.3 L TEX Tables : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 194 14.1 The Car Textual Output : : : : : : : : 14.1.1 The Key Error Report : : : : : 14.1.2 The Huge Car Error Report : : 14.1.3 The Medium Car Error Report 14.1.4 The Small Car Error Report : 14.2 The Car Graphical Output : : : : : : 14.2.1 The Graphs For Each Loop : : 14.2.2 The Graphs For Each Shift : : 14.3 The Car Plots : : : : : : : : : : : : : : 15.1 15.2 15.3 15.4

13 Program Output: How To View It 14 Program Output: The Car Data

193 197

: : : : : : : : :

: : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : :

: 197 : 198 : 199 : 200 : 200 : 200 : 201 : 206 : 207 : 213 : 217 : 217 : 222 : 223 : 225 : 226 : 227 : 229 : 230 : 231 : 232 : 233 : 236 : 237 : 242 : 242 : 244 : 247

15 Program Output: The Loop Data

The Loop Textual Output : : : : : : : : : The Loop Text Reports Summary : : : : The Basic Data Set : : : : : : : : : : : : : The Calculated Data Set : : : : : : : : : : 15.4.1 The Loop Delay And Density Files 15.4.2 The Loop Emission Files : : : : : 15.4.3 The Aggregate Loop Files : : : : : 15.5 The Loop Plots : : : : : : : : : : : : : : :

213

16 Program Output: The Incident and Cross Data Analysis

16.1 Quick Overview Of The Incident And Analysis Output : : : : 16.2 Textual Output : : : : : : : : : : : : : : : : : : : : : : : : : : 16.2.1 The Base Case Output : : : : : : : : : : : : : : : : : : 16.2.2 The Raw Incident Output : : : : : : : : : : : : : : : : 16.2.3 Incident Database - Probe Vehicle Correlation Results 16.2.4 The Incident Duration Fix Output : : : : : : : : : : : 16.2.5 The Finished Incident Output : : : : : : : : : : : : : : 16.3 Graphical Output : : : : : : : : : : : : : : : : : : : : : : : : : 16.3.1 The Incident Plots : : : : : : : : : : : : : : : : : : : : 16.3.2 The Correlation Plots : : : : : : : : : : : : : : : : : : 16.3.3 The Contour Plots : : : : : : : : : : : : : : : : : : : :

229

17 A Larger Picture: The Whole FSP Data Flow A Frequently Asked Questions and Warnings
A.1 A.2 A.3 A.4 General : : : : : : : : : The Loop Data : : : : : The Probe Vehicle Data The Incident Database :

: : : :

: 255 : 256 : 261 : 262

251 255

CONTENTS

B Changes From Version 1.0 to 1.1

265

CONTENTS

List of Figures
1.1 Basic Program Structure. : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 14 1.2 Basic Program Structure with Chapters. : : : : : : : : : : : : : : : : : : : : : : : 15 3.1 3.2 3.3 3.4 3.5 3.6 4.1 4.2 4.3 4.4 4.5 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 6.1 6.2 6.3 6.4 Relationship Between fsp and xfsp Programs. Main xfsp Window. : : : : : : : : : : : : : : : The xfsp File Selector Window. : : : : : : : : The xfsp Run Window. : : : : : : : : : : : : : The xfsp Output Window. : : : : : : : : : : : The xfspview Window. : : : : : : : : : : : : : The FSP Study Section. : : : : : : : : : : FTP Directory Structure On www-path. Basic Keys Pressed During First Set. : : : Basic Keys Pressed During Second Set. : Basic Calculation of Car Speeds. : : : : : Basic Keys Pressed During Second Set. Basic Car Position Plot That Drifts. : : Loop Data Dropout. : : : : : : : : : : : Missing Detector. : : : : : : : : : : : : : Detector Current Level. : : : : : : : : : Basic Incident Plot. : : : : : : : : : : : Car Trajectories. : : : : : : : : : : : : : Correlation Plots. : : : : : : : : : : : : : Fixed Incident Placement. : : : : : : : : Actual Incident and Witnessed Incident. Incorrect Incident Duration Fix. : : : : Input FSP Directory Structure. : : Car Input Directory Structure. : : Loop Input Directory Structure. : Loop Output Directory Structure.

: : : : 7.1 Basic Incident Plot. : : : : : : : : : 10.1 High Speed Test. : : : : : : : : : : : 10.2 Cross Lane Test. : : : : : : : : : : :

: : : : : : :
9

: : : : : : :

: : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: 24 : 31 : 33 : 34 : 35 : 35 : 38 : 39 : 42 : 43 : 46 : 56 : 58 : 59 : 60 : 62 : 65 : 66 : 66 : 67 : 69 : 70 : 72 : 73 : 75 : 80 : 108 : 140 : 141

10 11.1 11.2 11.3 11.4 11.5 11.6 11.7 11.8 12.1 12.2 12.3 Big Picture For FSP Program. : : : Fixing The Loop Data. : : : : : : : : Delay Calculation wrt A Constant. : Delay Calculation wrt The Average. Data Flow For Fixing The Incidents. Processing The Incidents. : : : : : : Incident At One Time Slice. : : : : : Density Contour With Incident. : : :

LIST OF FIGURES
10.3 The Loop Detectors In The Freeway. : : : : : : : : : : : : : : : : : : : : : : : : : 142

14.1 14.2 14.3 14.4 14.5 14.6 14.7 14.8 14.9 Travel Times With Gore And INRAD Points. Gnuplot le: stimes.gtv

: : : : : : : : Incident Database-Probe Vehicle Correlation Plot. : Correlation Plot With Fixed Incident Locations. : : Delay Contour Plot. : : : : : : : : : : : : : : : : : : Car File Name Extensions. : : : : : : : : : : : : : : Car Trajectory (X-Y). Gnuplot le: c1loop2.vxy : : Car Trajectory (time vs. distance). Gnuplot le: c1loop2.vtd : Car Trajectory (speed vs. distance). Gnuplot le: c1loop2.vsd : Car Trajectory (speed vs. time). Gnuplot le: c1loop2.vst : : : Travel Times With INRAD Points. Gnuplot le: inrad.gtv : : : Travel Times With nbd Gore Points. Gnuplot le: ngore.gtv : Travel Times With sbd Gore Points. Gnuplot le: sgore.gtv : :

: : : : : : : :

: : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : :

15.1 Cumulative Loop Delay. : : : : : : : : : : : : : : : : : : : : : : : : : : 15.2 Loop Delay Table. : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 16.1 Data Flow For Fixing The Incidents. : : : : 16.2 Generating The Incident Delays. : : : : : : 16.3 Histogram Of The Number Of Incidents. : : 16.4 Histogram Of The Percentage Of Incidents. 16.5 Cumulative Distribution Plot. : : : : : : : : 16.6 Incident Delay Versus Duration. : : : : : : 16.7 Incident Correlation Plot. : : : : : : : : : : 16.8 Contour Plot Of Delay. : : : : : : : : : : : : 16.9 Contour Plot Of Density. : : : : : : : : : : 16.10Contour Plot Of Di erential Density. : : : :

: : : : : : : : : : 17.1 The Larger Picture. : : : : : : : : : : : : : :

: : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: 151 : 155 : 159 : 160 : 161 : 162 : 163 : 164 : 181 : 183 : 189 : 203 : 208 : 208 : 209 : 209 : 210 : 210 : 211 : 211 : 224 : 225 : 230 : 231 : 243 : 244 : 245 : 246 : 247 : 249 : 250 : 250 : 252

List of Tables
3.1 Anonymous ftp sites for the software packages. : : : : : : : : : : : : : : : : : : : 27 4.1 Size of data sets (in megabyes). : : : : : : : : : : : : : : : : : : : : : : : : : : : : 40 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10 7.11 7.12 7.13 7.14 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9 8.10 8.11 9.1 9.2 10.1 10.2

: : : : : : : : : : : : : : : : : : : : : : : Run le parameters in the Incident Output/Processing window. : Run le parameters in the Loop Output/Processing window. : : : Some eld descriptors for incident lter. : : : : : : : : : : : : : : : : More eld descriptors for incident lter. : : : : : : : : : : : : : : : : Test parameter defaults. : : : : : : : : : : : : : : : : : : : : : : : : : Auxiliary parameter defaults. : : : : : : : : : : : : : : : : : : : : : :
11

: : : : : : : : : : : : : : Run le parameters to xfsp location. : : : : : : : : : : : : : : : More run le parameters to xfsp location. : : : : : : : : : : : : Run le parameters in the Car Output/Processing window. : Run le parameters in the Correlate Data window. : : : : : : Run le parameters in the Emissions/Delays window. : : : : Run le parameters in the Fix Inc Data window. : : : : : : : Run le parameters in the Fix Loop Data window. : : : : : : Run le parameters in the General Options window. : : : : : Run le parameters in the Incident Delays window. : : : : : :

Default values for the main parameters. : : : : : : : : : : : : Default values for the car parameters. : : : : : : : : : : : : : Default values for the loop parameters. : : : : : : : : : : : : : Default values for the incident parameters. : : : : : : : : : : : Default values for the analysis parameters. : : : : : : : : : : : Summary of main parameters. : : : : : : : : : : : : : : : : : : Summary of car parameters with no pre-de ned options. : : : Summary of loop parameters with no pre-de ned options. : : Summary of incident parameters with no pre-de ned options. Summary of pre-de ned car parameters. : : : : : : : : : : : : Summary of pre-de ned loop parameters. : : : : : : : : : : : Summary of more pre-de ned loop parameters. : : : : : : : : Summary of pre-de ned incident parameters. : : : : : : : : : Summary of pre-de ned analysis parameters. : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: 110 : 110 : 111 : 112 : 112 : 113 : 113 : 114 : 115 : 116 : 117 : 118 : 119 : 120 : 122 : 123 : 124 : 124 : 124 : 124 : 125 : 125 : 125 : 125 : 126 : 129 : 130 : 149 : 149

LIST OF TABLES
10.3 Main parameters and error entries. : : : : : : : : : : : : : : : : : : : : : : : : : : 150 15.1 Summary of loop output text les. : : : : : : : : : : : : : : : : : : : : : : : : : : 217 15.2 Loop plots. : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 228 A.1 Travel Distances (in feet). : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 262

Chapter 1

Introduction
This manual is the reference manual for the fsp and xfsp programs. The fsp program is a software tool used to interrogate the data that was collected during the Freeway Service Patrol Evaluation Project. This program will perform diagnostics on the data, generate error reports, and make plots of various pieces of data. The program takes as it's input arguments a le that we shall call a run le, an incident lter le, and an incident run number. The run le contains all of the commands that the fsp program needs to run. The incident lter tells the program which incidents to lter out of the incident database and the incident run number is just an index for the output les. The xfsp program is a graphical user interface to the fsp program that was written in Tcl/Tk 1] and Expect 2]. This program allows the user to generate the run le and the incident lter by clicking on various buttons and widgets with the mouse. Since the xfsp program is just a graphical user interface to the fsp program this manual will concentrate on explaining the di erent types of analysis that the fsp program will perform. The xfsp program is described in more detail in Chapter 3. The fsp program generates quite a few di erent types of output. If you were to run the program on a complete data set the program would take about 12 hours and could possibly generate up to 8000 les. As a result, a large portion of the manual is going to be devoted to the interpretation of the various output les. A summary of the various types of output les and plots is given below: Loop Data: { Speed vs. Time plots { Counts vs. Time plots { Occupancy vs. Time plots { Delay (v-hr) vs. Time plots { Delay tables { Text reports of the data { Error reports on the data { Reports of dropout times Car Data: 13

CHAPTER 1. INTRODUCTION
Runfile Error Reports Incident Filter The fsp program Configuration Files Data Plots

Data Analysis Data (Car, Loop, Incident)

Figure 1.1: Basic Program Structure.

{ { { { { { {

Latitude vs. Longitude plots of car trajectory Speed vs. Time plots of car trajectory Distance vs. Time plots of car trajectory Speed vs. Distance plots of car trajectory Link Travel Time vs. Starting Time Plots of GPS data Driver evaluations

Incident Data:

{ Histograms of incident duration { Cumulative distribution of incident duration

Data Analysis:

{ { { {

Delay per incident Plot of delay per incident duration Plots of correlation between car and incident data Contour plots of delay on the freeway

Although this may seem too much to have to deal with, hopefully this manual will make everything seem clear. Basically the whole system looks like Figure 1.1. The program takes as input a run le, an incident lter le, various con guration les, and some data. It generates as output

Runfile Chapters 7, 8, 10, 12 Error Reports Chapters 13, 14, 15 Incident Filter Chapter 9 The fsp program Chapters 2, 3 Configuration Files Chapter 6 Data Analysis Chapter 16 Data Plots Chapters 13, 14, 15

Data (Car, Loop, Incident) Chapter 4, 5

Figure 1.2: Basic Program Structure with Chapters. various error reports, graphs, and tables. This manual is an attempt to describe in detail all of the various boxes listed in Figure 1.1. The chapters in this manual almost follow the boxes in Figure 1.1. Chapter 2 deals with how to setup the fsp program and Chapter 3 deals with how to setup the xfsp program. Chapter 4 talks about the data that we collect during the course of the experiment and Chapter 5 talks about the problems associated with the data. Chapter 6 describes how the fsp program expects the data to be stored on the system. Chapters 7, 8, 10, and 11 discuss the di erent parameters that can be set in the run le and Chapter 9 explains how to generate incident lters. In terms of program output, Chapter 13 explains the basics of how to view the output and where you can expect to nd it. Chapters 14, 15 explain the various types of output that are generated from the loop and car data sets. Chapter 16 explains the output that is generated from the cross data analysis. Finally, Chapter 17 talks about how the fsp program ts into a larger picture. With this in mind I would like to relabel my diagram of the basic program structure to include the chapter numbers in the appropriate boxes. I have done this in Figure 1.2. During the course of the Freeway Service Patrol there turned out to be a need to have more detailed data collection from the cars. What this basically means is that the format of the data from the cars changed in the middle of the experiment. I have pointed out in the manual where this can cause problems. Although I wrote the fsp program, I never could have done it without the help of quite a few people. Probably the most important is Leon Chen. He wrote the code that reads in the binary loop data and converts it to an understandable format. The routines that process the loop data still use his code as a foundation. Kumud Sanwal wrote the routines to do the consistency x on the loop data and part of this documentation was written by him as well. Hisham Noeimi and Dan Rydzewski came up with the format of the incident database which plays a big part in fsp program. They also had the thankless job of collecting all of the data.

CHAPTER 1. INTRODUCTION

Dr. Alex Skabardonis managed the project and wrote the nal report. I would also like to acknowledge my advisor Professor Pravin Varaiya for his continuing support and many helpful suggestions. If you are looking for a summary of the results of the Freeway Service Patrol Evaluation Project then you should consult 3]. Please note that this software is currently in ux. Hence, the manual is not quite nished yet. There are bound to be typos, bad grammar, and even incorrect instructions. If you nd that something doesn't work then please send me email at pettyk@eclair.eecs.berkeley.edu. I'm not guaranteeing that I'll be respond - it's just that it would be nice to know if there were any bugs.

Chapter 2

Setting Up And Running The fsp Program

The fsp program is rather large and complex. There are quite a few input les that need to be placed in the right spots, and quite a few input directories that need to be created. I have outlined the steps below to setup the fsp program, create the directories and nally to compile and execute the software. The installation procedure for the xfsp program is quite a bit harder than for the fsp program. As a result, all of Chapter 3 is devoted to installing and running the xfsp program. The steps to generating the fsp code and running it are pretty straight forward: 1. Download the software. 2. Compile the program using the included make le. 3. Install the con guration les using the included make le. 4. Install some data. 5. Make a run le. 6. Make an incident lter. 7. Run it. In this chapter we will talk about the rst 3 items in this list. The fourth item, installing some data, is discussed in Chapter 4, and the fth and sixth items, making a run le and an incident lter, are discussed in Chapters 7, 9, and 10.

2.1 Setting Up The fsp Program

Downloading the software is pretty straight forward. You simply need to download one le from the the software server at Berkeley. This is done via a mechanism called anonymous ftp. To use this simply type the following command: 17

CHAPTER 2. SETTING UP AND RUNNING THE FSP PROGRAM

ftp www-path.eecs.berkeley.edu

When the machine prompts you for a login name type in the word \anonymous." When you are prompted for a password type in your email address like: \me@some.machine.somewhere." This will let you in. I would suggested that you download any les named README and look at those rst. The fsp software package is located under /pub/PATH/FSP/Packages/fsp.1.1.tar.Z. You should download this by rst changing to that directory and then typing the command:
get fsp.1.1.tar.Z

This will download the le from the machine at Berkeley to your local machine. The way that the fsp program is distributed is in a compressed tar le. The le, on your machine, should look something like this:
clair 1: ls fsp.1.1.tar.Z

To unpack the data simply type the following command:

clair 2: uncompress fsp.1.1.tar.Z

This will create a le called fsp.1.1.tar which you then need to \untar" with the following command:
clair 3: tar xvf fsp.1.1.tar

This last command will create a directory on your system named fsp. This directory will be referred to as the main fsp directory. Note that if you already have a directory named fsp then it might be overwritten by the tar command. A listing of the directory should look something like this:
clair 4: cd fsp clair 5: ls Makefile Set1 README.DOC Set2 fsp_src manual xfsp_src xfspview_src

This directory has the following set of subdirectories: 1. 2. 3. 4. 5. 6. Directory of source les for the fsp program (fsp src). Directory of source les for the xfsp program (xfsp src). Directory of source les for the xfspview program (xfspview src). Directory of con guration les for the before data set (Set1). Directory of con guration les for the after data set (Set2). Directory holding this manual (manual).

2.1. SETTING UP THE FSP PROGRAM

The directory will also include a make le named Make le and a documentation le named README.DOC. In order to compile the fsp program you need to do the follow steps: 1. Figure out where you want to place the data. This will be referred to by its make le name, FSP_DATA_DIR (for the fsp data directory). 2. Manually create this directory. 3. Edit the make le and follow the instructions in there. You will need to set the value of FSP_DATA_DIR to be the name of the directory that you just created. 4. Compile the fsp program by typing in the main directory:
clair 6: make fsp

This will make the fsp program. Note that you don't have to change into the fsp src directory for this to work - this should be done from the main fsp directory. You should see something like the following output:
clair 6: make fsp cc -g -c fsp.c cc -g -c compassc.c cc -g -c cparsec.c cc -g -c fsp_util.c cc -g -c makeprnc.c cc -g -c congpsc.c cc -g -c log_170c.c cc -g -c log_stat.c cc -g -c log_fsp.c cc -g -c log_util.c cc -g -c log_flow_plot.c cc -g -c inradc.c cc -g -c fsp_calc.c cc -g -c loop_util.c cc -g -c inc_util.c cc -g -c inc_pos.c cc -g -c inc_print.c cc -g -c fsp_neural.c cc -g -c fsp_mkavg.c cc -g -c fsp_dir.c cc -o fsp -g fsp.o compassc.o cparsec.o fsp_util.o makeprnc.o congpsc.o log_170c.o log_stat.o log_fsp.o log_util.o log_flow_plot.o inradc.o fsp_calc.o loop_util.o inc_util.o inc_pos.o inc_print.o fsp_neural.o fsp_mkavg.o fsp_dir.o -lm chmod ugo+rx fsp

CHAPTER 2. SETTING UP AND RUNNING THE FSP PROGRAM

If this is not what happens and the fsp executable program has not been created then make sure that all of the libraries are in the appropriate place, that all the include les are around, and that the source les are there as well. If you still can't get it to compile then track down a hacker and ask them. 5. To install the con guration les type:
clair 7: make set1 or clair 7: make set2

The rst thing that this will do is to create all of the subdirectories that you will need to store the data. For an explanation of the various directories and where the data should be placed see Chapter 4. This command will also copy all of the les from the various con guration directories into the appropriate spots under the FSP_DATA_DIR. Note that this will overwrite any con guration les that you already have in these directories. If you don't want to run the install portion of the make program then that is ne, but you'll have to manually copy the con guration les to their appropriate place yourself because the fsp program expects them to be there. For example, if the value of FSP_DATA_DIR is /home/clair0/PATH/FSP/Temp/kp1 then the output of the \make set1" command should be something like this:
clair 8: make set1 Making main directories: Making Making Making Making directory directory directory directory /home/clair0/PATH/FSP/Temp/kp1/Loopdata /home/clair0/PATH/FSP/Temp/kp1/Cardata /home/clair0/PATH/FSP/Temp/kp1/Incidents /home/clair0/PATH/FSP/Temp/kp1/Runfiles

Installing configuration files: Installing files from loop_config Making loop data subdirs... Copying loop configuration files... Installing files from car_config Making car data subdirs... Copying car configuration files... Installing files from inc_config Copying incident configuration files... Installing files from runfile_config

2.2. RUNNING THE PROGRAM

Copying runfile example files... Done

6. Next, you need to install the fsp software. Most people like to have all of the executable programs in a few locations on their system. These are usually /bin or /usr/local/bin. On step 9 in the make le there is a variable named DEST that you can de ne as the destination for the fsp executable. Once you have set the variable DEST in the make le, to install the fsp software you simply type:
make install_fsp

This will copy the program over from the source directory to the destination directory. If you don't want to install the fsp program in some common directory but instead wish to leave the program in the source directory then that is ne but you'll need to set your path such that you can nd the fsp program. 7. Note that the installation procedure for the xfsp program is given in Chapter 3.

2.2 Running The Program

Once you have complied the program, installed the con guration les, and installed some data then you can start running the program. For an explanation of how to install some data see Chapter 4. There are a few things to note: You can run the program from anywhere on your system (as long as you have your path set correctly) and it should still put the data in the correct spot. If you halt the program, by typing control-c, you might see weird les lying around. If the program exits normally then these les are deleted, but if you halt it then it won't get a chance to delete them. You can just delete them yourself or you can wait until the program is run again and it will delete them when it exits normally. These les are named garbage.raw. You need to specify on the command line the name of the run le, the name of the incident lter, and a run number. The run number is used to name, or index, some of the output les. If you want to know more about the run le then refer to Chapter 7. If you want to run through the loop data then that takes the longest amount of time. To run the program simply type:
clair 9: fsp my.runfile my.inc.filter 0

(or whatever your run le and incident lter are called). I usually like to run the program in the main data directory. On my system this would be the directory: /home/clair0/PATH/FSP/Set2.

CHAPTER 2. SETTING UP AND RUNNING THE FSP PROGRAM

Chapter 3

Setting Up And Running The xfsp Program

The xfsp program is a graphical user interface to the fsp program. It will allow you to create the run le and the incident lter that the fsp program requires by pointing and clicking on various buttons and widgets with the mouse. It will also collect the output for you and display it in a window on the screen. There is an extensive help system within xfsp that should allow the user to control the fsp program without much need for this manual. This chapter probably should have been a little bit later in the manual because it assumes that you know something about the way the fsp program works. You can probably skip most parts of this chapter at rst and then come back to them later. The part that you should probably read is the section on installing the xfsp program.

3.1 Introduction To The xfsp Program

The xfsp program does something really simple: it allows the user to generate a run le and an incident lter for the fsp program. Once the run le and the incident lter have been created, the xfsp program will execute the fsp program, collect the output and then display it on the screen. One can think of the xfsp program as being a \wrapper" for the fsp program: the fsp program is what does all of the processing work and the xfsp program is what deals with the user. One way to view this graphically is in Figure 3.1. Figure 3.1 shows the xfsp program being in control of the fsp program: the xfsp program tells the fsp program what to do and then reads the output back from it. On the same gure is another program named xfspview. Xfspview is a program that allows the user to browse through the output of the fsp program by simply clicking on buttons. The xfsp program starts up the xfspview program every time that it runs the fsp program. The xfsp and xfspview programs are what the normal user will be using.

3.2 Support Software For The xfsp Program

The xfsp and xfspview programs were written on top of two di erent software tools: Tcl/Tk, that was written by John Ousterhout at the University of California at Berkeley 1], and Expect,

CHAPTER 3. SETTING UP AND RUNNING THE XFSP PROGRAM

xfsp program

xfspview program fsp program

FSP Data Set

FSP Output

Figure 3.1: Relationship Between fsp and xfsp Programs. that was written by Don Libes at the National Institute of Standards and Technology 2]. Tcl/Tk is a very powerful command language that lets you manipulate graphical objects like windows, buttons, sliderbars, etc. Expect is also a command language that is built on top of Tcl/Tk that allows the xfsp script to control the fsp program. In order to run the xfsp program you need to have Tcl/Tk and Expect on your system. A list of the software packages that you need to download or already have installed is given below:

Tcl7.3 This is the \Tool Command Language" that is a simple script writing language for
controlling and extending applications. It is one half of the Tcl/Tk package that is used to generate the graphical user interface (GUI) that the user will interact with. objects in X to create really nice graphical user interfaces. This is the second half of the Tcl/Tk package. us to start up a program in the background and then collect it's output to a window. We will use this feature when the xfsp program starts up the fsp program. It is built on top of Tcl/Tk and should already be available on most systems in the form of the program called expectk.

Tk3.6 This is a toolkit for the X Window System. This allows you to manipulate various

Expect 5 This is a program that allows scripts to interact with other programs. This will allow

xgraph and gnuplot (version 3.5) Xgraph and gnuplot are two standard pieces of software
on any Unix system. Xgraph comes with the X Window System distribution which is now the windowing standard on workstations. Gnuplot is a plotting program that comes with GNU software. These two programs are used by the xfsp and xfspview programs to generate plots and graphs. The fsp program actually generates les that can be read

3.3. INSTALLING THE SUPPORT SOFTWARE

directly into gnuplot. Since these two pieces of software should be on your system already this chapter will not discuss installing them. If you have access to the Internet then you can download these programs via anonymous ftp from many di erent sites around the country. The software packages are also located on the le server at UC Berkeley along with the fsp code so that you can download them easily. An important thing to note about all of these programs is that they are free and they are probably installed on your system already. If they aren't then there are steps below which you can follow to download and install these programs.

3.3 Installing The Support Software

Since there are a few di erent software packages, and the installation procedure can be a little confusing, the following discussion is provided to assist the user. This section will deal speci cally with installing the support software for the xfsp program. Section 3.4 will deal with installing the xfsp program itself. The most important thing that you can do at this point is to check and see if Tcl/Tk and/or Expect are already on your system. Speci cally what we are looking for is the program called expectk. This is a version of Expect that was built with the Tcl/Tk support included. If this program is on your system them you can skip all the way to Section 3.4 and install the xfsp program. To nd out if you have the expectk program on your system can type the following:
pettyk 1: which expectk /usr/sww/bin/expectk

This tells me that the program expectk is located in /usr/sww/bin/expectk. If you type this command and it says something else about not being able to nd the program then you should talk to your system administrator and see if it's been stored in an odd place. If you don't have this program installed, then you need to download and install the programs yourself. An overview of the steps that you need to take to install the support software are as follows: 1. Download Tcl7.3, compile and install. 2. Download Tk3.6, compile and install. 3. Download Expect 5.16, compile and install. Installing these packages isn't that hard. They were designed to be used by a whole variety of people and machine types so they are extremely easy to use. For the most part, you will only have to type three commands to completely compile and install each packages. The nal goal of installing the software packages is a program called expectk. This is a shell that the xfsp program will call to interpret it's commands.

CHAPTER 3. SETTING UP AND RUNNING THE XFSP PROGRAM

3.3.1 Step 1: Creating The Directory Structure

The hardest part is guring out where to place the packages in your directory structure. If you are installing the software as a system administrator then you will probably place the packages in /usr/tools or /usr/local. In that case you can probably gure out how to set up the links yourself so I won't tell you how to do this. The case that I will explain is when you aren't the system administrator. In that case, you will want to create a directory to hold all of the packages including the fsp package. It is very important that all of the packages reside in the same directory. The directory that I have chosen for this example is /home/clair1/FSP. Note that you will need approximately 32 megabytes just to hold the software packages. You will also need to gure out where the executable les and libraries will reside. Once again, if you are the system administrator then there are a few obvious places for these les like /usr/local/{bin,lib}. But if you aren't the system administrator then I would recommend that you create the appropriate directories to hold these les in the current directory. In my case, the correct directory is /home/clair1/FSP. So in this directory I will create four subdirectories called: bin, lib, include and man with the following mkdir command:
clair 1: pwd /home/clair1/FSP clair 2: mkdir bin lib include man clair 3: ls bin include lib

man

These will be the directories that will hold the executables, libraries and manual pages.

3.3.2 Step 2: Downloading The Software

Table 3.1 gives a list of where you can look to nd the various software packages. Note that you can also download the software from the le server that contains the fsp and xfsp code which is currently www-path.eecs.berkeley.edu. To download software via anonymous ftp you only need to ftp to the site and then give your login name as \anonymous." When the system prompts you for a password simply type in your e-mail address. Once the software has been downloaded to the desired directory your listing should look like the following:
clair 4: pwd /home/clair1/FSP clair 5: ls bin expect.tar.Z

fsp.1.1.tar.Z include

lib man

tcl7.3.tar.Z tk3.6.tar.Z

At this point you should uncompress and untar all of the les. This is done by using the following commands:

3.3. INSTALLING THE SUPPORT SOFTWARE

Software package Anonymous ftp site Tcl7.3 ftp.cs.berkeley.edu ftp.neosoft.com ftp.uu.net www-path.eecs.berkeley.edu Tk3.6 ftp.cs.berkeley.edu ftp.neosoft.com ftp.uu.net www-path.eecs.berkeley.edu Expect 5 ftp.cme.nist.gov www-path.eecs.berkeley.edu fsp www-path.eecs.berkeley.edu Study Area Map www-path.eecs.berkeley.edu

27 Package path and name1 /ucb/tcl/tcl7.3.tar.Z /pub/tcl/distrib/tcl7.3.tar.gz /languages/tcl/tcl7.3.tar.Z /pub/PATH/FSP/Packages/tcl7.3.tar.Z /ucb/tcl/tk3.6.tar.Z /pub/tcl/distrib/tk3.6.tar.gz /languages/tcl/tk3.6.tar.Z /pub/PATH/FSP/Packages/tk3.6.tar.Z /pub/expect/expect.tar.Z /pub/PATH/FSP/Packages/expect.tar.Z /pub/PATH/FSP/Packages/fsp.1.1.tar.Z /pub/PATH/FSP/Packages/freeway.ps

Table 3.1: Anonymous ftp sites for the software packages.

uncompress expect.tar.Z tar xvf expect.tar

on each software package. After you have untar'ed the packages you can delete the tar les themselves because they are just wasting disk space. The steps for installing all of these packages is going to be just about the same: 1. cd into the package directory. 2. Read the documentation le (README or INSTALL). 3. Follow the instructions. If you want to skip reading the documentation and just trust what I tell you then it should save you a lot of time. Everything that I tell you should work just ne, but if something goes wrong then you'll have to refer to their notes to correct the problem. The generic steps that you need to follow to install these, and quite a few other, packages are: 1. Run the con gure program. 2. Run the make program. 3. Run the make program with the install option. One nice feature that all of the software packages come with is a program called con gure. This program will look at your system and gure out where all of your les are located and it will gure out what needs to be done to compile programs on your machine. This simpli es your job quite a bit. The only thing that you need to tell the con gure program is where the executable and library directories (bin and lib) are located as well as the data and manual directories (include and man). In my directory structure, and hopefully in yours as well, these are both the same: /home/clair1/FSP. The complete command looks like this:

3.3.3 Step 3: Installing Tcl 7.3

CHAPTER 3. SETTING UP AND RUNNING THE XFSP PROGRAM

./configure --prefix=/home/clair1/FSP --exec_prefix=/home/clair1/FSP

Note that you need to put the ./ before the con gure program so that you will be sure that you are running the local version and not the system version. Also note that you have to be in the Tcl directory to run this and the following commands. This will generate a lot of uninteresting output that you can just ignore. Once it is done you should attempt to compile the Tcl package by typing:
make

Finally, if this succeeds then you should install the package by typing:
make install

Once this step has completed you are done installing the Tcl package. If any of these steps don't succeed then you should examine the output and attempt to x it yourself. If that fails then nd somebody that knows about make les and ask them.

3.3.4 Step 4: Installing Tk 3.6

The installation for this package should be the same as for the Tcl package. Just cd into the tk3.6 directory and type the following commands:
./configure --prefix=/home/clair1/FSP --exec_prefix=/home/clair1/FSP make make install

These steps should generate a lot of output that you can just ignore. If the installation of the Tcl 7.3 package came o without a hitch then this package should be just as easy.

3.3.5 Step 5: Installing Expect 5

The installation for this package should be the same as for the Tcl package. Just cd into the expect-5.16 directory and type the following commands:
./configure --prefix=/home/clair1/FSP --exec_prefix=/home/clair1/FSP make make install

If the installation of the Tcl 7.3 package came o without a hitch then this package should be just as easy.

3.4. INSTALLING THE XFSP SOFTWARE

3.3.6 Step 6: Finishing Up

Once the software packages have been installed you can delete all of the intermediate les that were created by the various installation procedures. This is done by using the following command in each one of the package directories:
make clean

This will delete all of the les that you don't need. In order to use the Tcl/Tk packages you need to set a few environment variables. These environment variables tell the Tcl/Tk programs where they can nd the support programs that they need to run properly. You will notice that when you installed Extended Tcl that it created two di erent directories in your main directory: These directories hold the support programs and les for the main Tcl/Tk program wishx. These are the directories that Tcl/Tk programs need to know about. We can set the appropriate environment variables with the following commands:
setenv TCL_LIBRARY /home/clair1/FSP/lib/tcl setenv TK_LIBRARY /home/clair1/FSP/lib/tk

You should probably put these two statements in your .cshrc le so that these environment variables are set every time that you log on to your system. The Tcl/Tk programs will not run properly without them. The last thing that needs to be done is you need to set the permissions on the les such that other people can use them. To do this you need to be in the main directory which on my system is /home/clair1/FSP. You need to run the following commands to open up the les for other people to use:
chmod -R ugo+rxX bin chmod -R ugo+rX lib include man

This will enable di erent users to be able to execute the programs.

3.4 Installing The xfsp Software

Once you have the software packages installed, installing the xfsp software should be quite simple. Note that you absolutely have to have the above support packages installed in order for the xfsp program to work. The steps involved in installing the xfsp software are as follows: 1. Edit the make le in the main fsp directory and follow the steps outlined there. 2. Assemble the program by typing make xfsp. 3. Install the program by typing make install xfsp. 4. Set up an environment variable and correct your path.

CHAPTER 3. SETTING UP AND RUNNING THE XFSP PROGRAM

The make le in the main fsp directory is appropriately named Make le. You should edit this le and simply read the steps listed. The important step for the xfsp installation is step 8. In this step you supply a complete path to the executable program expectk that you just compiled in Section 3.3. In the example above the complete path is /home/clair1/FSP/bin/expectk. So in the make le for step 8 you would put the following line:
EXPECTK_EXE_PATH = /home/clair1/FSP/bin/expectk

The most important thing to note here is that the complete path to the expectk program, including the program name, has to be less than 32 characters. This is a quirk of Unix that is completely out of our control. In our example above the total path is 26 characters long and so we are ne. If the path is longer than 32 characters then you have to nd a way to make it shorter. One way to do this is to create a link from one of the common executable directories to this le. The most obvious choices for the common executable directory are /bin or /usr/local/bin. In order to do this you must have root access. Let's assume for a minute that the directory that we had placed our executables into had caused the complete path for the wishx program to have more than 32 characters. And let's also assume that we made a link from /usr/local/bin/xfsp to our executable le in /home/clair1/FSP/bin/xfsp. In that case, we would put the following line in the make le:
EXPECTK_EXE_PATH = /usr/local/bin/xfsp

Note that this is the location of the link and not the actual le. Once we have completed the steps outlined in the make le we can assemble the program by running the make le on the xfsp program:
make xfsp

Note that this should be run in the main fsp directory, not the xfsp src directory. Finally, we can install the xfsp and xfspview programs in the destination directory by running the make le with the install option:
make install_xfsp

This should place the xfsp and xfspview programs in the executable directory. Now that the xfsp program is in place you need to set an environment variable so that the program will know where the support les (help les, pictures, tables, etc.) are located. This is done by setting the environment variable XFSP_DIRECTORY to the main fsp directory. So in our example this would be done like this:
setenv XFSP_DIRECTORY /home/clair1/FSP/fsp.1.1

Just like the environment variables for the Tcl/Tk package, you should probably put this statement in your .cshrc le to make sure that it is set every time that you log on to your system. Finally, you have to set your path to include the xfsp program. If you installed the xfsp program in the same place that you installed the expectk program, like we did in this example, then you don't need to do anything else. If you didn't then you need to execute a statement like:

3.5. RUNNING THE XFSP SOFTWARE

set path = ($path /home/clair1/FSP/bin)

Once again, something like this can be placed in your .cshrc le so that it is set every time you login.

3.5 Running The xfsp Software

Now that the software has all been installed you can run the xfsp program. You might want to rst make sure that the following steps have been completed: 1. The environment variables XFSP_DIRECTORY, TCL_LIBRARY and TK_LIBRARY have all been set to their proper values. 2. Your path has been set to include the directories that hold the expectk, xfsp, xfspview and fsp programs. 3. You are currently in a directory that you have write access to. This is needed because the xfsp will create some les there. If all of this has been done then you should be able to run the xfsp program by simply typing:
xfsp

If everything is set up properly then the xfsp control window will pop up onto the screen. It looks something like Figure 3.2.

Figure 3.2: Main xfsp Window. There are two distinct part of the xfsp control window. The top part consists of a menu bar with 5 buttons in it that control the various administrative parts of the program like le manipulation, the main help screens, exiting the program, etc. The large window right below the menu bar is the data ow window. Each of the buttons in the data ow window has

CHAPTER 3. SETTING UP AND RUNNING THE XFSP PROGRAM

various options \underneath" it. If you click on one of the buttons then a window will pop up with the options speci c to that button's function. For example, there is a button called \Fix Loop Data." If you click on that button then the window that holds the options that deal with xing the loop data will pop up. Once you are done setting those options then you can pop that window down and play with some di erent options. For every button and every option there is either a help screen or an explanation button. You should probably just spend some time reading the explanations given for various options. The sections that follow will point out some of the details about that xfsp program that you should de nitely be aware of.

3.5.1 The Layout Of The xfsp Window

In the xfsp data ow window there are three rows of buttons. These rows, from top to bottom, correspond to the various data sources that we have: the loop data, the probe vehicle data, and the incident database. The basic ow for each of the rows is the same: The buttons on the far left side of the data ow window allow you select the data that you would like to process. The buttons in the second column from the left allow you to apply various xes to the data. For example, under the loop data x button you can choose whether or not to ll in the holes in the loop data. The buttons in the middle column allow you to choose what kind of processing you would like to do on the various sets of data. In the fourth column you can choose to do various integrity tests on the loop data and/or indicate whether the program should attempt to correlate the incident database with the probe vehicle data. Finally, the last column of buttons deal with calculating the delay for each incident. The layout of the data ow window was chosen to re ect the actual ow of data inside the fsp program. The arrows indicate the how the data ows (which is mostly from left to right). The hope is that this would help the user understand the function of each of the options.

3.5.2 Using The Fileselector

There are few times within the xfsp program that you will need to tell the program what le you are referring to. For example, you might want to use a setup le (Described in Section 3.5.3) to load some options. Or you might want to save the current run le and incident lter without running the fsp program. In all cases, le selection is done though a piece of code called a le selector. The le selector window is shown in Figure 3.3. The le selector reads in the contents of the current directory and displays them in the large window. The user is then allowed to select a le by either typing in a le name and then clicking on \OK" or by clicking twice really fast on one of the les in the list. Either way, the selected le is the passed back to the application which then uses it. You can traverse directories by either selecting \.." in the le list window or by typing a directory name in the

3.5. RUNNING THE XFSP SOFTWARE

Figure 3.3: The xfsp File Selector Window. entry window and hitting return. If you decide that you don't want to continue with whatever option brought up the leselector window then you can simply click on the \Cancel" button to cancel everything.

3.5.3 Using Setup Files

The rst thing that you will notice about the xfsp program is that there are quite a few options (approximately 120). The rst thing that I noticed about using the program is that it's a complete pain to have to respecify all of the options that you desire every time that you start up the program (the program starts up with the parameters set to their default settings). Therefore, to easy this burden, the xfsp program can create and reload special les called setup les. A setup le is simply a le that the xfsp program creates that holds the current settings of all of the various options. So if you are doing a particular type of analysis and you have the parameters set a certain way then you might want to save these settings in a setup le so that you can run the program later and not have to respecify everything. I would suggest that you utilize the setup les because they save quite a bit of time. What I do is I have one setup le for the before study data set and one for the after. Saving and loading the setup les can be done through the button names \Files" in the menu bar at the top of the control window. Once you have set up the options the way that you like you can have the xfsp program run the fsp program. This is done by choosing \Run" in the menu bar at the top of the xfsp control window. This will pop up a run window that looks like Figure 3.4 with a few options in it. Once you have set these then you can choose \Run" in the run window and the program will

3.5.4 Running The fsp Program

CHAPTER 3. SETTING UP AND RUNNING THE XFSP PROGRAM

Figure 3.4: The xfsp Run Window. start. When this happens the run window will pop down and an output window will pop up. An example of an output window is given in Figure 3.5. The output window will collect the output from the fsp program and display it in the text area. At the bottom of the output window are a few buttons that allow you to save the output to a le or print it to a printer. The le that you can save to is called fsp.out.X and it is placed in the current directory (the \X" in the lename is the run number). The printer that you can print to is determined by the printer option in the xfsp program. These buttons should only be used once the fsp program has nished. You will know that the fsp program has nished processing normally because it spits out the following line:
****** END OF PROGRAM ******

If the program does not nish successfully but encounters some sort of error, then it will say something bad and not spit out this line. When the fsp program gets done running (whether it nished successfully or not) the xfspview program will pop up (Section 3.5.5). You should note that if you are doing any processing on the loop data or the car data that this might take a long time. In cases like this the xfsp program is not really very useful as an interactive tool. What you might want to do, instead of starting the fsp program from inside the xfsp program, is to save the run le and incident lter that you have made and to then run the fsp program from the command line and put it in the background. You could even redirect the output to a le for later viewing. This would work really well when the program is expected to take 4 or 5 hours (which can happen).

3.5.5 Using The xfspview Program

The xfspview program is a graphical user interface to the data that the fsp program generates. The xfspview program can be viewed as a sister program to the xfsp program: the xfspview

3.5. RUNNING THE XFSP SOFTWARE

Figure 3.5: The xfsp Output Window. program gives the user an easy way to view the output les that the fsp program has generated. The xfspview window is given in Figure 3.6.

Figure 3.6: The xfspview Window. The xfspview program is run in one of two ways: It can be run in stand alone mode where the user starts the xfspview program up from the command line. When the program is run this way the user needs to supply as the one argument the main output directory. This is done by simply typing the program name on the command line followed by the name of the output directory. Something like: xfspview /home/data/Out5min. It can be started up automatically by the xfsp program. After the xfsp program has run the fsp program it will start up the xfspview program if the user so requests. Whether this is done or not is set by a button in the \Run Window." The last panel of the \Run Window" allows the user to choose whether to run the xfspview program after the fsp program is done. The xfspview has three main sections of buttons that are stacked vertically. The top section is a row of buttons labeled \Quit," \Delete Graphs," and \Help." These button

CHAPTER 3. SETTING UP AND RUNNING THE XFSP PROGRAM

do fairly obvious tasks. The only potentially confusing button is the \Delete Graphs" button and we will talk about that a little bit later. The middle section of buttons has a title above it that says \Directories" and the bottom section of buttons has a title above it that says \Files." What the xfspview program does is it starts o in a directory and it reads all of the entries in the directory table. If an entry corresponds to a directory then a button is created with that directory name as it's label and it is placed in the middle section. If an entry is a le then a button is created for that le and it is placed in the bottom row. If the program starts out with a main output directory being passed to it (actually, it better start out with a main output directory or it will not work) then the middle section of buttons should read \Cardata," \Loopdata," and \Incidents." These are the main directories that the fsp program makes under the main output directory. When you click on one of the buttons in the middle section (one of the buttons corresponding to a directory) then the program will change down into that directory and then reread all of the les. So if you were to choose \Loopdata" then the program will change into the loop data directory and it will read the directory table and create new buttons corresponding to the directories and the les. Note that whenever you are in a directory below the main directory that there will always be a button labeled <Up> that will take you to the directory directly above. Whenever you click on one of the le buttons the program will either display the text le on the screen, generate a graph using the program xgraph, or it will generate a graph using the gnuplot program. The choice the program makes depends on what type of le you have selected. A more detailed description is given in the help windows of the xfspview program.

Chapter 4

The Data
This chapter will explain the format of the data that we get from the cars and from the loop detectors. It will also discuss the format of the incident database. The directory structure that the fsp program expects the data to be in is discussed in Chapter 6. The rst section of this chapter will discuss how to download the data and where to place it.

4.1 The Study

In order to estimate the delay savings attributable to the FSP, data was collected over two time periods: once when the FSP was not in operation (the \before" period) and once when the FSP was in operation (the \after" period). The before study took place from February 16 through March 19, 1993 with the after study taking place from September 27 through October 29, 1993. All of the data was collected on a section of the I-880 freeway in Hayward, California as shown in Figure 4.1. The study section was 9.2 miles long and varied from 3 to 5 lanes. An HOV lane covered approximately 3.5 miles of the study section. There were several sections that lacked right-hand shoulders and/or left-hand shoulders. Call boxes were installed at approximately 1/4 mile intervals but that data was not used for the evaluation project. Probe vehicle data was collected on the weekdays during the peak periods (6:30 - 9:30 am and 3:30 - 6:30 pm). And loop detector data was collected from 5:00 - 10:00 am and then again from 2:00 - 8:00 pm. For each study period we collected three di erent types of data: loop detector data, probe vehicle data and an incident characteristics database.

4.2 Downloading The Data

The data that was collected during the Freeway Service Patrol Evaluation Project is available via anonymous ftp from the machine www-path.eecs.berkeley.edu at UC Berkeley. Anonymous ftp is a way of downloading les via the Internet without having to use passwords. To connect to the machine that holds the data at UC Berkeley using anonymous ftp you simply type the command:
ftp www-path.eecs.berkeley.edu

38
To Oakland
0 Marina 21 Winton

CHAPTER 4. THE DATA

264 266 280 293 #2

# 11 #6

312

# 18

Jackson/SR 92 106

329

# 19

342 SR 92 Washington/SR238 359 128 134 Lewelling 140 #8 388 156 160 Hesperian Tennyson # 16 398

# 13

# 12

# 17

177

#3 431 # 15

194

#1 447 Industrial #5

211

228

# 20

A-Street

243 250

# 10 Whipple 497

To San Jose
Legend: Loop detector HOV lane Shoulders present No shoulders 1 unit = 100 feet (e.g. 142 = 14200 from Marina)

Figure 4.1: The FSP Study Section.

4.2. DOWNLOADING THE DATA

When the machine prompts you for a login ID you simply type in \anonymous." This will tell the machine that you want to log in as a guest. When you are prompted for your password you type in your email address like: pettyk@eecs.berkeley.edu. Once you have connected to www-path you will be able to browse through the entire directory structure. One thing that you should always do when browsing through an anonymous ftp site is to download any les named README or README.DOC because they usually have helpful information in them. After you log in, to get down to the FSP directory you need to change into the pub directory and then into the FSP directory. Once inside the FSP directory you'll see that there are three main directories named Packages, Data, and Results. The Packages directory holds the support packages for the xfsp programs, the Data directory holds the data (imagine that), and the Results directory holds the results of the project. The discussion here will focus on downloading the data. There are various README les scattered throughout the directory structure that can help you download the results and the software packages. Under the Data directory is a sub-directory named Raw that holds the raw data, and a sub-directory named Processed which holds the processed data. Figure 4.2 gives a representation of what the directory structure looks like for the branch FSP/Data/Raw/Set2/Loop. As you can see, the directory names are pretty straight forward.
FSP

Packages

Data

Results

Raw

Processed

Set 1

Set 2

Set 1

Set 2

Car

Loop

Inc

lp101393.tar.Z

Figure 4.2: FTP Directory Structure On www-path. If you want to run the fsp program on the data then you probably want to download the raw data and then use the fsp program to process it. In that you case you want to place the data that you download in the input directory structure that is de ned in Chapter 6. The data goes in the obvious places: the car data goes in the directory labeled \Cardata," the loop data goes in the directory labeled \Loopdata," etc. If you aren't interested in using the fsp program to process the data and you only want to use the data with your own programs then you probably want to download the processed data. The processed data holds, along with the car data and incident database, the loop data in 5 and 1 minutes averages. Most of the processing that has taken place in di erent groups has been done on the 1 minute loop data

40 and the incident database.

CHAPTER 4. THE DATA

One thing to point out is that you can also download the data through the World Wide Web using the program netscape or mosaic1 if you have access to a workstation running X, or by using the program lynx if you only have a character based terminal. Netscape is a program that allows people to do quite a few things, like browse documents, look at art galleries, listen to music les, and even get current weather maps. What we will use it for is a user friendly interface to download the data. In order for netscape to work, it needs to know the location of the document that you want to look through. This is done by specifying something called a uniform resource locator, or URL for short. The URL for the FSP project is: So to connect to this via netscape or lynx you would type:
netscape http://www-path.eecs.berkeley.edu/FSP or lynx http://www-path.eecs.berkeley.edu/FSP http://www-path.eecs.berkeley.edu/FSP/

4.2.1 Downloading Via The World Wide Web

Once you have connect to the FSP document via netscape you will be able to download all of the results, the software programs, and whatever combination of the data you would like. I would strongly recommend using this to download the data because it is so user friendly (besides, you'll be sur ng the Internet if you do!).

4.2.2 Size of the Data

A word of caution before you start downloading the data: they take up a lot of disk space. Table 4.1 gives the size of each data set in megabytes. Note that if you were to download the entire data set that you would need approximately 2 gigabytes to hold the set uncompressed. To generate any output involving the loop data you will need approximately 400 megabytes more. Set 1 Set 2 Data Type compressed uncompressed compressed uncompressed Loop data 382 760 412 817 each day 16 33 16 33 Car data 35 126 31 107 Incident data 0.04 0.2 0.03 0.2 Table 4.1: Size of data sets (in megabyes). In light of this I would recommend that you download only a portion of the data set and work with that. On the other hand, you can download the processed data, instead of the raw data, and work with that.
1 On some systems the program mosaic is called xmosaic or Mosaic. Check with your system administrator if you can't nd it.

4.3. THE CAR DATA

4.3 The Car Data

During the course of the experiment there were four or ve probe vehicles that were driven around the study section for approximately 2 1=2 hours in the morning and 2 1=2 hours in the evening. These vehicles were equipped with computers that recorded the car's movement and the driver's key presses and then saved these to various les on a PC oppy disk. We get a total of four les from each car for each run. They are currently named: key.dat, fsp.dat, nav.dat, and gsp.dat. Below is a short sample of each type of le and a description of what it is:

key.dat This is a le that saves the keys that the drivers type in.
SAMPLE: 6:54:15 3- 8-93 0: 0: 2.618 1 0: 0: 5.493 1 0: 0:21.549 1 0: 0:44.645 76 0: 0:56.244 76 0:18:16.297 65278 0:21:27.264 81942 0:26:42.116 106153 0:32:53.528 112000 0:36:32.899 132595 0:39:13.795 147085 0:40:29.114 153335 0:41:30.855 158933 0:42:13.116 162578 0:44: 3.463 168739

14 7311 03/07/93 06:55:00 qwe d k d d l l d k k qwe

The drivers type a sequence of keys each time they start a loop. During the before study this sequence was qwe. Each time they pass an incident and each time they pass a gore point they type in a single key. The le starts o with a date and time stamp on the rst line. This is put there by the computer when it is turned on. The next four lines are just start up information that the user types in. The rst main column is the time since the start of the le, the second is the odometer reading of the car in wheel rotations, and the third is the text that the driver has typed in. There is one line in this le for every line the driver types in. A more detailed explanation of the rst few lines follows:
0: 0: 0: 0: 0: 0: 2.618 0: 5.493 0:21.549 0:44.645 0:56.244 1 1 1 76 76 14 7311 03/07/93 06:55:00 qwe <<<<<Driver ID number Car ID number Date Time Sequence to indicate start of loop

42
0:18:16.297 0:21:27.264 65278 81942 d k

CHAPTER 4. THE DATA

<- Key to indicate gore point <- Key to indicate an incident

In the middle of the experiment it turned out that we needed to have more information from the cars. We wanted a way to get the travel times for the section of freeway that the cars were driving over that was already operating under the Freeway Service Patrol. In order to do this we had to tell the drivers to be more speci c when they typed in keys for the le key.dat. This means that we had to tell them to type in di erent keys at di erent points. These changes can be summarized in Figures 4.3 and 4.4. I will refer to the data taken during the rst part of the experiment as the rst set and the data taken during the second part of the experiment as the second set.
N

Loop start Incidents

Gore points

Figure 4.3: Basic Keys Pressed During First Set. In the rst set of data the drivers had to type in something to record three di erent things happening: 1. Every time they started another loop (or run). 2. Every time they passed one of four gore points. 3. Every time they passed an incident. To accomplish this they typed in the corresponding keys: 1. Each loop: qwe or QWE. 2. Each gore point: a single key from the left half of the keyboard. 3. Each incident: a single key from the right half of the keyboard.

4.3. THE CAR DATA

Loop start Northbound start and end

Incidents Southbound start and end

Gore points

Figure 4.4: Basic Keys Pressed During Second Set. These keys are labeled in Figure 4.3. In that gure, the boomerang shaped loop is a representation of the freeway. The three di erent keys that the drivers had to type in are indicated by the three di erent symbols. We thought that this was going to be a su ciently rich labeling to capture all of the data that we wanted. It turns out that we needed to have more detail, so for the second set of data, the after study, we had the drivers type in a di erent set of keys. They typed in a key: 1. 2. 3. 4. 5. 1. 2. 3. 4. 5. Every time they ended another loop (or run). At the start and end of every southbound run. At the start and end of every northbound run. Every time they passed one of four gore points. Every time they passed an incident. Each loop: the key \q" Southbound run: \c" Southbound run: \t" Each gore point: \n" Each incident: \o"

To accomplish this they typed in the corresponding keys:

These keys are labeled in Figure 4.4. Since this is a large number of keys for the drivers to remember to press when they are driving on the freeway, we modi ed the keyboards to make their task easier. We had hard plastic covers made that t over the keyboards.

CHAPTER 4. THE DATA

In these plastic covers we cut holes where the desired keys were and placed giant buttons that were clearly labeled on these keys. You might ask yourself at this point, why am I bringing this up at all? It turns out that in order to take advantage of this added detail, we have to process the car data les di erently. In order for the program to be able to do this it has to know what type of data it is dealing with. What this means is that there has to be a way to tell the program whether it is dealing with the rst type of data or the second. The way that this is done is through the run le parameter CAR_DATA_SET_NUM. This parameter should be set to a 1 if the rst data set is to be used and to a 2 if the second data set is to be used. fsp.dat This le is saved automatically by the INRAD equipment in the car each time that it drives over an INRAD beacon.
SAMPLE: 6:54:15 3- 8-93 0:19:19.557 70913 0:19:19.582 70915 0:19:19.608 70918 0:25:37.642 103309 0:25:37.663 103310 0:25:37.685 103311

CS4NE CS4NE CS4NE CS2SE CS2SE CS2SE

The rst line is the date stamp (that shows up in all the les). All of the other lines are times when the car picked up an INRAD beacon. The rst column is the time since the start of the le, the second column is the odometer reading of the car in wheel revolutions, and the third column is a string to indicate which INRAD signal was picked up. There are a total of three di erent INRAD points: two on the southbound run and one on the northbound run. nav.dat This is the data from the digital compass in the car.
SAMPLE: 6:54:15 0, 1, 1, 1, 1, 1, 3- 8-93 2565, 2640, 2565, 2640, 2563, 2641, 2575, 2639, 2575, 2639, 2575, 2639,

2356 2356 2354 2355 2355 2355

The nav.dat le is a binary le when it is stored on disk. We convert this to it's ascii equivalent which is what is shown above. Once again, the rst line is the date stamp. The rest of the rows are stored for each second. The rst column is the odometer reading in wheel revolutions, the second and third column is the digital compass reading, and the

4.4. THE LOOP DATA

fourth column is the angular rate sensor. Although you could calculate the position using the digital compass or the angular rate sensor, we found that the angular rate sensor wasn't very accurate. Therefore we get our position plots from the digital compass. gps.dat The gps.dat le is the data from the GPS equipment in the car.
SAMPLE: 6:54:15 3- 8-93 $GPGGA,025602,3747.75,N,12216.00,W,0,3,000,041,M,-028,M*6E $GPGGA,025602,3747.75,N,12216.00,W,0,3,000,041,M,-028,M*6E $GPGGA,025602,3747.75,N,12216.00,W,0,3,000,041,M,-028,M*6E $GPGGA,025602,3747.75,N,12216.00,W,0,3,000,041,M,-028,M*6E $GPGGA,025602,3747.75,N,12216.00,W,0,3,000,041,M,-028,M*6E

It is stored one line per second, just like the nav.dat le. The rst line is the date stamp. The following lines are a bunch of stu that the GPS equipment stores that we don't really use. Only the third and fth columns are of use to us. They contain the latitude and longitude of the car which we use to plot the trajectory.

4.4 The Loop Data

The loop data is pretty straight forward in that there is only one le per cabinet per day and it isn't even in ascii text so we can't read it. The loop data consists of the output from di erent loop detectors. A loop detector is just an inductive loop that is buried under the freeway that picks up the presence of a vehicle traveling over it. On the main line lanes the detectors are placed in pairs, but on the on and o ramps they are single detectors. From this data the program calculates the number of cars that pass over the detectors their average speed and the average occupancy per period. Figure 4.5 should help explain the calculations. The gure on the left side of Figure 4.5 is a graphical representation of one lane of a freeway. As you can see there is an upstream and a downstream detector and the distance between them, , is a known quantity. The graphs on the right side of Figure 4.5 are hypothetical graphs of the signals that come from the upstream and downstream detectors when a single car passes over both of them. The program nds the di erence in time between the falling edges of the two pulses, what is labeled in Figure 4.5, and then uses this to calculate the speed. The program calculates the values of speed, occupancy and counts, once per output period. The concept of output period is described in more detail in Chapter 7 but for now it will su ce to call it the frequency at which data is reported to the user. The calculation of speed per output period is as follows:
n 1X = n i i=1

CHAPTER 4. THE DATA

Upstream

Downstream

Downstream signal

Upstream signal

Time

Figure 4.5: Basic Calculation of Car Speeds. Where n is the number of cars that went over the detectors during that time period, i is the di erence in time between the falling edge of the upstream detector and the falling edge of the downstream detector for each car, is the average time between falling edges, and is the nal average velocity. Note that this is the same as the formula:
n 1 = 1X 1 n i=1 i

Where i is the speed for each car that went over the detector during the given time period. This is sometimes referred to as the harmonic mean speed. Note that this speed is generated for every lane of the highway and it is not the average speed that we will refer to later on. For a more complete discussion of the speeds used in the delay calculation see Section 11.1. The occupancy is the percentage of time that the detector has a vehicle on it and the on time is the average time that each vehicle spends on the detector. When the loop data is read in all of these values are calculated. If the user chooses to generate a text le of this data, as explained in Chapter 7, then they will get a le corresponding to the calculated values of counts, occupancy, speeds and on times. What I will explain below is the translation of a bit of loop data into ascii text. This is a sample of the text le from a loop for one output period:
This is the data from the file: /home/clair0/PATH/FSP/Set1/Loopdata/lp021793/loop1.txt 5:01:00 HACIENDA 1 2 0.51 0.76

PPS

3 2.29

4 1.27

5 0.76

7 0.25

4.4. THE LOOP DATA

OCC ON PPS OCC ON SPD 0.56 166.67 0.51 0.56 166.67 71.15 8 2.54 3.25 191.67 2.54 3.11 183.33 67.06 1.47 288.89 2.54 2.88 170.00 9.30 9 3.05 4.52 222.22 3.05 4.15 204.17 63.75 3.56 233.33 2.29 3.64 238.89 61.88 10 4.07 8.59 316.67 4.07 8.50 313.54 66.70 1.64 193.33 1.27 1.64 193.33 63.92 11 1.53 2.91 286.11 1.53 2.85 280.56 63.75 0.85 166.67 0.76 1.19 233.33 55.79 12 13 0.25 150.00 0.25 0.28 166.67 74.38 14

PPS OCC ON PPS OCC ON SPD

The above text is an example of one output record for an entire cabinet. This data is for March 17th, 1993 from cabinet #1, at 5:01:00am. Each cabinet can hold a total of 28 loop detectors but most of the time there aren't that many detectors at one site so they hold less. A record like the one above is generated once for every output period. Each record contains 28 slots of data in 2 rows of 14. Each slot contains 2 inductive measurement loops: an upstream and a downstream. You will notice that there are two main rows and in each one of these rows, 2 sub rows. The rst sub row is the upstream detector and the second sub row is the downstream detector. I have cut out a section of the above report and put it below with explanations to the right side.
PPS OCC ON PPS OCC ON SPD 1 0.51 0.56 166.67 0.51 0.56 166.67 71.15 2 0.76 1.47 288.89 2.54 2.88 170.00 9.30 3 2.29 3.56 233.33 2.29 3.64 238.89 61.88 <<<<Detector Upstream Upstream Upstream number PPS value OCC value ON time value

<- Downstream PPS value <- Downstream OCC value <- Downstream ON time value <- Speed value

The mapping from the detector numbers to the actual lanes is done by the loop wiring diagram les discussed in Chapter 6. If there is a whole column of values missing then that means that there just isn't any data for that detector slot. The empty columns are just extra.

CHAPTER 4. THE DATA

In some columns there might be data for just the upstream or just the downstream detector. This usually happens when that detector slot holds the output from one of the on or o ramps. If the output from two on or o ramps are placed in the same detector slot meaning one was placed in the upstream position and one in the downstream position - then there won't be a speed value calculated for this slot. This is because the two detectors might not even be next to each other on the road, and therefore it doesn't make any sense to calculate a speed value. There is one thing about the way the loop data is processed that I should point out before going on. There used to be two di erent ways to process the loop data. The rst way was called the long data set. This simply meant that we were referring to the whole time period over which the loop data was collected. The second way was called the short data set. This referred to a more speci c range of time that the loop data was collected. The original intention was that you would want to have a coarse look at all of the data and then a very ne, detailed look at a smaller section. But we decided that the long data set was not very useful. All of the analysis was being done on the short data set instead of the long data set. Therefore, the fsp program no longer has two di erent ways of processing the data - there is only one.

4.5 The Incident Data

The incident data is one database le with approximately 80 columns of information per incident. The database was collected during the experiment by the drivers of the probe vehicles. When they were driving around the freeway and they passed an incident they would radio it in to the command center (a person sitting at Denny's). Their report would go something like, \There's a stalled green passenger car, southbound, about 1/2 mile before 92. They are getting assistance from the FSP guy now. There is also a CHP on the scene." All of this would be written down by someone at the command center on a standard form. This form was then coded into a database with numerical entries in each column so that a computer could process it later. The database format was devised by Hisham Noeimi and Dan Rydzewski. A complete listing of the columns in the database is given below:

4.5. THE INCIDENT DATA

Column Name A Type:

B C D E F G H I

Incident: Date: Shift: Time: Direction: Beginning: End: Link Identity:

Location:

Relative:

Description and Options Data type F = Field data C = CHP data T = Tow truck data Incident number Date incident occurred Shift during incident 0 = AM shift 1 = PM shift Time listed in military time Direction of incident 0 = Northbound 1 = Southbound Incident present at beginning of shift 0 = No 1 = Yes Incident present at end of shift 0 = No 1 = Yes Link identity according to between exits 1 = Marina - Washington/238 intersection 2 = Washington/238 intersection - Lewelling/Hisperian 3 = Lewelling/Hisperian - A-Street 4 = A-Street - Winton 5 = Winton - Jackson/92/San Mateo Bridge 6 = Jackson/92/San Mateo Bridge - Tennyson 7 = Tennyson - Industrial 8 = Industrial - Whipple Location listed according to following 1 = Marina 2 = Washington/238 intersection 3 = Lewelling/Hisperian 4 = A-Street 5 = Winton 6 = Jackson/92/San Mateo Bridge 7 = Tennyson 8 = Industrial 9 = Whipple Relative location 0 = At exit 1 = Before 2 = After

50
Column Name L Exit Distance:

CHAPTER 4. THE DATA

Description and Options Distance of incident from speci c exit 1 = Right at over/under-pass 2 = < 1/4 mile 3 = 1=4 mile 4 = 1=2 mile 5 = 3=4 mile 6 = 1 mile 7 = > 1 mile Which lane was the primary lane 1 = Lane 1 2 = Lane 2 3 = Lane 3 4 = Lane 4 5 = Lane 5 7 = Right shoulder 8 = Center divide Which was the 2nd lane involved 1 = Lane 1 2 = Lane 2 3 = Lane 3 4 = Lane 4 5 = Lane 5 7 = Right shoulder 8 = Center divide Which was the 3rd lane involved 1 = Lane 1 2 = Lane 2 3 = Lane 3 4 = Lane 4 5 = Lane 5 7 = Right shoulder 8 = Center divide Type of incident 0 = Vehicle 1 = Debris/Pedestrian 2 = Sweeping/Clearing Debris Is this a breakdown 0 = Not this type 1 = Flat tire 2 = Gas 3 = Mechanical 5 = Can't tell/Using call box

Primary Lane:

2nd Lane:

3rd Lane:

P Q

Incident Type: Type 1:

4.5. THE INCIDENT DATA

Column Name R Type 2: Description and Options Is this an accident 0 = Not this type 1 = single car incident 2 = multiple car incident S Type 3: Is this a CHP event 0 = Not this type 3 = CHP is incident 4 = Ticketing T Begin/End: When did the incident start and end 0 = Started and ended during the shift 1 = Everything else U Num Vehicles: The number of vehicles involved V-X Vehicle Type: Type of 1st, 2nd and 3rd vehicles 0 = No vehicle involved 1 = Standard car 2 = Pickup truck 3 = Van 4 = Station wagon 5 = Motorcycle 6 = Vehicle with trailer 7 = Dump truck/Commercial truck 8 = 18-Wheeler tractor trailer 9 = Caltrans construction vehicle 10 = Other 11 = Tow truck 12 = 4x4 vehicle Y-AA Vehicle Color: Color of 1st, 2nd and 3rd vehicle 0 = Not a vehicle 1 = Black 2 = Blue 3 = Brown 4 = Gold 5 = Green 6 = Grey 7 = Orange 8 = Red 9 = White 10 = Yellow 11 = Beige 12 = Black and white (CHP) AB Ticketed For Tow: Vehicle ticketed for tow to storage by CHP 0 = No, not witnessed 1 = Yes

52
Column Name AC CHP:

CHAPTER 4. THE DATA

Description and Options Arrival of CHP at scene 0 = CHP does not arrive during shift at incident 1 = CHP present at beginning of witness 2 = CHP arrives during shift at scene AD Entries In Log: Number of times incident is entered in time log AE-BE Time Entries: Individual time entries in log BF No Tow: Tow truck did something funny 0 = Doesn't apply 1 = Tow truck left without assisting 2 = Clearance time not known BG Main Clear: Time that main was cleared BH FSP Arrival: Arrival of FSP at scene 0 = No FSP 1 = FSP present at rst witness 2 = FSP present during incident 3 = FSP is incident 4 = FSP present but another tow truck towed BI CHP Arrival: Time that the CHP arrived at scene BJ Tow Truck Arrival: Time that the Tow Truck arrived at scene BK Ambulance Arrival: Time that the Ambulance arrived at scene BL Fire Arrival: Time that the re department arrived at scene BM CHP Departure: Time that the CHP departs the scene BN Tow Truck Departure: Time that the Tow Truck departs the scene BO Ambulance Departure: Time that the Ambulance departs the scene BP Fire Departure: Time that the re department departs the scene BQ Comments: Were there comments written in the log 0 = No comments 1 = Comments written in eld log BR O cial: Number of o cial vehicles at incident BS Non-O cial: Number of non-o cial vehicles at incident BT Tow Truck Response: Time that the Tow Truck responds BU Tow Truck Clearance: Time that the Tow Truck cleared incident BV-CW Headway: The headway times CX Incident Duration: The duration of the incident CY Weather: The weather during the incident 0 = Clear 1 = Partly cloudy 2 = Cloudy 3 = Light rain 4 = Rainy

For the elds that have a time value if there is no time value or the time value is not available then the database entry is simply a \*". The database is stored on the workstations as a tab delimited set of lines. This means that there is one line per incident and the elds are

4.5. THE INCIDENT DATA

separated by tabs. These are all of the data les that we collect. We get 8 car disks and 19 or 20 loop disks per day and one incident database for the whole study period.

CHAPTER 4. THE DATA

Chapter 5

Problems With The Data

There are quite a few things that turned out to be wrong with the data. In most of the cases we attempted to x these problems by programming the fsp program to take care of them. In other cases there is nothing that we could do about the problems and so we just left them. This chapter will explain the problems that we found and what the fsp program does to x them. Note that this chapter does not have a canonical list of which speci c piece of data was wrong where. That information can be found in one of the other publications of the FSP project. All of the run le parameters that are referred to in this chapter are explained in detail in Chapters 7, 10, and 11.

5.1 The Car Data

There were usually 3 or 4 probe vehicles that were driving around the test section of the freeway during the study period. When the drivers would pass an incident they would press a key on their keyboard to record their position and they would radio in their position and the characteristics of the incident to the base station. Most of the problems with the car data arose during these transactions.

5.1.1 Key Presses

Recall that the drivers were supposed to press a certain set of keys when they were driving around the freeway. The keys that the drivers were supposed to press for the after study are given in Figure 5.1. So a typical sequence of key presses that the program could expecting to see is something like: loop start, southbound start, gore point, gore point, southbound end, northbound start, gore point, gore point, northbound end, etc. Well, quite a bit of the time the drivers either forgot to press the keys or they pressed the wrong key. This causes a few problems: It is harder to match up the incident database with the car key presses. This makes it hard to gure out the precise location of the incident. See the discussion in Section 5.3.1. If the drivers don't radio in that they see an incident then it could possibly mess up the incident duration. If they were the rst or the last driver to pass an incident and they don't report it then the duration of the incident will be too short. 55

CHAPTER 5. PROBLEMS WITH THE DATA

Loop start Northbound start and end

Incidents Southbound start and end

Gore points

Figure 5.1: Basic Keys Pressed During Second Set. In one routine, the program attempts to calculate the travel time for the southbound run and for the northbound run based on the start and end keys. If the drivers don't press these keys properly (in the right order and at the right time) then we can't get accurate travel times. Although we don't do much to x the key presses, the program will attempt to weed out simple things. For example, if the driver typed in 1) southbound start, 2) northbound end, 3) southbound end, then the program won't calculate any travel times. What it will still do, no matter what, is parse the car data on the southbound start key. If the driver repeatedly pressed the southbound start key in the middle of a run the program will assume that every key press signi ed the start of a southbound run. As it turns out, we don't really need to do that much with the key presses for the rest of the analysis to go smoothly.

5.1.2 Car Placement

If the key presses were entered correctly then it's not that hard of a job to gure out where the cars are at any speci c time. But you will notice that in the fsp program we don't use the car data that much. The reason for this is two fold: It was really hard to trust what the drivers typed in. So we couldn't place that much stock in the location of the car at any particular time. Getting anything from the car data is just plain hard. If there was ever a way to get any data we needed from the loop data we did. There was one thing that we did use the car data for, though. That was to re ne the placement of each key press in the key.dat le. The reason that this had to be done is

5.1. THE CAR DATA

because when the incident key was pressed the distance that was stored in the key.dat le was the distance since the computer had been turned on. Since the driver may have driven around the block a couple of times before they started their run down the freeway we need to gure out exactly where on the freeway the incident key was pressed. We do this by looking at the other keys that the drivers pressed and at the INRAD data. The procedure that we go through is listed out below: 1. If the INRAD data is available then measure the distance from the last INRAD point to the key press. Since we know where the INRAD points are we can then get the location of the key press. 2. If the INRAD points are not available then look for the other key presses. If you have both a gore point key and a direction starting key then gure out the location of the key press from both of these and average them. 3. If you only have the gore points then just use them. 4. If you only have the direction starting keys then just use them. Note that this is not the same thing as trying to match up the key presses with the incident database - this is more of a precursor to that routine. We are simply trying to give our best estimate of where the key presses took place based solely on the car data. Trying to match the key presses up with the incident data is another can of worms and is discussed in Section 5.3.1. Car 2 was consistently bad. It seems that in the middle of operation it would screw up the data stream that it was saving to the nav.dat le. We couldn't really understand what it was doing. Maybe the \COM" port on the PC was skipping a byte or something like that. We changed cars in the before study once we gured out that something was wrong. The car was supposed to be xed for the after study and it wasn't. Since car 2 was always bad, I would recommend that you don't use it for any data analysis.

5.1.3 Just Plain Bad

5.1.4 Car Position Plots

The calculation for the car position from the nav.dat les seems to drift. You can see this clearly in Figure 5.2. The nav.dat le contains the output from a digital compass for each second. The output consists of three values, the total distance the car has traveled, and two values whose ratio is proportional to the direction the car is pointing. A typical plot of the car trajectory should have the starting and ending points matching up. Unfortunately, this rarely happens. At rst, the reason that we wanted these plots was to make sure that the drivers weren't going to McDonald's in the middle of the experiment. We then decided that this was not important because the drivers were responsible people. So these plots are not used anywhere in the program. These plots are still generated in case somebody wants to do something with them later.

58
1

CHAPTER 5. PROBLEMS WITH THE DATA

Car and incident data: /am100693/car1/c1loop3 Car trajectory Incidents INRAD points

-1

-2
Position (miles)

-3

-4

-5

-6

-7

-8 0 1 2 Position (miles) 3 4 5

Figure 5.2: Basic Car Position Plot That Drifts.

5.2 The Loop Data

The loop data was our best source of data. Even so, there were still a lot of loop detectors that were continuously out, that went out periodically, or that counted things incorrectly. There are two main xes that we attempt to do on the loop data: a hole x, to ll in any missing data, and a consistency x, to correct systematic errors in the loop data. This section will describe these two xes and the various problems that we had with the loop data and what we did about them.

5.2.1 Loop Data Drop Outs

There are two di erent types of missing loop data. The rst type is when a loop detector is gone for the whole day - either the computer was broken or the disk was bad, etc. The second type is when the loop detector just doesn't report data for a period of time. If we visualize the data as a plot of detector number vs. time with a solid line if the data is present and a dotted line if the data is not there then we can easily see that we need to ll in the holes. Figure 5.3 is just such a representation. In this gure the data in loop #7 drops out for a time in the middle of the day and loop #10 is never there. What we do is recreate the data for the missing detectors from the adjacent (adjacent in distance, not time) loop detectors. For example, to recreate the data for loop # 10 we would use detectors # 2 and # 20 somehow. There are a couple of ways to recreate the missing data. We could just copy the

5.2. THE LOOP DATA

Detector # 3 1 7 20 10 2

Time

Figure 5.3: Loop Data Dropout. data from the adjacent upstream loop detector. Alternatively, we could average the values from the two adjacent loop detectors. The criterion that we use to govern how we recreate the data is that the delay should be the same as if the loop detector was not there in the rst place. To understand what we are doing here consider two situations: In the rst situation a loop detector is missing. The adjacent loop detectors expand the length of their segments to cover the missing detector. Based on these new lengths we calculate the delay for these two segments. This is the situation where the loop detector is not there in the rst place. In the second situation a loop detector is missing but we recreate some data for that detector. We now have three segments all with their original lengths. Based on the new data and the original lengths we calculate the delay for all three segments. This is obviously the situation where the loop data is recreated. Since these two situations cover the same distance on the freeway the total delay should be the same. This is the criterion that we use to gure out the formulas for recreating any missing loop data. These two situations are displayed graphically in Figure 5.4. The numbers on the top are the loop detector/segment numbers. Note that the segment lengths change from situation 1 to situation 2. The normal equation used for calculating the delay at a particular loop segment is: T 1 (5.1) Dk = Lk 60 Fk V ; V1 k T Where Dk is the delay on segment k, Lk is the length of segment k in miles, T is the time slice in minutes, Fk is the ow on segment k, Vk is the speed on segment k, and VT is the threshold or congestion speed. So what we are trying to do here is to set the delays for the two situations in Figure 5.4 to be equal. This is represented below: 1 1 (5.2) DSituation1 = KF1 L1 + L2 V ; V1 + KF3 L3 + L2 V ; V1 2 2 1 T 3 T

60
1 3

CHAPTER 5. PROBLEMS WITH THE DATA

1 2 3

L2 Situation 2

Situation 1

Figure 5.4: Missing Detector. 1 1 1 DSituation2 = KF1L1 V ; V1 + KF2L2 V ; V1 + KF3L3 V ; V1 (5.3) 1 T 2 T 3 T Where K is the time conversion constant. Setting equations 5.2 and 5.3 equal results in: F1L2 1 ; 1 + F3L2 1 ; 1 = F L 1 ; 1 (5.4) 2 2 2 V1 VT 2 V3 VT V2 VT If we assume that this must hold for all values of VT then we can pull out the terms that have VT in them to get: F1L2 + F3L2 = F2L2 (5.5) 2VT 2VT VT Finally, we solve equation 5.5 for F2 to get: F1 + F3 = F (5.6)
2 2 If we turn around and plug 5.6 into equation 5.4 then we get: F1L2 1 ; 1 + F3L2 1 ; 1 = F1 + F3 L 1 ; 1 2 2 V1 VT 2 V3 VT 2 V2 VT F1 + F3 = F1 + F3 V1 V3 V2 F1 + F3 V2 = F1 F3 V1 + V3

(5.7) (5.8) (5.9)

So the equations that we use to recreate the data for loop detector #2 in situation 2 in Figure 5.4 are equations 5.6 and 5.9 above. Note that the distance drops out and that this will work no matter how many detectors in a row are missing. If the detector that is missing is at the end of our study section, meaning we don't have any data for one side, then the counts, speeds,

5.2. THE LOOP DATA

and occupancies are simply copied from the side that we do have data for. This option can be turned on or o by the user by specifying the run le parameter LOOP_HOLES_FIX that is discussed in Chapter 7. Although this is not explained fully until Chapter 11 I feel obliged to mention something. When applied, the loop hole x will generate a set of loop les that will be referred to as the \gloop" les. The name \gloop" is used to refer to these les because all of them start with the pre x \gloop." This will also be referred to as the second stage in the loop data analysis. The rst stage is just the extraction of the raw data from the loop les and the generation of the \ oop" les. The third stage is the application of the consistency x discussed in the next section and the generation of the \hloop" les.

5.2.2 Over/Under Counting

When the loop detectors are setup they are calibrated so that they give consistent results - only one car is counted when only one car goes over the detector, the occupancy time reported is correctly, etc. We noticed that there were some loop detectors that were calibrated incorrectly or that were just broken. In some cases the loop detectors were over counting cars and in others they were under counting cars. This can be a problem for anybody trying to do tra c ow models on the data. A program to identify these problems was written by Kumud K. Sanwal. He ran his program on the loop data and generated a set of correction factors that can be applied to the loop data. When it runs, the fsp program can read in these correction factors and x the loop data such that it is consistent as described in the following subsections. Whether or not this x is applied is governed by the run le parameter LOOP_CONSISTENCY_FIX. For a complete discussion of the run le see Chapter 7. The text below explaining the problem was written by Kumud as well. When applied, the consistency x will generate a set of loop les that will be referred to as the \hloop" les. The name hloop is used to refer to these les because all of them start with the pre x \hloop." This is the third stage of the loop data analysis.

5.2.2.1 Data
Data is collected from inductive loops that are embedded in the highway. At a speci c location, each lane contains a pair of loops that are spaced about 14 feet apart, and during operation, have a current owing through them. When a vehicle passes over a loop, the e ective inductance in the circuit changes and this results in a change in the current owing in the loop as shown in Figure 5.5. An adjustable current threshold is set for each loop and the current in the loop is compared to this threshold. Binary data is generated by sampling (at 60 Hz) the result of this comparison. For a desired data output period, the fsp program generates the following information for each interval. The number of vehicles that pass over the loop location in that interval. The fraction of the time in that interval for which the loop is occupied. The mean speeds in that region during that interval.

CHAPTER 5. PROBLEMS WITH THE DATA

detector level Threshold

Time

Figure 5.5: Detector Current Level.

5.2.2.2 Sources of Error

The loop data may have inaccuracies/inconsistencies due to a variety of reasons other than a complete loop malfunction (which are taken care of by the fsp program). Some of these may lead to errors of the following nature: Counts: The loop may not be sensitive enough to detect all the vehicles passing over them and thus may in fact be undercounting. Also, vehicles not in the center of the lane may be missed as is the case of vehicles attempting to change lanes. On the other hand, loops may be detecting vehicles that are on neighboring lanes and hence resulting in some overcounting. Speeds: The resolution with which the time headways can be measured is 1=60 second. This limits the accuracy of measured vehicle speeds. Further, mismatch in tuning of a pair of coupled detectors leads to errors that cannot be compensated for. Occupancies: The detector thresholds may not be tuned properly and this can result in bias in the measured occupancies.

5.2.2.3 Occupancy Correction

The reliability of the densities obtained from the occupancy data provided by the detectors depends on proper tuning of the detector threshold. In the kth interval, the speed v k], the ow per lane q k] and the density k] are related by

q k] = k] v k]
The tra c density k] is proportional to the percent occupancy, occ k], measured by the detector as k] = Kd occ k], where Kd is a constant that depends on the detector. Substituting this into the previous equation and taking logarithms, we obtain

log(q k]) = log(Kd) + log(v k]) + log(occ k])

From the eld data we can nd the least squares regression t for Kd for each of the mainline detectors. These coe cients can be used to compensate the detector errors by using the estimated constant Kd to obtain the actual density.

5.2. THE LOOP DATA

5.2.2.4 Counts Correction

Since vehicles are neither created nor destroyed, we can apply conservation laws for vehicles. If we consider a section of highway which has detectors at the beginning and end as well as on the ramps, then the number of vehicles accumulated over the kth data collection interval is

k + 1]L ; k]L = qin k] ; qout k] + r k] ; s k]

If the detectors on a section of the highway count correctly, then the accumulation should not have a drift (should remain bounded within reasonable numbers, the reasonable depending on the length and number of lanes in the section) since this section of highway can only hold a limited number of vehicles. We compute the average accumulation per minute over a long period (about 4 hours) and if its absolute value exceeds a set threshold, then our algorithm checks the consistency of the detectors associated with that section and compensation factors are computed as a fraction of the ow of the nearest mainline ow. Using these correction factors the fsp program computes ow estimates that satisfy the consistency requirements.

5.2.3 Bad Initialization

The loop data is collected from 5am to 10am and then again from 2pm until 8pm. When the program reports it's statistics for each time interval (a time period could be 1 min or 5 min, etc.) it reports the number of vehicles, the average occupancy time of the vehicles, and the average speed of the vehicles that went over the detector for that speci c time interval. At 5am it turns out that there aren't that many people on the road and it could happen that a whole time interval goes by without a single car going over the detector. If this happens then the loop detector will report the number of vehicles to be zero and the average occupancy to be zero as well - both of these reports are ne. The problem comes when the detectors report the speed for this interval - they will say that the speed is zero. Well, if you are ltering the loop speeds with the loop ltering factor and you come across a speed of zero then this will give you very misleading results. What the program does to correct this is it resets any zero speed from the loop detectors to be the speed from the previous interval. The rst couple of samples in the morning might still have zero speed because nothing came before them, but the results are much better. This is not an run le option - this is on all of the time.

5.2.4 Bad Traps

The loop detector for one lane consists of an upstream and a downstream detector placed about 14 feet apart. Certain pairs of detectors have one of the two traps out, meaning that it always reports zeros. This, of course, causes severe problems: The counts for one lane are computed as the average of the two traps. So if one trap is out then the value reported will be only one half of the correct value. The speeds will all be zero. When calculating the counts and speeds for the whole freeway (meaning the average over all of the lanes) the program will get wrong results.

CHAPTER 5. PROBLEMS WITH THE DATA

We take care of this by programming in the con guration le to only look at the trap that works. This tells the program to do a few things: Report the counts based only on the good detector. Don't use this lane when calculating the average speed. This option is on all of the time - the user can't turn it on and o . The loop con guration le formats are discussed in Section 6.1.4.

5.3 The Incident Data

The only problems that we had with the incident database was that the location of the incidents was not accurate and the starting and ending times were not accurate.

5.3.1 Bad Placement

It turns out that the location of the incidents is not accurate. The way that we attempt to x that is by calling a routine that attempts to correlate the locations of the incidents in the incident database with the locations of the key presses in the car data. Our hope in doing this is that we can get a more accurate location for the incident. In the text that follows I will explain what is meant by correlating the data and the limitations and problems that arise in attempting to do so. What we are trying to do here is to match up two di erent sets of data: the incident database and the data from the probe vehicles. The incident database was generated from the observations of the drivers. Whenever the drivers would pass an incident they would contact a manager by radio and tell them everything they could about the incident: the type of incident, the number of cars involved, the color of the cars, the location, etc. All of this information was written down and stored in what is now called the incident database. The data from the probe vehicles is basically all the les named key.dat. Whenever the drivers of the probe vehicles passed an incident they pressed a key that recorded the location. This information was stored in the key.dat le. So we have a key.dat le for every car, for every shift, and for every day. This constitutes the car data. But there are problems with each set of data. In the incident database the location of the incident is only stored in very general terms like, "a half a mile before A-Street," or "3/4 of a mile past Winton." These distances are based solely on the drivers perception and in our experience they are very inaccurate. When we look at the car data the situation doesn't get much better. Even though there was a key that was pressed when the driver passed an incident, there is no link between a speci c incident and a key press. There is only a marker in the key.dat le that says that a key was pressed when the odometer said a certain value. The odometer reading that is recorded is just the total distance from the start of the shift. So to nd out the exact location on the freeway where the key was pressed we need to do a little more processing. This extra processing involves trying to determine where the vehicle was on the freeway based on other keys that the driver typed in. There is a discussion of these problems in Section 5.1. I would like to brie y list out the points that I made above about the two sets of data:

5.3. THE INCIDENT DATA

Time Distance error bounds

Incident end time

Time error bounds Incident start time

Distance

Incident location

Figure 5.6: Basic Incident Plot. Incident Database

{ Includes a lot of descriptive information including the location. { The location is very vague.
Car data

{ A collection of time and distance stamps that should correspond to incidents.

What the correlation routine will attempt to do is to merge the two data sets to get a more accurate incident location. The way that it does this is it rst de nes a box for each incident in the time-distance plane. This box is centered in distance around the location of the incident recorded in the incident database. The width of the box is the distance error bound that is a function of how accurate we think the data is. The box is centered in time around the recorded time of the incident. The length of the box on the time axis is increased by the amount of the time error bound which is a user settable option. The time error bound is set by the run le parameter TIME ERROR BOUND which is discussed in Chapter 7. Figure 5.6 is a typical picture of an incident plot. Once the program de nes all of the incident boxes on a space-time plot it places all of the key presses from all of the key.dat les for that shift and that day on the plot as well. An example of the key presses from the car data is given in Figure 5.7. The plot on the left in Figure 5.7 is a plot of one run of a probe vehicle down the freeway and back. Since this is a plot of time versus distance, the inverse of the slope is the speed of the vehicle. The steep region in the middle of the run is where the car got o the freeway and turned around. Each \x" is a key press that corresponds to an incident. The plot on the right is just all of the runs for that particular car on one plot. You can see that if you take a vertical line at an incident then it should pass through multiple key presses - these are just the di erent times that the car passed the same incident.

66
One Run

CHAPTER 5. PROBLEMS WITH THE DATA

All Runs

Incidents

Time

Distance

Figure 5.7: Car Trajectories. Finally, the correlation plot is made from combining all of the incident plots for one shift with all of the key press plots for one shift. This is a lot of information and to make it a little more presentable we take out the trajectory of each car and just leave the key presses. Figure 5.8 is a sample of a correlation plot.
Incidents

Correlation plot
Time

Distance

Time

Key presses

Time

Distance
Distance

Figure 5.8: Correlation Plots. Note that the key presses from the key press plots should fall inside of the incident boxes but quite often they don't. Also note that on the nal plots the key presses from a speci c car are all one symbol: car 1: diamond car 2: plus car 3: square

5.3. THE INCIDENT DATA

Old correlation plot New correlation plot

Time 13 14

Distance

Figure 5.9: Fixed Incident Placement. car 4: cross (x) car 5: triangle For an example of a real correlation plot and an explanation of where the les are found see Chapter 16. Once we have made these plots, or in reality, the computer has these plots stored in memory, the program attempts to gure out where the incident actually occurred. It does this by taking the average location of all the key presses that occurred inside of each box. This average location is called the incident location. If an incident doesn't fall within any box then it is not counted at all. There is no attempt to nd the closest box that an incident could be in. It turns out that this process takes a long time. So instead of trying to do this every time that we want to run the program we came up with a di erent scheme. We took all of these plots and printed them out and looked for places where it was obvious that the placement of the incident was wrong. By wrong we mean there was a whole column of key presses just outside of an incident box. If there is no other incident around then we can be pretty much assured that this incident should be on top of these key presses. We then gured out which direction and how far we needed to shift the incident box for the key presses and the box to match up. Note that we only had to get the key presses inside the box in order for the program to work because the routine will take the average of all of the key presses inside of the box no matter where they are. We then coded this shift into a le that can be read at runtime to adjust the location of the incidents. Whether or not this le is read in to adjust the incidents is governed by the run le parameter FIX_INC_LOCATION which is discussed in Chapter 7. An example of this process is given in Figure 5.9. So reading in the runtime le and using it to adjust the incidents is a replacement for running the correlation part of the fsp program. Of course you can still run the correlation part all that you want. You can even gure out which boxes you want to move around and program those into the incident location x le. Simply follow the format described in Chapter 6. Unfortunately the correlation between the incident data and the probe vehicle data

CHAPTER 5. PROBLEMS WITH THE DATA

only gave marginal results. If you look at some of the correlation plots the situation looks pretty hopeless. There are many reasons why things could look so bad: 1. The driver could have pressed a key when there was no incident. 2. The driver could have not pressed a key when there was an incident. 3. The computer might have been broken in a car that reported an incident. This might cause an incident to appear in the database that has no corresponding key presses. 4. The location in the incident database could be wrong. 5. The fsp program might not be able to determine the location on the freeway of the key press in the key.dat le accurately. There are a few things that need to be pointed out about the correlation of the incident data: 1. The routine that does the correlation between the incident database and the probe vehicles is turned on and o by the run le parameter CORRELATE_CARS_DATABASE. 2. If this option is not turned on, then the correlation plots will not be made. For an explanation of the correlation plots see the discussion in Chapter 7. 3. This test does not need to be run in order for everything else to work. The only thing that this test does is adjust the location of the incident by looking at the data that the probe vehicles recorded. If you don't want to adjust this value then don't run these tests - everything else will work just ne. 4. You can also adjust the locations of the incidents by reading in the runtime le with the run le parameter FIX_INC_LOCATION discussed above. 5. The only incidents that this test looks at are the ones passed to it from the incident lter. So you aren't going to get a very good correlation if the incidents that you pick from the lter don't overlap with the days that you pick from the car data. It should be pointed out that what we really need to know is which loop detector was directly upstream of the incident. As you have seen we spend a lot of time trying to adjust the location of the incident and in the end the only granularity that we need is about 1/3 of a mile. Sometimes overkill produces interesting results though.

5.3.2 Bad Duration

Another thing that should probably be corrected in the incident database is the duration of the incidents. Since we only witnessed incidents when a probe vehicle would drive by, we usually don't know when an incident started and ended. The incident duration is obviously longer than the duration that we have in the incident database because those are just times that a car drove by and witnessed the incident. This can be seen in Figure 5.10. In this picture the diagonal lines are the trajectories that the various probe vehicles made. The solid box corresponds to the duration of the incident that we have in the incident database and the dotted line corresponds

5.3. THE INCIDENT DATA

Car trajectories

Time Witnessed incident

Actual incident

Distance

Figure 5.10: Actual Incident and Witnessed Incident. to the actual duration of the incident. The incident actually occurred sometime between when we witnessed it the rst time and when somebody drove by the same spot and didn't witness it. One way to estimate the true incident start and end time is to gure out the average time between any two vehicles and then add one half of this time to the starting time and one half to the ending time. The problem with this is that the headway time is not constant and adding some constant to both sides of the duration might not be the best thing to do. What we could do instead is gure out the last time that a car drove by that didn't witness the incident and then take a certain fraction of this time. The fraction of this time that we usually use is 50% simply because there is no reason to think that start time of the incident isn't uniformly distributed between when we didn't see it and the rst time that we did see it. This method should give you a more accurate approximation to the duration of the incident. Once again, since processing the car data takes a long time we take the familiar route of doing the processing once and then saving the results to a le. This le can then be read in at runtime as a substitution for extracting this information from the car data. The way that this is done is the program will save the last time that a car went by an incident, before it happened and didn't witness it, and the rst time that a car went by an incident, after it had ended and didn't witness it. By saving these two values, the user can still choose various values of the fraction of time to use. When the program saves this information, it saves it to a speci c le named inc.duration.out in the incident data directory. When the program reads this information back in during subsequent runs it reads in the le inc.duration.in, also in the incident data directory. So for the program to use the le that it has generated the user has to manually copy the le inc.duration.out to inc.duration.in. The reason for the two les is to keep the program from overwriting the good data le which took a long time to process (and is very irritating to lose). Of course, doing this method brings up problems of it's own. Since car 2 was broken we never got any location data from it. But since the driver was still driving around the freeway

CHAPTER 5. PROBLEMS WITH THE DATA

1 2 3 Time Witnessed incident Missing car

Actual incident

Distance

Figure 5.11: Incorrect Incident Duration Fix. and reporting incidents we have database entries for a car that we have no tach data from. This could easily mess up the duration calculation. For example, let's say that car 3 drove past an incident and witnessed it just as it was being cleaned up, and that the next two cars to pass the incident were car 2 and then car 1 and neither one of them saw the incident. The correct ending time for this incident should be half of the time between when car 3 passed the incident and witnessed it when car 2 passed the incident and didn't witness it. But since we don't have any data from car 2 the fsp program thinks that the next car that passed by was car 1. Therefore the ending time for this incident will be erroneously in ated. A picture of this is given in Figure 5.11. Finally, to be complete, I should mention that another problem that could show up is the fact that we don't know exactly where the probe vehicles are. This is a fuzziness that we always have due to the fact that the vehicle position is dependent on the drivers pressing a certain set of keys at a particular time. As a result we can't be precisely sure of when a car drove by an incident location. I believe, but don't o er any proof, that we can only be accurate to within 1-2 minutes.

Chapter 6

Program Input: Directory Structure and File Formats

The fsp program uses two di erent main directories when it runs: an input directory and an output directory. There are many subdirectories but these are the top ones. All of the raw data is stored under the input directory and all of the output les are placed under the output directory. Since both the input and the output directories are speci ed by the run le the output can be placed wherever the user likes by simply modifying the appropriate run le parameter. The way that the program used to be run is there was only one main directory for both the input and the output. This meant that the output les were placed in the same directories as the data les. There are a couple of disadvantages in doing this. The rst is that having one main directory for both the input and the output means that the data les are writable by random users. Since the data is usually valuable and hard to replace it would be best if this was not the case. The second reason that having only one directory is bad is that it makes it di cult for multiple users to work with the data. If all of the output is placed in the same directory then whenever the program is run the output is going to be overwritten. In a multiuser environment where people want to be working with di erent types of output (5 minute output versus 1 minute output) this is a huge headache. By allowing users to specify the output directory in the run le they can have the output placed in their own directory and thus avoid having to deal with other users. So far I have only mentioned the main input and output directories. Underneath each of these directories there are a whole host of subdirectories that the fsp program expects to see. The subdirectory structures in the input and output directories are almost the same. The only di erence is the contents: the input directories hold raw data and con guration les and the output directories hold processed data. When the fsp program runs the rst thing that it does is it checks to see if the output directory exists. If it doesn't then the fsp program creates all of the subdirectories that it thinks it's going to need. Since the directory structures are almost the same the output directory is sometimes referred to as the parallel directory structure. 71

72 CHAPTER 6. PROGRAM INPUT: DIRECTORY STRUCTURE AND FILE FORMATS

6.1 The Input Directory Structure

The fsp program expects to see a special input directory structure when it runs. Although some of the directories can be changed by simply changing the appropriate run le variables, most of the structure is already determined. The fsp program also requires the assistance of a few con guration les when it runs. These les must be in the appropriate directories each time the program is run. If you downloaded the software in it's original form and you followed the directions in Chapter 2 then the whole input directory structure will be made for you and all of the con guration les will be put in the correct place. I am including this discussion so that users can understand all aspects of the directories that the fsp program uses. What I will describe in this chapter are the di erent con guration les that are needed and the various input directories that the fsp program expects to see. The example that I will use is the le system that I have on my machine. This is illustrated in Figure 6.1.
Main input directory

Car data

Loop data

Incident data

Runfiles

Figure 6.1: Input FSP Directory Structure. Note that all of the data directories reside under one directory. Also note that the directory labeled \Run les" is only used to hold the di erent run les and incident lters that the user might use. The run les don't need to be stored here and this directory isn't needed by the fsp program. The run les are placed here simply for neatness.

6.1.1 Car Input Directory Structure

The car input directory structure is fairly simple. Below the main car directory there is a con guration directory and one directory for each shift of car data. The location of the main car directory is governed by the run le parameter CAR_DATA_DIRECTORY. My directory structure is shown in Figure 6.2. The directory labeled \Con guration" holds the les needed by the fsp program at startup. These les are described below in Section 6.1.2. The directories labeled \day directory" need a little more explanation. Each one of these directories holds one shift worth of data. For example, one directory might hold the morning shift of February 3rd and another one the afternoon shift of February 3rd. Inside each one of these directories are the directories that corresponds to each car that was in operation on that day. These directories correspond to the boxes in Figure 6.2 that are labeled \car directory." The car directories are usually labeled

6.1. THE INPUT DIRECTORY STRUCTURE

Car data directory

Configuration

day directory

car directory

Figure 6.2: Car Input Directory Structure. \car1," \car2," etc., but this name can be set by the run le parameter CAR_DIRECTORY_ROOT. The car directory structure can be represented with the following picture:
am020393 | |-|-|-pm020393 | |-|-|-<= This is the day directory car1 car2 car3 <= <= <= <= Car directory 1 Car directory 2 Car directory 3 This is the day directory

car1 car2 car3

<= Car directory 1 <= Car directory 2 <= Car directory 3

In the above text there are two day directories, am020393 and pm020393, holding data for the morning and evening shift of February 3rd respectively. Inside of the car directories is the actual data from each car (the four les discussed in Section 4.3).

6.1.2 Car Con guration File Formats

There are two con guration les that the fsp program needs in order to interpret the car data correctly. These are the les DRIVER FILE NAME and CALIBRATION FILE NAME. Both of these le names are de ned in the le fsp.h. Below is a short description of each le:

DRIVER FILE NAME: This le holds the driver names and their identi cation numbers.
The format is:
ID number] First name] Last name]

74 CHAPTER 6. PROGRAM INPUT: DIRECTORY STRUCTURE AND FILE FORMATS The ID number can be any unique valid integer and the driver names need to be in two parts. If you don't have a last name then make up one because the program expects there to be two names. When the drivers type in their ID number for the le key.dat their name will be matched up with that speci c ID. A short sample of the le follows:
1 2 3 4 Hisham Noeimi Dan Rydzewski Ayman Taha Jun Huang

On my system this lename is de ned as:

#define DRIVER_FILE_NAME "drivers.dat"

CALIBRATION FILE NAME: This le holds the calibration data for each car. The caliCar number] Conversion value]

bration value is the number of wheel revolutions per mile. This value allows the program to calculate the real distance traveled. The format is:

The car number needs to be in the range 1 to MAX NUM CARS as de ned in the le fsp.h. If it is not in this range then the program will halt. The value of MAX NUM CARS is currently de ned to be 5. The conversion value should be a valid oating point number. If the program can not nd a value for a car then it will print a warning and the program will probably crash later on due to a divide by zero error. An example of this le follows:
1 2 3 4 5 6019.20 10032.00 6019.20 12038.40 19588.80

On my system this lename is de ned as:

#define CALIBRATION_FILE_NAME "calibration.dat"

6.1.3 Loop Input Directory Structure

The loop input directory structure is quite a bit like the car directory structure. There is a main loop directory below which lie the directories for the individual days and the con guration les. The location of the main loop directory is governed by the run le parameter LOOP_DATA_DIRECTORY. This structure is shown in Figure 6.3. The directory labeled \Con guration" holds the les needed by the fsp program at startup to interpret the loop data correctly. These les are described below in Section 6.1.4.

6.1. THE INPUT DIRECTORY STRUCTURE

Loop data directory

Configuration

loop directory

Figure 6.3: Loop Input Directory Structure. The directories labeled \loop directory" are simply the directories of the various days of loop data. For example, one directory might hold the loop data from February 3rd and another one the data from February 4th. Inside each one of these directories are the data les for each individual cabinet. These are labeled loop1.dat, loop2.dat, loop3.dat, etc. Note that if the les are compressed then they will be labeled loop1.dat.Z, loop2.dat.Z, etc. This structure can be represented with the following picture:
lp020393 | |-- loop1.dat |-- loop2.dat |-- loop3.dat . . lp020493 | |-- loop1.dat |-- loop2.dat |-- loop3.dat . . <= This is a main loop directory <= loop detector 1 <= loop detector 2 <= loop detector 3

<= This is a main loop directory <= loop detector 1 <= loop detector 2 <= loop detector 3

In the above text there are two main loop directories, lp020393 and lp020493, holding data for February 3rd and 4th respectively.

6.1.4 Loop Con guration File Formats

There are many con guration les that the fsp program needs in order to interpret the loop data correctly. These are the display con guration les for the loop cabinets, the wiring diagram les for the cabinet slots, the emission tables, and the geometrics of the road. Below is a list of the various loop con guration les needed:
The data provided by loops are speed, occupancy and counts. Note that there are five lanes with downstream and upstream detectors per lane, which means there are 20

76 CHAPTER 6. PROGRAM INPUT: DIRECTORY STRUCTURE AND FILE FORMATS

Display con guration les: These are the les that tell the program how to interpret the

loop data when it is rst read in and how to display the data when it is printed out. These les came with the original software that Leon Chen wrote and have not been changed since. There are no parameters in these les that can be changed by the user. Therefore I have not listed out their format. These les have names of the format loc_ZZ.cnf. Where \ZZ" is the cabinet number. These les need to be in the directory de ned by the variable LOOPDATA CONFIG DIR in the le fsp_dirs.h. to what lane on the freeway. These les have names of the format loopZZ.wir. Where \ZZ" is the cabinet number. The format of these les is:
Detector number] Up or down] Type] Lane number]

Wiring diagram les: These les are the les that tell the program what slot corresponds

The various legal values are de ned below.

Column Valid Value Explanation

Detector: Up or down: Type:

Lane number:

1 thru 14 0 1 n s f F p P d D q Q b 1 thru 6 0

The detector number Upstream detector Downstream detector Northbound lane Southbound lane South o ramp North o ramp South passage North passage South demand North demand South queue North queue Blank The lane number Blank

Any line in the wiring le starting with a \#" is considered to be a comment line and is ignored. Note that since the program wants you to specify what the upstream and downstream detectors are you need to have a line in this le for every detector. Since there are 14 slots, each with an upstream and downstream detector, that means that there needs to be 28 lines in each one of these les. Also note that the characters used to specify the southbound lanes are all lower case while the characters used to specify the northbound lanes are mostly upper case. The one exception is that \n" means northbound lane. A short sample of the le follows:

6.1. THE INPUT DIRECTORY STRUCTURE

# Loop 16 # Trap Up_or_Down Type Lane 1 0 n 1 1 1 n 1 2 0 n 2 2 1 n 2 3 0 n 3 3 1 n 3 4 0 n 4 4 1 n 4 5 0 n 5 5 1 n 5 6 0 b 0 6 1 b 0 7 0 s 1 7 1 s 1

This sample le is loop16.wir. Note that this is only the rst half of this le. These les need to be in the directory de ned by the variable LOOPDATA CONFIG DIR in the le fsp_dirs.h. Emission Tables: These les hold the tables that are used to do the emission calculations. They are basically tables of the amount of a certain type of emission in grams per hour versus vehicle speed. There is a table for hydrocarbons, nitrogen compounds, and carbon monoxide. The emissions le for carbon monoxide is given below:
# This is the table for the emissions of carbon monoxide. # The values are in grams/mile except for the idle speed # which is grams/minute. # The first row is the idle value for cars, gas trucks, and diesel trucks. # The second row is the speed values. # The third through fifth rows are the values for cars, # gas trucks, and diesel trucks, respectively, for the # speed values in the second row. 3.67 8.81 3.23 5 10 15 20 25 30 35 40 45 50 55 60 44.0 22.5 15.4 11.7 9.3 7.8 6.6 5.8 5.2 4.7 4.3 8.4 105.7 66.4 46.7 35.0 27.6 22.9 20.0 18.3 17.6 17.8 18.8 24.0 38.8 26.7 19.3 14.5 11.5 9.5 8.2 7.4 7.0 7.0 7.3 7.9

Any line that starts with an \#" is a comment line and is not read in by the program. You can see that there is a short explanation of the various values in this le in the comments. As it says in the comments, the rst non-commented row is the idle value of cars, gas trucks, and diesel trucks respectively in grams/minute. The second row is a list of speed values for which data values will be given later. The third through fth rows are

78 CHAPTER 6. PROGRAM INPUT: DIRECTORY STRUCTURE AND FILE FORMATS the values for cars, gas trucks, and diesel trucks for the speed values given in the second row. Note that for space considerations I have left o a few of the speed values and I truncated the precision of the emissions values. LOOP DISTANCE FILENAME: This le holds the distance in feet of each loop detector from the start of the course. The starting point for the course is the intersection of I-880 and Marina. The distance is always increasing, meaning that the northbound loops are the distance from Marina to Whipple and back to the loop. Note that you need to list out all of the cabinets in the southbound and northbound direction separately - you can't have one entry for a cabinet if it has loop detectors in both the southbound and northbound lanes. You need to list that cabinet out as both a southbound and northbound cabinet. Finally, you have to list out the detectors in order. The speci c order that the program is looking for is the order that a car driving around the loop would see if they started at Marina, drove south all the way to Whipple, turned around and drove back to Marina. The format is:
Loop number] Dist] Seg length] South or north] Number of lanes]

Where the loop number is a number from 1 thru 20, and the distance is the distance, in feet, from the starting point of Marina. The segment length is the length, in feet, of the current segment. A segment is the stretch of road covering a loop detector. There is only one loop detector per segment. \South or north" is either SB to indicate that this is a southbound detector or NB to indicate that this is a northbound detector. Finally, \Number of lanes" is simply the number of main line lanes. An example of this le follows:
# Distance Loop Direction #lanes # These distances were typed in on 6/13 # south bound loops 16 15950 1970 SB 5 3 17700 1880 SB 5 1 19400 1700 SB 5 7 21100 1700 SB 5 20 22800 1550 SB 5

Any line that starts with a \#" is treated as a comment line. As you can see by this sample le that the northern most loop detector on the southbound run has to be loop #16. This le needs to be in the directory de ned by the variable LOOPDATA CONFIG DIR in the le fsp_dirs.h. On my system this le is de ned as:
#define LOOP_DISTANCE_FILENAME "loop.distances"

6.1.5 Incident Input Directory Structure and Con guration Files

The incident input directory is only one directory. This directory holds the incident database and the con guration les. You should note that there are some les that are generated by

6.2. THE OUTPUT DIRECTORY STRUCTURE

the fsp program that can be read in later on to x the incident data. While these les are read in by the fsp if you specify the correct parameters in the run le they are not technically con guration les so they will not be discussed further. These les are described in more detail in Chapters 5 and 7. The one true incident con guration le is the le that tells the program what the various elds in the incident database mean. This le is named according to the variable INCIDENT DEFS FILE which is de ned in the le fsp.h. This le is usually named inc_defs.dat. The format of the le is as follows:
field string] = numerical value] = explanation string]

The \ eld string" is the string that is associated with a particular incident database eld. These strings are used when creating an incident lter as described in Chapter 9. Since each incident database eld has a few di erent options there is a line in the inc_defs.dat le for each option. For example, the incident eld that describes the weather has as it's eld string \WEATHER." Since there are ve di erent options the section of the inc_defs.dat le that describes this eld would look like this:
WEATHER WEATHER WEATHER WEATHER WEATHER = = = = = 0 1 2 3 4 = = = = = Clear Partly cloudy Cloudy Light rain Rainy

Unfortunately, things are not as exible as they might seem. It turns out that there needs to be a way to tell the program what kind of data each eld is: whether it's a time, a date, or a single numerical value. This coding is done within the program itself. This makes changing the format of the incident database something that can only be done by a programmer.

6.2 The Output Directory Structure

As was mentioned above, the output directory structure is quite a bit like the input directory structure. The nicest part about the output directories is that they are created by the fsp program at runtime. If you want to place output les in a directory that was used before then that's ne: the fsp program will simply write over the old les. If you want to place the output in a new directory then that's ne as well, the fsp program will create it for you. The incident and car output directories are exactly the same as the input directories with the exception that there are no con guration directories. The loop output directory structure is only slightly di erent than the loop input directory structure. The main loop output directory has a few additional directories that hold various types of output. A graphical representation of the directories is given in Figure 6.4. The directory labeled \Reports" in Figure 6.4 is the summary directory and it holds the summary loop error reports that are described in more detail in Chapter 15. Note that

6.2.1 Loop Output Directory Structure

80 CHAPTER 6. PROGRAM INPUT: DIRECTORY STRUCTURE AND FILE FORMATS

Loop data directory

Average files

Delay files

Reports

loop directory

Figure 6.4: Loop Output Directory Structure. this only holds a certain subset of the loop output text les. The directory labeled \Average Files" contains the average loop les. These les are the average over all of the days of the counts, speeds, occupancies, and densities. These les are needed when calculating the delay with respect to the average. The directory labeled \Delay Files" contains a sub-directory for each main loop directory. These sub-directories contain the delay les for each day with respect to the average. The procedure for computing these les is described in detail in Section 12.7. Finally, the directory labeled \loop directory" holds the output for one speci c day.

Chapter 7

Program Input: The Run le

When the FSP program runs, it takes as one of its arguments the name of a le that is called the run le. The run le contains the commands that tell the program what to do: what data to analyze, what tests to run, what output to generate, etc. This chapter is a reference guide to the various parameters that can be speci ed in the run le. There is a whole set of parameters to the run le that are not listed in this chapter. These are the parameters that deal with the various tests that you can put the loop data through when generating the loop error reports. Since these are all in the same category, and there are quite a few of them, they are described in Chapter 10. Note that if you are going to be using the program xfsp then you don't have to worry about the various names of the run le parameters because the program will create the run le for you. You will have to worry about what each parameter does, but the xfsp program has on-line help that will replace this chapter. Chapter 8 gives a cross reference guide between the xfsp windows and the run le parameter strings that might be helpful.

7.1 The Basic Idea

I wanted the program to be as exible as possible and easy to use. Therefore I decided to make the program highly automatic so that if the user has lots of data that they want to crunch through then they can simply create the appropriate run le and start the program up - everything will be taken care. Unfortunately, the price in software for increased exibility is increased complexity. In this case the complexity manifests itself in the number of run le parameters needed to tell the fsp program what to do. As you read the rest of this chapter you might conclude that so much exibility, and hence so many run le options, just confuses everything. Hopefully, with a little bit of practice, the fsp program will become easy to use. Then again, maybe not.

7.2 How To Use The Parameters

The run le is just a text le that you can edit with any editor. There are a few things about specifying parameters that need to be pointed out: 81

CHAPTER 7. PROGRAM INPUT: THE RUNFILE

To specify a parameter, place it at the start of a new line followed by an equals sign and the chosen value. Spaces do not matter. You can have as many spaces as you want between the parameter, the equals sign, and the chosen value. If you do not specify a value or you leave out a parameter then the default value will be assigned. A list of the default values is given below in Section 7.4. The run le is case sensitive and all of the parameters have to be speci ed in upper case. If you have a parameter on a line then you must have an equals sign on the line as well. You don't have to specify a value for the parameter after the equals sign, but the equals sign must be there. The comment character is the pound sign: #. To comment out a line then just place this character at the start of the line. This is very useful in switching between di erent parameter options when you don't want to retype a di erent value every time. For most of the parameters you just supply one of a few prede ned strings. For some parameters you need to type in your own value. When you do this, just type in your value - don't use quotes, or type casts the program takes care of all of the casting. You can NOT use the logical OR character \j" with the parameters. You can only choose one of the prede ned strings.

An example of specifying the parameter DEBUG LEVEL is given below. Each one of these lines is acceptable.
DEBUG_LEVEL = VERBOSE_DEBUG DEBUG_LEVEL=VERBOSE_DEBUG DEBUG_LEVEL = VERBOSE_DEBUG DEBUG_LEVEL = #DEBUG_LEVEL = DETAIL_DEBUG

In the rst three lines the value of the option DEBUG LEVEL is set to VERBOSE DEBUG. In the fourth line the value of DEBUG LEVEL is set to the default value which is SILENT DEBUG. In the last line the whole line has been commented out. Therefore it is not read by the run le parser and the value is set to the default value. You could have all of these lines in the same run le, but the parameter DEBUG LEVEL would only be set to the last supplied value. Note that in the fourth line above there is no supplied value, so in this case the value would be set to VERBOSE DEBUG. In the examples below we will use a combination of the di erent allowable ways to specify a parameter.

7.3 Parameters To The Run le

What follows is an alphabetical listing of the various run le parameters. The parameter name is in bold face, ush with the margin, and the explanation is indented.

7.3. PARAMETERS TO THE RUNFILE

CAR CLEANUP Specify whether to leave the temporary car les.

This lets you delete intermediate les that were generated when processing the car data or to leave them hanging around. The les that the program generates when grinding through the car data are completely unimportant and don't hold any useful information like the temporary loop les. This option should only be used if you are trying to debug the program. The options are:

DELETE FILES: Delete temporary car les. LEAVE FILES: Leave temporary car les.
The default for this parameter is DELETE FILES.

CAR DATA COMPRESSED Specify whether the car data is compressed or not.

Since the data for this project takes up so much room it is sometimes advantageous to store the raw data in the compressed format. This option will tell the program to expect the data to be in the compressed format or the uncompressed format. The compressed format is the standard UNIX compression format that is done by the programs compress and uncompress. There are a couple of things to note about using this option: You need to have the programs compress and uncompress in your path. If you type the command which compress then it should list out where the program is located. If the program is not in your path then ask your system administrator where it resides. All of the data needs to be compressed or uncompressed. You can't have some of the data compressed and some of the data uncompressed. If you are only going to be working on a small set of data but you are going to be running the program over and over again then you should probably just uncompress the data before you start running the program - it will take too long for the program to do it for you. This option is only useful if you are going to be working with a very large data set and you only want to do the processing once. The process of uncompressing and compressing the car data can take up to 10 minutes for each day. So be warned that the processing time for the whole data set might take a while! The various options are:

DATA NOT COMPRESSED: The data is not compressed. DATA IS COMPRESSED: The data is compressed.
The default for this parameter is DATA NOT COMPRESSED.

CHAPTER 7. PROGRAM INPUT: THE RUNFILE

This is the complete path of the directory that holds the car data. It must also hold the car con guration and report directories. For more information on the directory structure that the fsp program expects see Chapter 6. The default for this parameter is /home/clair0/PATH/FSP/Set1/Cardata. after study. The FSP experiment involved a before and after study of the freeway. Since the data collected from the probe vehicles was di erent in both studies there needs to be a way to tell the program what type of data set to expect. This parameter tells the program if the car data set being used belongs to the before study or to the after study. For a complete explanation of the di erence between the two data sets see Section 4.3. There are two possible values for this parameter, 1 or 2, that correspond to the before and after data sets respectively. The default for this parameter is 1. This is the root name to your car directory. The directory structure looks something like the example below:
am110492 | |-- car1 | |-- car2 | |-- car3 <= This is a car directory <= Sub car dir 1 <= Sub car dir 2 <= Sub car dir 3

CAR DATA DIRECTORY Specify which main car directory to use for the data.

CAR DATA SET NUMBER Specify whether the data set is from the before study or the

CAR DIRECTORY ROOT Specify the car sub-directory name.

Where the car directory is called am110492, and the various subdirectories below it are called car1, car2, and car3. So the name that we are trying to specify with this parameter is the sub-car-directory name. In this example the name is \car". For more information on the directory structure that the program expects to see then see Chapter 6. The default for this parameter is car.

CAR SPD FILTER FACTOR Specify the ltering factor for the car speed data.

When making the plots for the car data of speed vs. time and speed vs. distance it is sometimes useful to lter the data so as to get a better looking plot. The general formula for ltering data looks like this:

xk = xk;1 + sk yk = (1 ; )xk

7.3. PARAMETERS TO THE RUNFILE

Where sk is the current speed measurement, xk is the state variable, is the ltering factor that you are specifying with this parameter, and yk is the nal output variable. This is simply exponential ltering. Some things to note: If the data is ltered then all subsequent analysis will be performed on the ltered data. The value for this parameter has to be 0 < 1. The program will not let you set the variable to 1 because this results in an unstable lter. The larger the value the more smoothing you do. A value of 0 will perform no ltering at all and will give you the actual data. The default for this parameter is 0.9. CORRELATE CARS DATABASE Specify whether to attempt to correlate the incident database with the car data. This tells the program to attempt to correlate the incident database with the data collected from the probe vehicles. We do this to re ne the incident location. If you remember, from Chapter 4, when a probe vehicle went past an incident the driver would radio in the location to the base station and they would also press a key on their keyboard. During the radio call the driver would give the distance as something like, \A half mile before 92," or \3/4 of a mile past Winton." These locations are obviously not accurate. Every time that a di erent probe vehicle would pass the same incident a record would be made at the base station, and in the incident database, of the time that somebody passed it. And when the drivers would press a key, the computer would store the location of the car in a le. So what we have is an incident database entry with a list of times that some probe vehicle passed it and all of the car data les that have times and distances when they passed some incident. What we are attempting to do here is to match up the key presses with the incident log with the ultimate goal of getting a more accurate location for each incident. This process is described in detail in Chapter 5. There are a couple of things to note about this parameter: There are two other parameters that e ect the output of this routine. These are: INC CORRELATION GRAPH and NUMBER INC CORR GRAPHS. The rst parameter tells the program whether to make a graph of the keypresses and the incidents and the second one tells the program whether to put the incident numbers on this plot. Since this routine is working with car data, you have to specify some car data for this to do anything at all. The program has to nd the incidents from the car data in order for the correlation to take place. So the parameter INCIDENT POINTS must be set to YES INCIDENT POINTS. These tests do not need to be run in order for everything else to work. The only thing that this test does is adjust the location of the incident by looking at the data that the probe vehicles recorded. If you don't want to adjust this value then don't run these tests - everything else will work just ne.

CHAPTER 7. PROGRAM INPUT: THE RUNFILE

The correlation of the data take almost as much time as the loop tests. So if you want to run this test then be prepared to wait. The various options for this parameter are:

NO CORRELATE: Don't attempt to correlate the data. YES CORRELATE: Attempt to correlate the data. The default for this parameter is NO CORRELATE. DEBUG LEVEL Specify how much debug information to print out.

This allows the user to receive various levels of diagnostic output in case there is an error. This probably shouldn't be changed at all because the program is completely free of bugs.... well, maybe. The various options are:

SILENT DEBUG: No output at all. MINIMUM DEBUG: Small updates on progress. DETAIL DEBUG: Some updates and more diagnostic output. VERBOSE DEBUG: Prints out everything - this will take forever to run. The default for this parameter is SILENT DEBUG. DELAY CALCULATION Specify what type of loop and incident delay calculation to perform. This parameter tells the program how to calculate the delay for the loop data. The formula for calculating the delay for a particular section of freeway for a speci c time is given below: ! i = L T Fi 1 ; 1 Dk 60 k i V

i Where Dk is the delay on segment k during time slice i, L is the segment length in miles, T is the time slice in minutes, Fki is the ow on segment k during time slice i, Vki is the speed on segment k during time slice i, and VT is the threshold or congestion speed. What this parameters tells the program is whether to use a constant speed for VT or to use the average speed. The constant speed that is used, when required, is given by the run le parameter TRAFFIC LOW SPEED. Note that even though this parameter applies to how the loop delays are calculated, it also applies to which loop delay les the program reads in to calculate the delay per incident. A discussion of how to nd the average speeds as well as the details on how the delay calculation is performed is given in Chapter 11. The various options for this parameter are:

WRT CONSTANT SPEED: Calculate the delay with respect to a constant speed. WRT AVERAGE SPEED: Calculate the delay with respect to an average speed.

7.3. PARAMETERS TO THE RUNFILE

The default for this parameter is WRT CONSTANT SPEED.

DELAY DOWNSTREAM NUM Specify how many downstream detectors to use in the

incident delay calculation. There is no consensus on how to calculate the delay for a speci c incident. What this option allows the user to do is to choose how many detectors downstream of the incident the program should use in calculating the delay. For each incident the program calculates the duration and location. Then, for the whole duration of the incident the program adds up the delay at each loop detector that is close to the incident. The parameter DELAY DOWNSTREAM NUM and DELAY UPSTREAM NUM de ne what is meant by close. This parameter tells the program how many detectors to use downstream of the incident. Normally, one would think that this should be 0 because an incident shouldn't e ect anything downstream, only the stu upstream. Well, as it turns out, you might actually get some bene t downstream from an incident. So we left this decision up to the user. A value of -1 for this parameter means to go all the way downstream to the end of the study section. A more complete description of the delay calculation is given in Chapter 11. The default for this parameter is 0. When the program applies the formula for calculating the loop delay it is possible for the delay to be negative if the current speed is above the congestion speed. It is a debatable point as to whether or not the delay can be negative. We don't attempt to answer that question but we leave it up to the user. This parameter will tell the program to allow negative delays or to make all negative delays zero. The various options are:

DELAY TYPE Specify whether to allow the delay to be negative or not.

ONLY HAVE POSITIVE DELAY: Allow only positive delays. HAVE POSITIVE AND NEGATIVE DELAY: Allow positive and negative delay. The default for this parameter is ONLY HAVE POSITIVE DELAY. DELAY UPSTREAM NUM Specify how many upstream detectors to use in the incident

delay calculation. This parameter tells the program how many loop detectors to use upstream of an incident when calculating the delay for that incident. This parameter is the counterpart to DELAY DOWNSTREAM NUM and you should see the discussion there for a short description. For a more complete discussion of the incident delay calculation see Chapter 11. The default for this parameter is -1. For some reason or another the loop detectors don't work all of the time - they go out sporadically and don't record data. This parameter tells the program to attempt to gure out when those dropout periods occur. It will attempt to do this for all of the data les in each loop directory and it will store the results in one le for that directory. This le is

DROPOUT TIMES Specify whether to gure out the loop data dropout times.

CHAPTER 7. PROGRAM INPUT: THE RUNFILE

called bad.times. See Chapter 15 for an explanation of the output. If error reports are being generated then the dropout information is included at the end of the error report. If you are going to attempt to x the holes in the loop data set with the parameter LOOP HOLES FIX then you need to set this parameter to YES DROPOUT FILE. The various report type options are:

NO DROPOUT FILES: Don't attempt to gure out when the data has blackouts. YES DROPOUT FILE: Attempt to gure out when there are data blackouts. The default for this parameter is NO DROPOUT FILES. EMISSION CALC Specify whether to calculate the loop emissions.

This parameter tells the program whether or not to calculate the emission factors. The emission factors are calculated a lot like the delay values. The formula is given below:

speed as speci ed by the parameter DELAY TYPE. There are three di erent types of emission calculations: Carbon monoxide (CO) Hydrocarbon compounds (VOC) Nitrogen compounds (NITRO) These are described in more detail in Chapter 11. The various options for this parameter are given below:

T i Ek = L 60 Fki eVki ; eVT i Where Ek is the emissions on segment k during time slice i, L is the segment length in miles, T is the time slice in minutes, Fki is the ow on segment k during time slice i, eVki is the emission factor for speed Vki on segment k during time slice i, and eVT is the emission factor for speed VT . Note that VT can be either a constant speed or an average

NO CALC EMISSIONS: Don't calculate any emissions. YES CALC CO EMISSIONS: Calculate carbon monoxide emissions only. YES CALC VOC EMISSIONS: Calculate hydrocarbon emissions only. YES CALC NITRO EMISSIONS: Calculate nitrogen compound emissions only. YES CALC ALL EMISSIONS: Calculate all emissions. The default for this parameter is NO CALC EMISSIONS. ERROR FILE NAME EXT Specify a new extension for the car error les.

This lets you specify a di erent name for the extension of the car error les. This could be useful if you want to try out a di erent error criterion and you don't want to lose the les that you already have. This probably shouldn't be changed. The default for this parameter is err.

7.3. PARAMETERS TO THE RUNFILE

FIX INC DELAY BOX Specify whether to use a prede ned box to calculate the incident

delay. It turns out that there was quite a bit of debate over how to exactly calculate the delay per incident. This parameter gives the user one more way to calculate this. The plots generated by the parameter INC CONTOUR DELAY PLOT are contour plots of the delay in vehicle-hours. So each line type is a speci c level surface. These plots also have the incidents on them as a box. After looking at the delay caused by certain incidents we decided that trying to have the computer automatically gure out the region that contained the delay for each incident was going to be too complex. So we decided that we could de ne a bounding box for each incident by hand and then code that into a le. This le could then be loaded in at runtime and used by the program to calculate the delay for each incident correctly. A couple of things to note about this option: Only certain incidents have a bounding box in the runtime le. This is because it was too hard to gure out what the bounding boxes were for quite a few of the incidents because of overlapping incident. You can de ne more bounding boxes yourself. Just follow the details given in Section 12.11. If you tell the program to use the bounding box le then all of the incidents not de ned in that le will have a delay of zero. A more complete description of the calculation of the incident delays is given in Chapter 11. The various options for this parameter are given below:

NO FIX INC DELAY: Don't read in the bounding box le. YES FIX INC DELAY: Read in the bounding box le and use it to calculate the
delay for the incidents in there. The default for this parameter is NO FIX INC DELAY.

FIX INC DURATION Specify whether to attempt to x the incident duration or not.

This parameter tells the program whether to attempt to x the incident durations or not. Since we only witnessed incidents when a probe vehicle would drive by, we usually don't know when an incident started and ended. The true incident duration is obviously longer than the duration that we have in the incident database because those are just times that a car drove by and witnessed the incident. The incident actually occurred or was cleared sometime between when we witnessed it last and when somebody drove by the same spot and didn't witness it. The way that we attempt to x the duration is to take the di erence between when we witnessed the incident and the last time that a car drove by that didn't witness the incident. We then take a certain fraction of this di erence and add it onto the starting or ending time of the incident. This parameter governs whether or not to do this processing and exactly how to do it. Since the car data takes a long time to process we will try to only do it once. So once we gure out the times from the car data we save them to a le named inc.duration.out.

CHAPTER 7. PROGRAM INPUT: THE RUNFILE

This le will hold two numbers for each incident: the time that a car went by, before the incident occurred, and didn't witness it, and the time that a car went by, after the incident occurred, and didn't witness it. This le can then be read in by the program to substitute for processing the car data. This should save about 4 hours of processing. The one catch is that the le that the program tries to read in is named inc.duration.in. So in order for the fsp program to use this le after it has generated it the user has to manually copy inc.duration.out to inc.duration.in. See the discussion in Section 5.3.2 for a more complete discussion of the problems that this generates.

NO FIX INC DURATION: Don't attempt to x the incident duration at all. FIX INC DURATION FROM DATA: This will attempt to x the incident dura-

tion by reading in the car data and matching up the incidents. This routine will only process the car data that has been speci ed in the run le. In order for this routine to work you HAVE to have generated the time vs. distance les for the car data. This routine will save the output to a le named inc.duration.out that resides in the incident data directory. FIX INC DURATION FROM FILE: This will attempt to x the incident duration by reading in a le that contains the times that cars drove by an incident and didn't witness it. You don't have to do any processing on the car data for this option to work. This le is named inc.duration.in and must reside in the incident data directory. The default for this parameter is NO FIX INC DURATION.

FIX INC LOCATION Specify whether to x the placement of the incidents.

One of the things that the program attempts to do is to re ne the position of the incidents. The standard way of doing this is to read in all of the car data and to try to match up the key presses in the car data with the incident database, as was discussed under the parameter CORRELATE CARS DATABASE. Well, this takes quite a bit of time: someplace on the order of 2 or 3 hours. We have come up with a much faster way of doing this. What we did was rst to produce the correlation plots between the incident data and the car data. These plot are generated for each day and each shift and they have all of the key presses that all of the cars made and all of the incidents on them. We then visually lined up where we thought the incidents belonged. Then we coded this into a le which can be read in at runtime to adjust the position of the incidents. This parameter tells the program whether or not to load in this le and adjust the incidents with it. This is much faster than adjusting the position of the incidents based on the car data each time and the results are the same. The various options are:

NO FIX INC LOC: Don't read in the incident placement x le. YES FIX INC LOC: Read in the incident placement x le and adjust the location
of the incidents accordingly. The default for this parameter is NO FIX INC LOC.

7.3. PARAMETERS TO THE RUNFILE

FLOOP CLEANUP Specify whether to keep the temporary oop les around.

There are three di erent stages that the program can go through when it generates the loop data: the oop, gloop, and hloop stages. There are di erent parameters that determine which of these stages are used. In each stage the program makes some temporary les that can be deleted when the program is done with them. This parameter lets the user decide whether they want the les from a certain stage, the oop stage, to be left on the system. For a complete description of the di erent stages that the program goes through when calculating the loop data see Chapter 11. A couple of things to note: There is basically no reason to leave these les laying around except for debugging purposes or to make sure that the various stages are working correctly. The program will not delete les that it might need later on in the program. For example, if you are going to calculate the delay for the incidents then the program will not allow you to automatically delete the last set of loop les, whatever those may be, because they are going used later on. You can still delete them by hand if you wish. The various options are:

DELETE EVERYTHING: Delete all of the les from the oop stage. DELETE ALL LANES: When the program generates the loop data for the oop stage

it makes a couple of les for each lane in the freeway. This will delete only the lane les. DELETE MAIN LINE ONLY: The program also generates les that correspond to the average over all of the lanes. This will delete only the average les. DELETE RAMPS ONLY: There are les generated for each on and o ramp as well. This option will delete all of the on and o ramp les. DELETE NOTHING: This will leave all of the les from the oop stage.

The default for this parameter is DELETE EVERYTHING.

FSP DATA FILE NAME Specify the name of the fsp data le.

This lets you specify the name of the fsp le that was generated by the computer in the car. This is the le that holds the INRAD data. This probably shouldn't be changed. The default for this parameter is fsp.dat.

GLOOP CLEANUP Specify whether to keep the temporary gloop les around.

This parameter is basically the same as the parameter FLOOP CLEANUP except that it deals with the gloop stage. See the discussion under the parameter FLOOP CLEANUP for a short explanation. See Chapter 11 for a more detailed explanation. The various options are:

DELETE EVERYTHING: Delete all of the les from the gloop stage.

CHAPTER 7. PROGRAM INPUT: THE RUNFILE

DELETE MAIN LINE ONLY: The program generates les that correspond to the

average over all of the lanes. This will delete only the average les. DELETE RAMPS ONLY: There are les generated for each on and o ramp as well. This option will delete all of the on and o ramp les. DELETE NOTHING: This will leave all of the les from the gloop stage. The default for this parameter is DELETE EVERYTHING.

GNU PRINTER Specify which printer to have as the default printer for the plotting.

This is the name of the printer to use when generating the gnuplot les. This only works with a UNIX system and when you are generating plots with gnuplot. See Section 13.1 on making plots with gnuplot for a complete explanation. The default for this parameter is s307 (the printer in my o ce). When the drivers are driving around the course they periodically hit a key that signi es that they passed a certain point in the road that we call gore points. When they hit this special key, it is saved in they key.dat le with a time and distance stamp. Since there are usually two gore points for each direction, one at the start of the run and one at the end of the run, you can gure out the travel time between the two points. If you choose to gure out the gore points then the program does a couple of things: The program picks out all of the gore points from each car. It gures out the travel time for each section from the di erence between the time stamps of two adjacent gore points. It attempts to weed out any mistakes that it detects. This includes multiple hits of gore point keys, missing gore points, and any gore point travel times that are too short. The critical low value is de ned in the le fsp.h by the de ned value GORE LOW THRESHOLD. It is currently de ned to be 200 seconds. If a travel time is less than this value then the program assumes something is wrong and deletes that gore point. It combines all of the valid gore travel times from all of the cars for that shift and makes a plot of travel time vs. run start time for both the south bound tra c and northbound tra c. It places these les in the main car directory. Note that a shift is either morning or afternoon. For information on how to make the plots see Section 13.1.

GORE POINTS Specify whether to nd the gore points or not.

The various options are:

NO CALC GORE POINTS: Calculate points. YES CALC GORE POINTS: Don't calculate points. The default for this parameter is NO CALC GORE POINTS.

7.3. PARAMETERS TO THE RUNFILE

HEADWAY TIME VAL Specify the headway time to use.

Since there were only 4 - sometimes 3 - probe vehicles traveling around the study section there is a granularity in the sighting of incidents. The headway time is the average time between any two probe vehicles. This parameter, which must be speci ed in seconds, allows the user to specify the average headway time. Half of the headway is added to each side of the duration of the incident when calculating the delay. The problem with this is that the variance of the headway is quite large. For a more detailed description of how we calculate the delay per incident see Chapter 11. The default for this parameter is 420.

HLOOP CLEANUP Specify whether to leave the temporary hloop les around.

This parameter is basically the same as the parameter FLOOP CLEANUP except that it deals with the hloop stage. See the discussion under the parameter FLOOP CLEANUP for a short explanation. See Chapter 5 for a more detailed explanation. The various options are:

DELETE EVERYTHING: Delete all of the les from the hloop stage. DELETE MAIN LINE ONLY: The program generates les that correspond to the

The default for this parameter is DELETE NOTHING.

INC CONTOUR DELAY PLOT Specify whether to generate the contour delay plots for

the incidents. We found that a very useful way to visualize the e ect of an incident is to generate a plot of distance versus time that has the incident locations marked as well as the contours of delay (or density) that were calculated from the loop data. This parameter lets the user decided if they want to generate these plots or not. If they do want to generate them then one plot is generated for each shift, direction, and day. So for each day there are four plots made. The incidents that are placed on the plots are only the incidents that make it through the incident lter. For a discussion of the incident lter see Chapter 9, and for a discussion of how we use the contour delay plots see Chapter 11. If you want to generate the contour delay plots then the loop data averages need to have been computed. Section 12.7 gives an example of how this is done. The various options are:

NO INC CONTOUR DELAY PLOTS: Don't generate the contour delay plots. YES INC CONTOUR DELAY PLOTS: Generate the contour delay plots.
The default for this parameter is NO INC CONTOUR DELAY PLOTS.

CHAPTER 7. PROGRAM INPUT: THE RUNFILE

the car data and the incident database. This option will tell the program to generate the incident correlation graphs. This is only relevant if the program is already attempting to correlate the incident database with the car data by using the parameter CORRELATE CARS DATABASE. If that parameter is not set then this option is ignored. The correlation graphs are an easy way to visualize what the program is attempting to do when it is trying to correlate the incident database with the car data. A correlation graph is a plot of the incidents from the incident database with the key presses from the car data on a time versus distance plot. This option will generate one correlation graph for each direction and each shift of car data that is speci ed. The way that these plots are generated is discussed in Chapter 5 and examples of these plots are given in Chapter 11. The various options are:

INC CORRELATION GRAPH Specify whether to generate the graphs from correlating

NO INC CORR GRAPHS: Don't generate the correlation graphs. YES INC CORR GRAPHS: Generate the correlation graphs. The default for this parameter is NO INC CORR GRAPHS. INC DUR EXPAND FRACTION Specify what fraction of time to expand the incident

duration. This parameter is used in conjunction with the run le parameter FIX INC DURATION. When we attempt to x the incident durations we have the time that we last witnessed an incident and the time that a car drove by the same location and the incident wasn't there. This parameter tells the program how much of this time di erence to take and add onto the duration. This is usually set to 50% to indicate that we should just take half of the time. Note that the same analysis is done for the starting time and that both the starting and ending times are expanded. See the discussion in Section 5.3.2 for more details. As was discussed in that section, this method of xing the incident durations gives an estimate of the durations that is biased. The default for this parameter is 50. This parameter is a little di erent from all of the others in that it is a string. It can be multiple words, it can have commas, etc. The only restriction is that it has to be on a single line and it should probably be less than 50 or 60 characters. The restriction on the length is because it probably won't t on the graph if it's too long. The graphs that this title string will be placed on are: The delay vs duration graph. The histogram of the number of incidents vs. duration. The histogram of the percentage of incidents vs. duration. The cumulative distribution of incidents vs. duration.

INC EXPLANATION Specify what title string to put on the incident graphs.

7.3. PARAMETERS TO THE RUNFILE

The default for this parameter is Plot (which is really descriptive).

INC FINISHED GRAPHS Specify whether to make a graph of the delay versus duration
for the incidents. This parameter tells the program whether to generate a graph of the delay versus duration for all of the incidents that passed through the incident lter. For an example of this type of graph see Chapter 16. A couple of things to note: This will only have an e ect if you are already processing the incidents. The only incidents that will be plotted are those that passed through the incident lter. This does not govern whether the three incident histograms are made. Those are generated whenever you process the incidents.

NO FINISHED GRAPH: Don't generate the graph. YES FINISHED GRAPH: Generate the delay vs. duration graph. The default for this parameter is NO FINISHED GRAPH. INC FINISHED OUTPUT Specify where you want the nished textual output from the

incident analysis to go. This option tells the program where to put the nished incident output. The nished output is the output that explains the results of the incident database - probe vehicle correlation, the results of the delay calculation for each incident, a table of delay vs incident duration, and various histograms of the incidents. For a discussion of the nished incident output see Chapter 16. The various options are:

NO FINISHED OUTPUT: This will simply not generate any output at all. FILE FINISHED OUTPUT: This will place the output in a le. SCREEN FINISHED OUTPUT: This will simply place the output on the screen.
This is probably the most useful option. The default for this parameter is NO FINISHED OUTPUT.

INC FINISHED OUT LEVEL Specify what level of nished output you want from the

incident analysis. This option tells the program how much to print out about the nished incidents. The nished incidents are simply the incidents that have been processed. There are quite a few di erent types of output for the nished incidents. For a complete discussion of the output see Chapter 16. The various options are:

INC FIN OUT SPARSE: Don't print out much. INC FIN OUT MEDIUM: Print out the right amount of information. This is what
most people probably want to use.

CHAPTER 7. PROGRAM INPUT: THE RUNFILE

INC FIN OUT VERBOSE: Print out way too much information. The default for this parameter is INC FIN OUT SPARSE. INC GRAPH MAX NUM Specify what the y-axis range should be for the histogram of

the number of cars vs duration. This parameter allows the user to set the vertical axis scale on a certain histogram. The reason that we added this parameter is because we noticed that we wanted to be able to visually compare two di erent plots and that was sort of hard because gnuplot usually sets it's axes scales automatically. The default for this parameter is 10. of the percentage of cars vs duration. This parameter allows the user to set the vertical axis scale on a certain histogram. The reason that we added this parameter is because we noticed that we wanted to be able to visually compare two di erent plots and that was sort of hard because gnuplot usually sets it's axes scales automatically. The default for this parameter is 10.

INC GRAPH MAX PERCENT Specify what the y-axis range should be for the histogram

INC MATCH ZERO WIDTH Specify whether you want to match incidents that were only

witnessed once. This option tells the program whether it should attempt to match incidents that have zero width. The reason that they have zero width is because they were only witnessed once by one driver, so there is only one entry in the incident database. The program can still calculate a value for the delay caused by this incident because it takes into account the probe vehicle headway. The vehicle headway is a run le parameter that the user can set that is an estimate of the time between any two probe vehicles. See the text under HEADWAY TIME VAL for the relevant discussion. Usually, the incidents that are just witnessed once are small events that aren't really going to contribute to any delays. So this parameter lets you weed those out right o the bat. The various options are:

NO MATCH ZERO WIDTH INC: Throw out incidents witnessed once. YES MATCH ZERO WIDTH INC: Process incidents witnessed once. The default for this parameter is NO MATCH ZERO WIDTH INC. INC RAW MATCH OUTPUT Specify where you want the raw output from the incident

analysis to go. This option tells the program where to put the raw incident output. The raw output is the output before any processing is done on the incidents. So it's just a listing of the incidents that made it through the lter. This could be useful if you just wanted to search for di erent types of incidents and you didn't want to bother with calculating the delays. The various options are:

7.3. PARAMETERS TO THE RUNFILE

NO RAW MATCH OUTPUT: This will simply not generate any output at all. FILE RAW MATCH OUTPUT: This will place the output into a le. For a discus-

sion of the raw incident output see Chapter 16. SCREEN RAW MATCH OUTPUT: This will simply place the output on the screen. This is probably the most useful option.

The default for this parameter is NO RAW MATCH OUTPUT.

INC RAW OUTPUT LEVEL Specify what kind of raw output you want from the incident

analysis. This option tells the program how much to print out about the raw incidents. The raw incidents are simply the incidents that made it through the incident lter. The various options are:

want to use because the interesting output is in the nished output. INC RAW OUT MEDIUM: Print some information but not too much. INC RAW OUT VERBOSE: Print out all the elds of the incident database for each incident that was matched. This is quite a bit of information. The default for this parameter is INC RAW OUT SPARSE.

INC RAW OUT SPARSE: Don't print anything. This is probably what most people

INCIDENT DATA DIRECTORY Specify which main incident directory to use.

This is the complete path of the directory that holds the incident data. This directory must also hold the incident con guration les. For more information on the directory structure that the fsp program expects see Chapter 6. The default for this parameter is /home/clair0/PATH/FSP/Set1/Incidents.

INCIDENT POINTS Specify whether to look for the incidents or not.

This will tell the program to look for the incident points in the car data or not. This option must be turned on if you are going to generate the correlation plots between the incident database and the car data. Since this looks in the car data le key.dat, you need to specify some car data for this to have any e ect.

NO INCIDENT POINTS: Don't record the incident locations. YES INCIDENT POINTS: Record the incident locations. The default for this parameter is NO INCIDENT POINTS. INRAD POINTS Specify whether to gure out where the INRAD points are.

In each car is an INRAD system that records whenever the car goes over a speci c radio beacon in the road. These time stamps are placed in the le fsp.dat. This option tells the program to place the INRAD points on the trajectory plots of the cars, and to make a plot of the travel time between INRAD points. Unfortunately, there are only three

CHAPTER 7. PROGRAM INPUT: THE RUNFILE

INRAD points on the whole route: one at the start of the southbound run, one at the end of the southbound run, and one at the start of the northbound run. So we can only calculate travel times for the southbound direction. Another drawback is that the drivers don't always drive over the INRAD loops in the road, so sometimes we can't get any travel times at all. When we can get the INRAD points we use them to aid in guring out where the probe vehicle was when the driver pressed a key to indicate that they were passing an incident.

NO INRAD POINTS: Don't do anything with the INRAD points. YES INRAD POINTS: Determine the INRAD points and mark them on any relevant
plots and generate the travel time plot. The default for this parameter is NO INRAD POINTS.

KEY DATA FILE NAME Specify the name of the keyed in le.

This lets you specify the name of the keyed in data le. This le holds all of the key presses that the drivers made while on their runs. This lename probably shouldn't be changed. The default for this parameter is key.dat. lay and ow. This option will tell the program to calculate the total delay and ow for all of the loop detectors for a xed time period. There are two time periods that the program uses: a morning period and an evening period. The morning period is from 6:30am until 9:30am and the evening period is from 3:30pm until 6:30pm. These times correspond to the times that we had probe vehicles on the freeway. We only looked at these times because we wanted to know the aggregate ow and delay only for the times that we knew there were incidents. To nd these aggregate values the program simply reads in all of the loop delay and ow les that have been calculated and sums up the values for the xed time period. This is done for each set of loop data speci ed. This will also sum up over all of the loop data sets speci ed. This should give you a feel for how much delay was taking place over certain days. The various options are:

LOOP AGGREGATE VALUES Specify whether you want to calculate the aggregate de-

NO CALC AGGREGATE VALUES: Don't calculate the aggregate delay and ow. YES CALC AGGREGATE VALUES: Calculate the aggregate delay and ow. The default for this parameter is NO CALC AGGREGATE VALUES. LOOP AVERAGE Specify whether to calculate the averages from the loop data.
This option will tell the program whether to calculate the average values for the speeds, counts, occupancies and densities. For each di erent data type the average is calculated at each time of day with respect to the various days. For example, if you started o with

7.3. PARAMETERS TO THE RUNFILE

four days worth of speed data that covered the time period from 8am until 10am in steps of 1 minute then this routine would calculate the average speed over the four days from 8am until 10am in steps of 1 minute. So the average speed value at 8am would be the average of four values, each one corresponding to the speed of the di erent days at 8am. These average values are used by the fsp program in a few di erent ways. The rst way is in the calculation of the delay with respect to the average. The fsp program needs to know what the average speed is before it can calculate the delay this way. For a complete example of how to calculate the averages and to then use them to calculate the delay with respect to the average see Section 12.7. The second way the averages are used is in the generation of the contour delay plots. If the run le parameter INC CONTOUR DELAY PLOT is set properly then the fsp program will generate various contour plots that give a space-time picture of the density around an incident. The contour delay plots are described in more detail in Chapter 16. There is an average le created for every loop detector for each value. These average les are placed under a special directory named \Avg" that lies under the main loop output directory. These les are named according to the following scheme: WloopX.YZa. Where we have the following:

W: is either \g" or \h" corresponding to the gloop or hloop les. The gloop les are the
loop les with the holes xed and the hloop les are the gloop les that have been xed to be consistent. X: is the loop number. Y: is either \n" for northbound or \s" for southbound. Z: is either \s," \c," \o," or \d," for speeds, counts, occupancies or densities respectively.

For example, the le holding the average speed for xed northbound loop data at detector #17 would be named gloop17.nsa. There are a few things to note about creating the averages: The averages are created for only the speeds (mph), counts (vehicles/lane/hour), occupancies (%), and densities (vehicles/mile). The fsp program can only make the averages for the loop data with the holes lled in. That means that the loop data le pre x needs to be either \g" or \h" in order for this to work. If you attempt to make the averages for the data with the hole not lled in then the program will crash. The fsp program will only make the average for the loop data sets that were declared in the run le. This means that if you are only working with a subset of the data and you tell the program to compute the averages then the program will compute the averages on only a subset of the data - the original averages, if there were any, will be overwritten.

NO LOOP AVERAGE: Don't calculate the loop averages. YES LOOP AVERAGE: Calculate the loop averages.

100

CHAPTER 7. PROGRAM INPUT: THE RUNFILE

The default for this parameter is NO LOOP AVERAGE.

LOOP CONSISTENCY FIX Specify whether you want to attempt to x the consistency

errors in the loop data. It turns out that there are certain loop detectors that consistently over counted or under counted the cars going over them. To correct this problem we allow the user to read in a set of prede ned les that tell the program how to correct for these consistency errors. This is explained in detail in Section 5.2.2. If this is turned on then this constitutes the third stage in the loop data processing. There are a couple of things to note about the algorithm that does the consistency x: You can only run the consistency x after the loop hole x has been run. So you need to set up the program to run the hole x algorithm at the same time that you want to run the consistency x. See the discussion under LOOP HOLES FIX. The consistency x is only run on the averages across the lanes, not the individual lane les themselves. You need to have the consistency x tables in place in order for this to run. See the discussion in Chapter 6.

The various option are:

NO FIX CONSISTENCY ERRORS: Don't attempt to x the consistency errors. YES FIX CONSISTENCY ERRORS: Attempt to x the consistency errors.
The default for this parameter is NO FIX CONSISTENCY ERRORS.

LOOP DATA COMPRESSED Specify whether the loop data is compressed or not. DATA NOT COMPRESSED: The data is not compressed. DATA IS COMPRESSED: The data is compressed.
The default for this parameter is DATA NOT COMPRESSED.

This will allow the user to store the loop data in the compressed format. See the discussion under CAR DATA COMPRESSED for the relevant information. The various options are:

LOOP DATA DIRECTORY Specify which main loop directory to use.

This is the complete path of the directory that holds the loop data. It must also hold the loop con guration and report directories. For more information on the directory structure that the fsp program expects see Chapter 6. The default for this parameter is /home/clair0/PATH/FSP/Set1/Loopdata.

LOOP HOLES FIX Specify whether you want to attempt to x the holes that show up in
the loop data.

7.3. PARAMETERS TO THE RUNFILE

101

This parameter will tell the program to attempt to x the holes in the loop data or not. It does this by guring out where there is missing data and then making up for it by using the data that surrounds it (i.e. the adjacent loop detectors). This routine will read in the oop les, which are the 1st stage in the loop data processing, and then generate the gloop les, which are the 2nd stage in the loop data processing. Whether the program does the third stage of loop processing is determined by the run le parameter LOOP CONSISTENCY FIX. In order for the hole x routine to work correctly you need to set a couple of parameters: LOOP FLOW PLOTS needs to be set to YES CALC ALL FLOW PLOTS. This tells the program to generate the oop les. LOOP TEXT needs to be set to LOOP ERR REPORT ONLY. This tells the program to process the oop les. DROPOUT TIMES needs to be set to YES DROPOUT FILE. This tells the program to gure out where the holes in the data are. LOOP HOLES FIX needs to be set to YES FIX HOLE ERRORS. This tells the program to attempt to x the oop les based on what dropout times it was passed. This will generate the gloop les. So what this routine will do is generate a set of loop les exactly like the oop les except that they are named the gloop les and there shouldn't be any holes in the data. Also note that the gloop les don't have the individual on and o ramp data les. These have been compressed into two le types: the on counts and the o counts. For a complete explanation of the procedure to x the loop holes see Chapter 5. The various options are given below:

NO FIX HOLE ERRORS: Don't attempt to x the holes in the loop data. YES FIX HOLE ERRORS: Attempt to x the holes in the loop data.
The default for this parameter is NO FIX HOLE ERRORS.

LOOP DIRECTORY Specify a main loop directory to process.

This is one of the two commands that specify data sets for the program to work on (the other one being MAIN DIRECTORY). This one speci es a loop directory to work on. Just like the car directories, you can have multiple loop directories for each run le. These directories all need to be subdirectories of LOOP DATA DIRECTORY. The rst entry after the equals sign should be the name of the loop directory. After that, the numbers of the loop les for that day should be placed in a row with spaces between each number. An example of specifying several di erent loop directories is given below:
LOOP_DIRECTORY = lp031793 1 2 3 4 5 6 7 8 9 10 LOOP_DIRECTORY = lp031893 1 2 3 4 5 6 7 8 9 10 LOOP_DIRECTORY = lp031993 1 2 3 4 5 6 7 8 9 10

102

CHAPTER 7. PROGRAM INPUT: THE RUNFILE

In this example there were three loop directories that were speci ed and all of them contained data for the loop detectors 1 thru 10. The operations that are de ned in the rest of the run le will be performed on all three of these directories. Some things to point out: The loop directories have to reside in the directory speci ed in the run le parameter LOOP DATA DIRECTORY. See Chapter 4 on downloading the data and Chapter 6 on the directory structure for more details. Even though this command speci es the loop data set it doesn't tell the program what to do with the data. So if you aren't getting any output then try to specify one of the following commands: LOOP TEXT, or LOOP FLOW PLOTS.

LOOP FILTER FACTOR Specify the ltering factor for the loop data.

This is exactly the same principle as the parameter CAR SPD FILTER FACTOR except that this is for the loop data. See the discussion there for an explanation of the algorithm used. This lter will be applied to all of the loop data the speeds, occupancies, and counts. All analysis and error checking will be performed on the ltered data. The default for this parameter is 0.9. This is one of the options to control what kind of data to extract from the loop data. The other one is LOOP TEXT. TEXT. The loop data contains occupancies, speeds, and counts for every main line lane, and every demand and passage detector. This option will dictate what gets extracted into various les for generating plots. The output period for the data set is governed by the parameter LOOP OUTPUT PERIOD and the time period by LOOP START TIME and LOOP END TIME. Once the plots are generated they can be viewed on the screen or printed, using the gnuplot program, to the printer speci ed by the parameter GNU PRINTER. See Section 13.1 on gnuplot for further information on printing and viewing the les. The various options are:

LOOP FLOW PLOTS Specify what kind of plots to make from the loop data.

NO CALC LOOP FLOW PLOTS: Don't generate any plots at all. YES CALC OCC FLOW PLOTS: Generate only the plots for occupancy. YES CALC SPD FLOW PLOTS: Generate only the plots for speed. YES CALC PPS FLOW PLOTS: Generate only the plots for PPS or counts. YES CALC ALL FLOW PLOTS: Generate all of the plots. The default for this parameter is NO CALC LOOP FLOW PLOTS. LOOP END TIME Specify the ending time of the loop data set.
This is the ending time, in seconds since midnight, of the loop data. The default for this parameter is 72000 (8:00pm).

7.3. PARAMETERS TO THE RUNFILE

103

LOOP OUTPUT PERIOD Specify the output period for the loop data set.

This is the output time period for the loop data. The output period is the period at which the data is generated. This value has to be between 1 and 3600 seconds. Note that all of the data generated from the loop data will have this period. The default for this parameter is 60 seconds. This is the starting time, in seconds, of the loop data. This time is in seconds measured from midnight the night before. The default for this parameter is 18000 (5:00am).

LOOP START TIME Specify the starting time of the loop data set.

LOOP TEXT Specify what kind of reports to generate from the loop data.

This allows the user to focus in on a detailed section of the loop data and to extract data from it. This is one of the two commands that actually extract information from the loop data. The other one is LOOP FLOW PLOTS. With this parameter one can focus in on a speci c time by specifying the parameters LOOP START TIME, for the starting time, LOOP END TIME, for the ending time, and LOOP OUTPUT PERIOD for the output period. The output will then be generated for that period of time. Note that these are also the variables that govern over what time period the LOOP FLOW PLOTS are generated. The various options are:

LOOP NO REPORTS: No output at all. LOOP ERR REPORT ONLY: Only print out the error report. LOOP TEXT REPORT ONLY: Only print out the loop data. Using this will just
convert the loop data from raw form to text form. LOOP BOTH REPORTS: Do both reports. The default for this parameter is LOOP NO REPORTS.

MAIN DIRECTORY Specify a main car directory to process.

This is one of the two commands that specify data sets for the program to work on (The other one being LOOP DIRECTORY). This one speci es a car directory to work on. You can have multiple car directories speci ed for each run le, you just need to put a line in the run le for each main car directory that you wish to process. Since this is not a parameter that has default values the format of this statement is important. The rst entry after the equals sign should be the name of the car main directory. After that, the numbers of the car directories should be placed in a row with spaces between each number. An example of specifying several di erent main car directories is given below:

104
MAIN_DIRECTORY MAIN_DIRECTORY MAIN_DIRECTORY MAIN_DIRECTORY MAIN_DIRECTORY MAIN_DIRECTORY = = = = = =

CHAPTER 7. PROGRAM INPUT: THE RUNFILE

am031793 pm031793 am031893 pm031893 am031993 pm031993 1 1 1 1 1 1 3 4 4 4 3 3 4 5 5 5 5 4 5 4 5

In this example there were six main directories that were speci ed. All of the operations that are de ned in the rest of the run le will be performed on all of the directories. Some things to point out: The main car directories have to reside in the directory speci ed in the run le parameter LOOP DATA DIRECTORY. Since you have to specify which main car directories you are talking about, there is no default value for this parameter. Therefore you have to specify a directory if this parameter is going to be in the run le. Even though this command speci es the car data set it doesn't tell the program what to do with the data. So if you aren't getting any output then try specifying some commands.

NAV DATA FILE NAME Specify the name of the nav.dat data le.

This lets you specify the name of the navigation data le. This is the le that holds the data that was taken from the PC in the car. This le should be in the raw data format. This probably shouldn't be changed. The default for this parameter is nav.dat. correlation graphs. This option will tell the program to place the incident numbers on the incident correlation graphs. This is only relevant if the program is already attempting to correlate the incident database with the car data and is trying to make the correlation plots. If those options are not set then this option is ignored. If this option is set then the program will place the incident number on the lower left hand corner of each incident box. The reason that you might not want to use this option is because when there are a lot of incidents and a lot of key presses it might become really hard to see the numbers. For a more thorough discussion see Chapter 11. The various option are given below:

NUMBER INC CORR GRAPHS Specify whether to put the numbers on the incident

NO NUMBER INC CORR GRAPHS: Don't place the numbers on the incident YES NUMBER INC CORR GRAPHS: Place the numbers on the incident correlation graphs. The default for this parameter is NO NUMBER INC CORR GRAPHS. correlation graphs.

7.3. PARAMETERS TO THE RUNFILE

105

OUTPUT DIRECTORY Specify which directory to use for the output.

This is the complete path of the directory that will hold the output from the fsp program. One of the rst things that the fsp program does when runs is it creates a mirror of the input data directories under the output data directory. Then, all of the output data, meaning the graphs, the text, the error reports, etc., is place in this directory. This is done so that multiple users can process the data without having to worry about messing up other users. The only requirement is that the stem of the output directory must already exist. The stem directory is assumed to be the rst directory up from the output directory. So if the output directory is /home/data/FSP/Output then the stem directory is assumed to be /home/data/FSP. The directory named Output may or may not exist. If it does exist then that's ne. If it doesn't then the fsp program will create it. For more information on the directory structure that the fsp program expects see Chapter 6. The default for this parameter is /home/clair0/PATH/FSP/Out1.

OUTPUT FLOW AVG FACTOR Specify whether the counts value in the loop data is

per second or per output period. When displaying the PPS value from the loop data you can either have this value mean pulses per second, or pulses per period. If you are trying to generate a plot of the volume of cars ( eg: cars/lane/hour ) then you need this value to be MATCH OUTPUT PERIOD. This will make the value of PPS be the number of cars that have passed over the detector in the current time period. For example, if the value of LOOP OUTPUT PERIOD was 60, meaning a data point is spit out every 60 seconds, and the value of OUTPUT FLOW AVG FACTOR was MATCH OUTPUT PERIOD then the PPS values are the number of counts per output period, which in this case is 60 seconds. In another example, let's assume that the value of LOOP OUTPUT PERIOD was 4 seconds. And that during each of the rst two seconds there was 1 car that went over the detector and then during the last two seconds there were no cars that went over the detector. If the value of OUTPUT FLOW AVG FACTOR was PER ONE SEC then the PPS value would be 0.5 cars/sec. If the value of OUTPUT FLOW AVG FACTOR was MATCH OUTPUT PERIOD then the PPS value would be 2 cars/output period. Note if OUTPUT FLOW AVG FACTOR is set to MATCH OUTPUT PERIOD that when you generate the les for the counts data then the individual lane and the on and o ramp data is in counts/output period but that the le for the aggregate ow on the main line is counts/hour/lane. The various options are:

MATCH OUTPUT PERIOD: Causes the true number of cars that went over the

detector in the time period to be displayed as the PPS value. For all of the analysis routines the program expects that this setting will be used. PER ONE SEC: Causes the PPS value to be the number of counts per second, averaged over the output period. The default for this parameter is MATCH OUTPUT PERIOD.

106

CHAPTER 7. PROGRAM INPUT: THE RUNFILE

diesel trucks. This allows the user to specify what percentage of vehicles on the freeway were diesel trucks. This information is used in the calculation of the emission factors. The types of vehicles on the freeway are either passenger cars, diesel trucks, or gas trucks. Since the percentage of diesel trucks and gas trucks are speci ed in the run le, the percentage of passenger cars is just whatever is left over. The default for this parameter is 2.0. trucks. This allows the user to specify what percentage of vehicles on the freeway were gas trucks. See the discussion under PERCENT DIESEL TRUCKS. The default for this parameter is 3.0.

PERCENT DIESEL TRUCKS Specify the percentage of vehicles on the freeway that are

PERCENT GAS TRUCKS Specify the percentage of vehicles on the freeway that are gas

PROCESS INCIDENTS Specify whether to do any processing on the incidents.

This option tells the program whether to process the incidents or not. If you want to do anything with the incidents then this has to be turned on. If this is turned on then the program will read in the incident lter and the incident database and attempt to lter the incidents. Once it has done that it will x the placement of the incidents if told to do so, and then it will attempt to correlate the incidents with the car data if told to do so. Then the program will calculate the delay for each incident. Whether any of this is displayed to the user is determined by the various incident output parameters.

NO PROC INCIDENTS: Don't do any incident processing. YES PROC INCIDENTS: Process the incidents. The default for this parameter is NO PROC INCIDENTS. REPORT OPTION Specify what type of car data diagnostics to perform.

When the program runs it tries to determine if the car data is valid or not. This parameter tells the program what kind of error reports to generate on the car data. You can make a total of four di erent types of reports varying from short and not very informative to long and detailed or you can make all four reports. The various report type options are:

name, start time, gps data results, etc. HUGE REPORT ONLY: Will print out a very detailed report about every car and every run the car makes. KEY REPORT ONLY: Will print out a very detailed report about the key strokes that the drivers typed in during their runs. This will only be generated if the car data set is of type 2. See Section 4.3 for a discussion of the di erent car data sets.

SHORT REPORT ONLY: This only lists out what data was collected. MEDIUM REPORT ONLY: Will print out a report about every car listing the driver

7.3. PARAMETERS TO THE RUNFILE

107

EVERYTHING: This makes all of the reports.

The les are saved in the directory \Reports" under the car output directory. For more information on the expected directory structure see Chapter 6. The various les are named with the following scheme: fkey,huge,med,smgZZZZZ.err. This means that the rst few characters are either key, huge, med, or sm corresponding to the key, huge, medium, or small report. The Z's correspond to the 3rd through 7th characters of the run le that was speci ed for this run. That might seem a little strange but you need to remember that the whole process is under computer control from the data disks to the nal reports and this ts into the scheme very nicely. For example, if the run le was called rf09230.run, then the car error reports would be called:
key09230.err huge09230.err med09230.err sm09230.err

For more information on the naming scheme of the run les and the whole process in general see Chapter 17. The default for this parameter is EVERYTHING.

SPEED DIST PLOTS Specify whether to make distance vs. time plots of the car trajectory.
This option is exactly like the SPEED TIME PLOTS option except that it tells the program whether to generate the distance vs. time plots of the car data or not. If the data is ltered by specifying something for the parameter CAR SPD FILTER FACTOR then the ltered data is plotted. The incidents, from the key presses, are always recorded and plotted on the distance vs. time plot. If the parameter INRAD POINTS is set to the value YES INRAD POINTS then the INRAD points are also plotted. The various options are:

NO SPEED DIST PLOTS: Don't generate the plots. YES SPEED DIST PLOTS: Generate the plots. The default for this parameter is NO SPEED DIST PLOTS. SPEED TIME PLOTS Specify whether to make speed vs. time plots of the car trajectory.
This option tells the program whether to generate the speed vs. time plots of the car data or not. If the data is ltered by specifying something for the run le parameter CAR SPD FILTER FACTOR then the ltered data is plotted. The incidents, from the key presses, are always recorded and plotted on the speed vs. time plot. If the parameter INRAD POINTS is set to YES INRAD POINTS then the INRAD points are also plotted. The various options are:

NO SPEED TIME PLOTS: Don't generate the plots.

108
Time

CHAPTER 7. PROGRAM INPUT: THE RUNFILE

Distance error bounds

Incident end time

Time error bounds Incident start time

Distance

Incident location

Figure 7.1: Basic Incident Plot.

YES SPEED TIME PLOTS: Generate the plots. The default for this parameter is NO SPEED TIME PLOTS. TIME DIST PLOTS Specify whether to make the time vs. distance plots of the car trajectory. This option tells the program whether to generate the time vs. distance plots of the car data or not. If the data is ltered by specifying something for the run le parameter CAR SPD FILTER FACTOR then the ltered data is plotted. The incidents, from the key presses, are always recorded and plotted on the speed vs. time plot. If the parameter INRAD POINTS is set to YES INRAD POINTS then the INRAD points are also plotted. The various options are:

NO TIME DIST PLOTS: Don't generate the plots. YES TIME DIST PLOTS: Generate the plots. The default for this parameter is NO TIME DIST PLOTS. TIME ERROR BOUND Specify the time error bound for the incident correlation analysis.

This option will tell the program to expand the size of the incident box in the time domain for the routine that does the correlation between the incident database and the car data. This parameter can be seen in Figure 7.1. This parameter expands the region of the time-distance space that the program searches for key presses to match. This option is useful if the clocks on the cars were not synchronized with each other and with the person recording the information for the incident database. Note that the time error bound is added to both sides of the box. It is obvious that if this bound is too large then the program will start to match key presses that should not be matched. For a discussion of the correlation procedure see Chapter 5. The default for this parameter is 600.

7.4. DEFAULT PARAMETERS VALUES

109

TRAFFIC DELAY Specify whether to calculate the loop tra c delay or not.

This tells the program whether to calculate the loop delay or not. Note that this option only tells the program whether to physically go through and generate the loop delay les from the loop ow les. It does not tell the program whether to use a constant speed or the average speed as the threshold. The reason for this is because the calculation of the delay for each individual incident relies only on what sort of reference speed you are using. It does not care if the program has calculated the the loop delay les during this run - they could have been calculated once a long time ago. Even though this may seem like a useless option it can save you time because you won't have to calculate the loop delay les multiple times. Note that the loop delay is not the same as the delay per incident. To calculate the loop delay the program simply reads in the loop les and calculates the delay for each loop segment for each time slice and saves this to another le. The delay per incident calculation looks at speci c parts of these les to gure out the delay for a speci c incident. For a complete discussion of how the loop delay is calculated see Chapter 11. The various options are:

NO CALC TRAFFIC DELAY: Don't calculate the loop tra c delay. YES CALC TRAFFIC DELAY: Calculate the loop tra c delay. The default for this parameter is NO CALC TRAFFIC DELAY. TRAFFIC LOW SPEED Specify the congestion speed.

This parameter lets the user specify what the congestion speed, in miles per hour, should be when calculating the loop delay. In order for this parameter to have any e ect the run le parameter DELAY CALCULATION should be set to WRT CONSTANT SPEED. See the discussion under the parameter DELAY CALCULATION for a short discussion of what TRAFFIC LOW SPEED does. For a more thorough discussion see Chapter 11. The default for this parameter is 60.

7.4 Default Parameters Values

Tables 7.1 - 7.5 are just a list of the default values for the various parameters. You can cause the default value to be used by either not including the parameter name in the run le or by including the parameter name and an equals sign and then nothing else. If there is a blank space where the default should be then that means that there is no default and you have to specify a value.

7.5 Summary Of Parameter Values

Tables 7.6 - 7.14 are just a summary of all of the parameters and their options. You should probably print this little section out for future reference. If the option has an \*" then that means that you need to provide either a numerical value or a string.

110

CHAPTER 7. PROGRAM INPUT: THE RUNFILE

Parameter CAR DATA DIRECTORY DEBUG LEVEL GNU PRINTER INCIDENT DATA DIRECTORY LOOP DATA DIRECTORY OUTPUT DIRECTORY

Default Value /home/clair0/PATH/FSP/Set1/Cardata SILENT DEBUG s307 /home/clair0/PATH/FSP/Set1/Incidents /home/clair0/PATH/FSP/Set1/Loopdata /home/clair0/PATH/FSP/Out1

Table 7.1: Default values for the main parameters.

Parameter CAR CLEANUP CAR DATA COMPRESSED CAR DATA SET NUMBER CAR DIRECTORY ROOT CAR SPD FILTER FACTOR ERROR FILE NAME EXT FSP DATA FILE NAME GORE POINTS INCIDENT POINTS INRAD POINTS KEY DATA FILE NAME MAIN DIRECTORY NAV DATA FILE NAME REPORT OPTION SPEED DIST PLOTS SPEED TIME PLOTS TIME DIST PLOTS

Default Value DELETE FILES DATA NOT COMPRESSED 1 car 0.9 err fsp.dat NO CALC GORE POINTS NO INCIDENT POINTS NO INRAD POINTS key.dat nav.dat EVERYTHING NO SPEED DIST PLOTS NO SPEED TIME PLOTS NO TIME DIST PLOTS

Table 7.2: Default values for the car parameters.

7.5. SUMMARY OF PARAMETER VALUES

111

Parameter DELAY CALCULATION DELAY TYPE DROPOUT TIMES EMISSION CALC FLOOP CLEANUP GLOOP CLEANUP HLOOP CLEANUP LOOP AGGREGATE VALUES LOOP AVERAGE LOOP CONSISTENCY FIX LOOP DATA COMPRESSED LOOP HOLES FIX LOOP DIRECTORY LOOP FILTER FACTOR LOOP FLOW PLOTS LOOP END TIME LOOP OUTPUT PERIOD LOOP START TIME LOOP TEXT OUTPUT FLOW AVG FACTOR PERCENT DIESEL TRUCKS PERCENT GAS TRUCKS TRAFFIC DELAY TRAFFIC LOW SPEED

Default Value WRT CONSTANT SPEED ONLY HAVE POSITIVE DELAY NO DROPOUT FILES NO CALC EMISSIONS DELETE EVERYTHING DELETE EVERYTHING DELETE NOTHING NO CALC AGGREGATE VALUES NO LOOP AVERAGE NO FIX CONSISTENCY ERRORS DATA NOT COMPRESSED NO FIX HOLE ERRORS 0.9 NO CALC ALL FLOW PLOTS 72000 60 18000 LOOP NO REPORTS MATCH OUTPUT PERIOD 2.0 3.0 NO CALC TRAFFIC DELAY 60

Table 7.3: Default values for the loop parameters.

112

CHAPTER 7. PROGRAM INPUT: THE RUNFILE

Parameter DELAY DOWNSTREAM NUM DELAY UPSTREAM NUM FIX INC DURATION FIX INC LOCATION HEADWAY TIME VAL INC DUR EXPAND FRACTION INC EXPLANATION INC FINISHED GRAPHS INC FINISHED OUTPUT INC FINISHED OUT LEVEL INC GRAPH MAX NUM INC GRAPH MAX PERCENT INC MATCH ZERO WIDTH INC RAW MATCH OUTPUT INC RAW OUTPUT LEVEL PROCESS INCIDENTS

Default Value 0 -1 NO FIX INC DURATION NO FIX INC LOC 420 50 Plot NO FINISHED GRAPH NO FINISHED OUTPUT INC FIN OUT SPARSE 10 10 NO MATCH ZERO WIDTH INC NO RAW MATCH OUTPUT INC RAW OUT SPARSE NO PROC INCIDENTS

Table 7.4: Default values for the incident parameters.

Parameter CORRELATE CARS DATABASE FIX INC DELAY BOX INC CONTOUR DELAY PLOT INC CORRELATION GRAPH NUMBER INC CORR GRAPHS TIME ERROR BOUND

Default Value NO CORRELATE NO FIX INC DELAY NO INC CONTOUR DELAY PLOTS NO INC CORR GRAPHS NO NUMBER INC CORR GRAPHS 600

Table 7.5: Default values for the analysis parameters.

7.5. SUMMARY OF PARAMETER VALUES

Parameter CAR DATA DIRECTORY GNU PRINTER DEBUG LEVEL Options * * SILENT DEBUG MINIMUM DEBUG DETAIL DEBUG VERBOSE DEBUG * * * Table 7.6: Summary of main parameters. Parameter CAR DATA SET NUMBER CAR DIRECTORY ROOT CAR SPD FILTER FACTOR ERROR FILE NAME EXT FSP DATA FILE NAME KEY DATA FILE NAME MAIN DIRECTORY NAV DATA FILE NAME Options 1 or 2 * * * * * * * Explanation Explanation Car data dir

113

Printer name for plots Debug stu ... - Be very, very quite - Print out sparse info - Print out a lot - Don't use this Incident data dir Loop data dir Output dir

INCIDENT DATA DIRECTORY LOOP DATA DIRECTORY OUTPUT DIRECTORY

Before or after study Default subdir name Filter factor for car speed Error le extension FSP data le Key data le The main sets of car data Navigation data le

Table 7.7: Summary of car parameters with no pre-de ned options.

114

CHAPTER 7. PROGRAM INPUT: THE RUNFILE

Parameter DELAY DOWNSTREAM NUM DELAY UPSTREAM NUM LOOP DIRECTORY LOOP FILTER FACTOR PERCENT DIESEL TRUCKS PERCENT GAS TRUCKS LOOP END TIME LOOP OUTPUT PERIOD LOOP START TIME TRAFFIC LOW SPEED

Options * * * * * * * * * *

Explanation # downstream dets. to use # upstream dets. to use The main sets of loop data Filtering factor for data % diesel trucks % gas trucks End time in seconds for loop data Seconds per period for the loop data Start time in seconds for loop data Tra c congestion speed

Table 7.8: Summary of loop parameters with no pre-de ned options.

7.5. SUMMARY OF PARAMETER VALUES

115

Parameter HEADWAY TIME VAL INC DUR EXPAND FRACTION INC EXPLANATION INC GRAPH MAX NUM INC GRAPH MAX PERCENT TIME ERROR BOUND

Options * * * * * *

Explanation Average probe headway Fraction of time to take Title to put on plots Vertical scale on one histogram Vertical scale on one histogram Width of correlation search area

Table 7.9: Summary of incident parameters with no pre-de ned options.

116

CHAPTER 7. PROGRAM INPUT: THE RUNFILE

Parameter CAR CLEANUP CAR DATA COMPRESSED GORE POINTS INCIDENT POINTS INRAD POINTS REPORT OPTION

Options DELETE FILES LEAVE FILES DATA NOT COMPRESSED DATA IS COMPRESSED NO CALC GORE POINTS YES CALC GORE POINTS NO INCIDENT POINTS YES INCIDENT POINTS NO INRAD POINTS YES INRAD POINTS KEY REPORT ONLY HUGE REPORT ONLY MEDIUM REPORT ONLY SHORT REPORT ONLY EVERYTHING NO SPEED DIST PLOTS YES SPEED DIST PLOTS NO SPEED TIME PLOTS YES SPEED TIME PLOTS NO TIME DIST PLOTS YES TIME DIST PLOTS

Explanation Do what with car tmp les - Delete them - Leave them there Is car data compressed? - No -Yes Calculate gore points? - No - Yes Calculate incident points? - No - Yes Calculate INRAD points? - No - Yes Types of reports to make - Detail on the keys - Lot's of detail - More detail - A short summary - Make all of the reports Make speed vs. distance plots? - No - Yes Make speed vs. time plots? - No - Yes Make time vs. distance plots? - No - Yes

SPEED DIST PLOTS SPEED TIME PLOTS TIME DIST PLOTS

Table 7.10: Summary of pre-de ned car parameters.

7.5. SUMMARY OF PARAMETER VALUES

117

Parameter

Options

Explanation

DELAY CALCULATION How to calculate delay - wrt a constant speed WRT CONSTANT SPEED WRT AVERAGE SPEED - wrt an average speed Can delays be negative? DELAY TYPE ONLY HAVE POSITIVE DELAY - No HAVE POSITIVE AND NEGATIVE DELAY - Yes DROPOUT TIMES Calculate the dropout times? NO DROPOUT FILES - No - Yes YES DROPOUT FILE EMISSION CALC Calculate the emissions? NO CALC EMISSIONS - No - Only for CO YES CALC CO EMISSIONS YES CALC VOC EMISSIONS - Only for VOC YES CALC NITRO EMISSIONS - Only for NITRO YES CALC ALL EMISSIONS - Yes - for everything Which temp oop les to delete FLOOP CLEANUP DELETE EVERYTHING - All of them DELETE ALL LANES - Just the lanes - Just the main line DELETE MAIN LINE ONLY DELETE RAMPS ONLY - Just the ramps DELETE NOTHING - Leave them all GLOOP CLEANUP - All of them DELETE EVERYTHING DELETE MAIN LINE ONLY - Just the main line DELETE RAMPS ONLY - Just the ramps DELETE NOTHING - Leave them all HLOOP CLEANUP DELETE EVERYTHING - All of them DELETE MAIN LINE ONLY - Just the main line DELETE RAMPS ONLY - Just the ramps DELETE NOTHING - Leave them all Table 7.11: Summary of pre-de ned loop parameters.

118

CHAPTER 7. PROGRAM INPUT: THE RUNFILE

Parameter

Options

Explanation Calculate aggregate values? - No - Yes Calculate the averages? - No - Yes Fix the consistency errors? - No - Yes Is loop data compressed? - No - Yes Which ow plots to make - Don't make any - Make occupancy plots - Make speed plots - Make counts plots - Make all plots Fix holes in the loop data? - No - Yes Whether to print data - Don't print anything - Print error reports - Print text reports - Print both reports What "PPS" means - #counts per output period - #counts per second Calculate tra c delay? - No - Yes

LOOP AGGREGATE VALUES NO CALC AGGREGATE VALUES YES CALC AGGREGATE VALUES LOOP AVERAGE NO LOOP AVERAGE YES LOOP AVERAGE LOOP CONSISTENCY FIX NO FIX CONSISTENCY ERRORS YES FIX CONSISTENCY ERRORS LOOP DATA COMPRESSED DATA NOT COMPRESSED DATA IS COMPRESSED LOOP FLOW PLOTS NO CALC LOOP FLOW PLOTS YES CALC OCC FLOW PLOTS YES CALC SPD FLOW PLOTS YES CALC PPS FLOW PLOTS YES CALC ALL FLOW PLOTS LOOP HOLES FIX NO FIX HOLE ERRORS YES FIX HOLE ERRORS LOOP TEXT LOOP NO REPORTS LOOP ERR REPORT ONLY LOOP TEXT REPORT ONLY LOOP BOTH REPORTS OUTPUT FLOW AVG FACTOR MATCH OUTPUT PERIOD PER ONE SEC TRAFFIC DELAY NO CALC TRAFFIC DELAY YES CALC TRAFFIC DELAY

Table 7.12: Summary of more pre-de ned loop parameters.

7.5. SUMMARY OF PARAMETER VALUES

119

Parameter FIX INC DURATION FIX INC LOCATION INC FINISHED GRAPHS INC FINISHED OUTPUT

Options NO FIX INC DURATION FIX INC DURATION FROM DATA FIX INC DURATION FROM FILE NO FIX INC LOC YES FIX INC LOC NO FINISHED GRAPH YES FINISHED GRAPH

Explanation Fix duration errors? - No - Yes, from car data - Yes, from made le Fix placement errors? - No - Yes Generate nished graphs? - No - Yes Generate nished output? - No - Yes, to a le - Yes, to the screen Finished output level? - Don't print much - Print just enough - Print way too much Match incidents witnessed once? - No - Yes Generate raw output? - No - Yes, to a le - Yes, to the screen Raw output level? - Don't print much - Print just enough - Print way too much Do any processing on incidents? - No - Yes

NO FINISHED OUTPUT FILE FINISHED OUTPUT SCREEN FINISHED OUTPUT INC FINISHED OUT LEVEL INC FIN OUT SPARSE INC FIN OUT MEDIUM INC FIN OUT VERBOSE INC MATCH ZERO WIDTH NO MATCH ZERO WIDTH INC YES MATCH ZERO WIDTH INC INC RAW MATCH OUTPUT NO RAW MATCH OUTPUT FILE RAW MATCH OUTPUT SCREEN RAW MATCH OUTPUT INC RAW OUTPUT LEVEL INC RAW OUT SPARSE INC RAW OUT MEDIUM INC RAW OUT VERBOSE PROCESS INCIDENTS NO PROC INCIDENTS YES PROC INCIDENTS

Table 7.13: Summary of pre-de ned incident parameters.

120

CHAPTER 7. PROGRAM INPUT: THE RUNFILE

Parameter

Options

Explanation Correlate cars and incidents? - No - Yes Use space-time boxes? - No - Yes Make contour delay plots? - No - Yes Make correlation graphs? - No - Yes Put numbers on them? - No - Yes

CORRELATE CARS DATABASE NO CORRELATE YES CORRELATE FIX INC DELAY BOX NO FIX INC DELAY YES FIX INC DELAY INC CONTOUR DELAY PLOT NO INC CONTOUR DELAY PLOTS YES INC CONTOUR DELAY PLOTS INC CORRELATION GRAPH NO INC CORR GRAPHS YES INC CORR GRAPHS NUMBER INC CORR GRAPHS NO NUMBER INC CORR GRAPHS YES NUMBER INC CORR GRAPHS

Table 7.14: Summary of pre-de ned analysis parameters.

Chapter 8

Run le Parameters To xfsp Strings

Tables 8.1 and 8.2 below give a complete cross reference between the run le parameters and the windows in the xfsp program. The individual options for each parameter are not listed out because they should be obvious (most of the responses are \yes" or \no"). This section has an alphabetical list of the run le parameters and what window they reside under. Note that none of the loop tests are listed below because they all reside under the \Loop Tests" button.

8.1 xfsp Windows To Run le Parameters

Tables 8.3 to 8.11 in this section translate from a speci c xfsp window to a run le parameter string.

121

122

CHAPTER 8. RUNFILE PARAMETERS TO XFSP STRINGS

Parameter CAR CLEANUP CAR DATA COMPRESSED CAR DATA DIRECTORY CAR DATA SET NUMBER CAR DIRECTORY ROOT CAR SPD FILTER FACTOR CORRELATE CARS DATABASE DEBUG LEVEL DELAY CALCULATION DELAY DOWNSTREAM NUM DELAY TYPE DELAY UPSTREAM NUM DROPOUT TIMES EMISSION CALC ERROR FILE NAME EXT FIX INC LOCATION FIX INC DELAY BOX FIX INC DURATION FLOOP CLEANUP FSP DATA FILE NAME GLOOP CLEANUP GNU PRINTER GORE POINTS HEADWAY TIME VAL HLOOP CLEANUP INCIDENT DATA DIRECTORY INCIDENT POINTS INC CONTOUR DELAY PLOT INC CORRELATION GRAPH INC DUR EXPAND FRACTION INC EXPLANATION INC FINISHED GRAPHS INC FINISHED OUTPUT INC FINISHED OUT LEVEL

Window or Button Car Output/Processing Car Output/Processing General Options General Options Car Output/Processing Car Output/Processing Correlate Data General Options Emissions/Delays Incident Delays Emissions/Delays Incident Delays Loop Output/Processing Emissions/Delays Car Output/Processing Fix Inc Data Fix Inc Data Fix Inc Data Loop Output/Processing Car Output/Processing Loop Output/Processing General Options Car Output/Processing Incident Delays Loop Output/Processing General Options Car Output/Processing Incident Delays Correlate Data Fix Inc Data Incident Delays Incident Delays Incident Delays Incident Delays

Subwindow or Title CAR CLEANUP FILES CAR DATA COMPRESSED Set Directories Set Directories Car directory root CAR SPEED FILTER CORRELATE CAR OPTION Set Main Options CALCULATION OPTIONS Number Of Downstream Detectors DELAY TYPE OPTION Number Of Upstream Detectors DROPOUT TIMES Emission Options Error le name FIX INCIDENT LOCATION FIX INCIDENT DELAY BOX FIX INCIDENT DURATION LOOP CLEANUP FILES ( oop) FSP le name LOOP CLEANUP FILES (gloop) Set Main Options GORE POINTS HEADWAY TIME LOOP CLEANUP FILES (hloop) Set Directories INCIDENT POINTS CONTOUR PLOTS CORRELATION GRAPHS Incident Duration Expand Fraction GRAPH EXPLANATION FINISHED OUTPUT GRAPH FINISHED OUTPUT LOCATION FINISHED OUTPUT LEVEL

Table 8.1: Run le parameters to xfsp location.

8.1. XFSP WINDOWS TO RUNFILE PARAMETERS

123

Parameter INC GRAPH MAX NUM INC GRAPH MAX PERCENT INC MATCH ZERO WIDTH INC RAW MATCH OUTPUT INC RAW OUTPUT LEVEL INRAD POINTS KEY DATA FILE NAME LOOP AGGREGATE VALUES LOOP AVERAGE LOOP CONSISTENCY FIX LOOP DATA COMPRESSED LOOP DATA DIRECTORY LOOP FILTER FACTOR LOOP FLOW PLOTS LOOP HOLES FIX LOOP END TIME LOOP OUTPUT PERIOD LOOP START TIME LOOP TEXT NAV DATA FILE NAME NUMBER INC CORR GRAPHS OUTPUT DIRECTORY OUTPUT FLOW AVG FACTOR PERCENT DIESEL TRUCKS PERCENT GAS TRUCKS PROCESS INCIDENTS REPORT OPTION SPEED DIST PLOTS SPEED TIME PLOTS TIME DIST PLOTS TIME ERROR BOUND TRAFFIC DELAY TRAFFIC LOW SPEED

Window or Button Incident Delays Incident Delays Incident Output/Processing Incident Output/Processing Incident Output/Processing Car Output/Processing Car Output/Processing Emissions/Delays Loop Output/Processing Fix Loop Data Loop Output/Processing General Options Loop Output/Processing Loop Output/Processing Fix Loop Data Loop Output/Processing Loop Output/Processing Loop Output/Processing Loop Output/Processing Car Output/Processing Correlate Data General Options Loop Output/Processing Emissions/Delays Emissions/Delays Incident Output/Processing Car Output/Processing Car Output/Processing Car Output/Processing Car Output/Processing Correlate Data Emissions/Delays Emissions/Delays

Subwindow or Title Maximum number on graph Maximum percentage on graph MATCH ZERO WIDTH RAW OUTPUT LOCATION RAW OUTPUT LEVEL INRAD POINTS Key le name AGGREGATE VALUES LOOP AVERAGE FIX LOOP CONSISTENCY LOOP DATA COMPRESSED Set Directories LOOP FILTER FACTOR LOOP FILES FIX LOOP HOLES Loop end time Loop output period Loop start time LOOP TEXT REPORTS Nav le name GRAPH NUMBERS Set Directories OUTPUT FLOW FACTOR Percent Gas Trucks Percent Diesel Trucks PROCESS INCIDENTS REPORT OPTION SPEED DISTANCE PLOTS SPEED TIME PLOTS TIME DISTANCE PLOTS TIME ERROR BOUND LOOP DELAY OPTIONS CONGESTION SPEED

Table 8.2: More run le parameters to xfsp location.

124

CHAPTER 8. RUNFILE PARAMETERS TO XFSP STRINGS

Window or Button Car Output/Processing Car Output/Processing Car Output/Processing Car Output/Processing Car Output/Processing Car Output/Processing Car Output/Processing Car Output/Processing Car Output/Processing Car Output/Processing Car Output/Processing Car Output/Processing Car Output/Processing Car Output/Processing Car Output/Processing Subwindow or Title CAR CLEANUP FILES CAR DATA COMPRESSED CAR SPEED FILTER Car directory root Error le name FSP le name GORE POINTS INCIDENT POINTS INRAD POINTS Key le name Nav le name REPORT OPTION SPEED DISTANCE PLOTS SPEED TIME PLOTS TIME DISTANCE PLOTS

Parameter CAR CLEANUP CAR DATA COMPRESSED CAR SPD FILTER FACTOR CAR DIRECTORY ROOT ERROR FILE NAME EXT FSP DATA FILE NAME GORE POINTS INCIDENT POINTS INRAD POINTS KEY DATA FILE NAME NAV DATA FILE NAME REPORT OPTION SPEED DIST PLOTS SPEED TIME PLOTS TIME DIST PLOTS

Table 8.3: Run le parameters in the Car Output/Processing window. Parameter Window or Button Subwindow or Title CORRELATE CARS DATABASE Correlate Data CORRELATE CAR OPTION INC CORRELATION GRAPH Correlate Data CORRELATION GRAPHS NUMBER INC CORR GRAPHS Correlate Data GRAPH NUMBERS TIME ERROR BOUND Correlate Data TIME ERROR BOUND Table 8.4: Run le parameters in the Correlate Data window. Parameter DELAY CALCULATION DELAY TYPE EMISSION CALC LOOP AGGREGATE VALUES PERCENT DIESEL TRUCKS PERCENT GAS TRUCKS TRAFFIC DELAY TRAFFIC LOW SPEED Parameter FIX INC DELAY BOX FIX INC DURATION FIX INC LOCATION INC DUR EXPAND FRACTION Window or Button Emissions/Delays Emissions/Delays Emissions/Delays Emissions/Delays Emissions/Delays Emissions/Delays Emissions/Delays Emissions/Delays Window or Button Fix Inc Data Fix Inc Data Fix Inc Data Fix Inc Data Subwindow or Title CALCULATION OPTIONS DELAY TYPE OPTION Emission Options AGGREGATE VALUES Percent Gas Trucks Percent Diesel Trucks LOOP DELAY OPTIONS CONGESTION SPEED Subwindow or Title FIX INCIDENT DELAY BOX FIX INCIDENT DURATION FIX INCIDENT LOCATION Incident Duration Expand Fraction

Table 8.5: Run le parameters in the Emissions/Delays window.

Table 8.6: Run le parameters in the Fix Inc Data window.

8.1. XFSP WINDOWS TO RUNFILE PARAMETERS

Parameter Window or Button Subwindow or Title LOOP CONSISTENCY FIX Fix Loop Data FIX LOOP CONSISTENCY LOOP HOLES FIX Fix Loop Data FIX LOOP HOLES Table 8.7: Run le parameters in the Fix Loop Data window. Parameter CAR DATA DIRECTORY CAR DATA SET NUMBER DEBUG LEVEL GNU PRINTER INCIDENT DATA DIRECTORY LOOP DATA DIRECTORY OUTPUT DIRECTORY Window or Button General Options General Options General Options General Options General Options General Options General Options Subwindow or Title Set Directories Set Directories Set Main Options Set Main Options Set Directories Set Directories Set Directories

125

Table 8.8: Run le parameters in the General Options window. Parameter DELAY DOWNSTREAM NUM DELAY UPSTREAM NUM HEADWAY TIME VAL INC CONTOUR DELAY PLOT INC EXPLANATION INC FINISHED GRAPHS INC FINISHED OUTPUT INC FINISHED OUT LEVEL INC GRAPH MAX NUM INC GRAPH MAX PERCENT Window or Button Incident Delays Incident Delays Incident Delays Incident Delays Incident Delays Incident Delays Incident Delays Incident Delays Incident Delays Incident Delays Subwindow or Title Number Of Downstream Detectors Number Of Upstream Detectors HEADWAY TIME CONTOUR PLOTS GRAPH EXPLANATION FINISHED OUTPUT GRAPH FINISHED OUTPUT LOCATION FINISHED OUTPUT LEVEL Maximum number on graph Maximum percentage on graph

Table 8.9: Run le parameters in the Incident Delays window. Parameter INC MATCH ZERO WIDTH INC RAW OUTPUT LEVEL INC RAW MATCH OUTPUT PROCESS INCIDENTS Window or Button Incident Output/Processing Incident Output/Processing Incident Output/Processing Incident Output/Processing Subwindow or Title MATCH ZERO WIDTH RAW OUTPUT LEVEL RAW OUTPUT LOCATION PROCESS INCIDENTS

Table 8.10: Run le parameters in the Incident Output/Processing window.

126

CHAPTER 8. RUNFILE PARAMETERS TO XFSP STRINGS

Parameter DROPOUT TIMES FLOOP CLEANUP GLOOP CLEANUP HLOOP CLEANUP LOOP AVERAGE LOOP DATA COMPRESSED LOOP FILTER FACTOR LOOP FLOW PLOTS LOOP END TIME LOOP OUTPUT PERIOD LOOP START TIME LOOP TEXT OUTPUT FLOW AVG FACTOR

Window or Button Loop Output/Processing Loop Output/Processing Loop Output/Processing Loop Output/Processing Loop Output/Processing Loop Output/Processing Loop Output/Processing Loop Output/Processing Loop Output/Processing Loop Output/Processing Loop Output/Processing Loop Output/Processing Loop Output/Processing

Subwindow or Title DROPOUT TIMES LOOP CLEANUP FILES ( oop) LOOP CLEANUP FILES (gloop) LOOP CLEANUP FILES (hloop) LOOP AVERAGE LOOP DATA COMPRESSED LOOP FILTER FACTOR LOOP FILES Loop end time Loop output period Loop start time LOOP TEXT REPORTS OUTPUT FLOW FACTOR

Table 8.11: Run le parameters in the Loop Output/Processing window.

Chapter 9

Program Input: The Incident Filter

The second parameter that the fsp program takes on the command line is the name of an incident lter. The incident lter tells the program which incidents to pull out of the incident database. All of the processing on the incidents is done on the ltered set of incidents. This chapter explains how to use the incident lter and its required format.

9.1 The Incident Filter Format

The format of the incident lter is pretty straight forward. It is a text le that can be edited with any text editor. Each line indicates one eld in the incident database that you wish to lter. Every line has a descriptor word followed by an equals sign followed by the desired values. For a list of all of the descriptor words see Section 9.2. An example of a line in an incident lter is given below:
SHIFT = 0

In the line above the descriptor word is \SHIFT" and the value that we are looking for is \0." If this line was the only line in your incident lter then you would be telling the program to only allow the incidents whose shift eld was 0 through the lter. When I say that an incident is allowed through the lter it means that the program will read that incident from the incident database and do more processing on it. If there are more lines in the incident lter then the nal lter is a logical \AND" of all of the lines. So if the two lines in the lter were:
SHIFT DIRECTION = 0 = 1

The the lter would only match incidents that had a shift of 0 AND a direction of 1. Probably the most important conceptual thing to understand about the incident lter is that it can not do a logical \OR" across elds. You can not have the incident lter match incidents that had a shift of 0 or had a direction of 1. But you can do a logical \OR" within a single eld. If there is a eld with a few di erent possible values, like the automobile color eld which has values in the range 0-12, then the incident lter can match multiple values. You specify this by typing each value that you want the lter to match in that eld on the same line: 127

128
VEHICLE_1_COLOR

CHAPTER 9. PROGRAM INPUT: THE INCIDENT FILTER

= 1 4 7

This would match any vehicle that had a color of black, gold, or orange. If there are two lines like this in the incident lter then the lter still performs an \AND" across the elds and an \OR" within the elds. So if you had something like:
VEHICLE_1_COLOR VEHICLE_1_TYPE = 1 4 7 = 2 3 4

Then this would look for incidents that were black, gold, or orange and that were a pickup truck, van, or station wagon. Another thing to note about the incident lter is that it can't do a logical \NOT" of a eld. So if you wanted to look for all incidents where the vehicles were not red then you would have to tell the lter to speci cally look for all of the other colors besides red. While most of the incident elds are simply integer values a few of them are time or date values. These are speci ed in the incident lter in a pretty straight forward way as seen by the examples below:
DATE TIME = 2/16/93 - 2/18/93 = 16:00 - 19:00

The date eld above is listed out from the starting date to the ending date in the standard month/day/year format. The date eld is closed on the left and open on the right. This means that the left date is included but that the right date is not. To specify one day then make the dates one day apart. Note that there needs to be a space between the \-" and the values. The time eld has the starting and ending time values in military time. If you mess up the times and list out an ending time that is before the starting time then the incident lter will not match anything. So the incident lter above will match incidents that occurred on either February 16th or 17th and happened between 4pm and 7pm. Finally, the \#" character is a comment character. So if a line starts with the \#" character then the whole line is discarded. This is useful if you want to rapidly switch between options in an incident lter without retyping.

9.2 Fields Of The Incident Filter 9.3 Incident Filter Examples

As was mentioned above, when the fsp program reads in the incident lter it expects there to be a one word eld descriptor at the start of each line. In Tables 9.1 and 9.2 I have listed out the eld descriptor words that you should use for each eld.

Below are a few examples of how to use the incident lter to obtain some interesting results. Since the run le dictates how the incidents are processed I have listed out the relevant run le parameters as well. Note that the numbers in parentheses to the right of each line are not part of the incident lter or the run le - they are only there for reference purposes. There are a few

9.3. INCIDENT FILTER EXAMPLES

Column A B C D E F G H I J K L M N O P Q R T S U V W X Y Z Name Type Incident Date Shift Time Direction Beginning End Link Identity Location Relative Exit Distance Primary Lane 2nd Lane 3rd Lane Incident Type Type 1 Type 2 Begin/End Type 3 Num Vehicles Vehicle 1 Type Vehicle 2 Type Vehicle 3 Type Vehicle 1 Color Vehicle 2 Color Field Descriptor Field Type DATA TYPE char (F,C,T) INC NUMBER integer DATE date SHIFT integer TIME time DIRECTION integer AT BEGINNING integer AT END integer LINK ID integer LOCATION integer RELATIVE LOC integer EXIT DISTANCE integer LANE 1 AFFECTED integer LANE 2 AFFECTED integer LANE 3 AFFECTED integer INCIDENT DESCRIPTION integer INCIDENT TYPE 1 integer INCIDENT TYPE 2 integer BEGIN END integer INCIDENT TYPE 3 integer NUM VEHICLES integer VEHICLE 1 TYPE integer VEHICLE 2 TYPE integer VEHICLE 3 TYPE integer VEHICLE 1 COLOR integer VEHICLE 2 COLOR integer

129

Table 9.1: Some eld descriptors for incident lter. steps that you want to follow every time that you want to create an incident lter and process the incidents. Below I have listed out two di erent lists: a short list and a long list. The short list gives a very quick overview of the general principles of ltering incidents. The longer list spells out most of the steps that you need to follow in order to do any ltering. The short list: 1. 2. 3. 4. Specify what incidents you want to lter. Specify what kind of xes you want to perform on the incidents. Specify any loop or car data that you need for the xes you chose. Specify what kind of output you want.

These four steps encompass all that you need to do to lter and process incidents. These steps are expanded out in more detail below in the longer list: 1. Decide which incidents you want to lter:

130
Column AA AB AC AD BF BG BH BI BJ BK BL BM BN BO BP BQ BR BS BT BU CX CY

CHAPTER 9. PROGRAM INPUT: THE INCIDENT FILTER

Name Vehicle 3 Color Ticket For Tow CHP Entries In Log No Tow Main Clear FSP Arrival CHP Arrival Tow Truck Arrival Ambulance Arrival Fire Arrival CHP Departure Tow Truck Departure Ambulance Departure Fire Departure Comments O cial Non-O cial Two Truck Response Two Truck Clearance Duration Weather Field Descriptor Field Type VEHICLE 3 COLOR integer TICKETED integer CHP integer NUM TIMES IN LOG integer TT NO REMOVE integer TIME MAIN CLEAR time FSP ARRIVAL integer CHP ARRIVAL time TOW ARRIVAL time AMB ARRIVAL time FIRE ARRIVAL time CHP DEPART time TOW DEPART time AMB DEPART time FIRE DEPART time COMMENTS integer NUM OFFICIAL integer NUM NON OFFICIAL integer TOW TRUCK RESPONSE time TOW TRUCK CLEARANCE time DURATION time WEATHER integer Table 9.2: More eld descriptors for incident lter.

2. 3. 4.

(a) Figure out what the eld descriptors are for the elds that you want. (b) Figure out what the values are for each eld that you are interested in. (c) Create the incident lter. Set the run le parameter PROCESS INCIDENTS to YES PROC INCIDENTS. Decide if you want to match incidents witnessed once and set the run le parameter INC MATCH ZERO WIDTH. Decide what kind of xes you want to perform on the incident data: (a) Decide if you want to x the duration of the incidents and set the run le parameters FIX INC DURATION and INC DUR EXPAND FRACTION. (b) Decide if you want to x the location of the incidents and set the run le parameters FIX INC LOCATION and CORRELATE CARS DATABASE. (c) Decide if you want to x the bounding box of the incidents for the delay calculation and set the run le parameter FIX INC DELAY BOX. Decide what kind of output you want on the raw incidents and set the run le parameters INC RAW MATCH OUTPUT and INC RAW OUTPUT LEVEL.

9.3. INCIDENT FILTER EXAMPLES

131

6. Decide what kind of output you want on the nished incidents and set the run le parameters INC FINISHED OUTPUT and INC FINISHED OUT LEVEL. 7. Decide if you want any graphs: (a) Decide if you want to generate a graph of the delay vs. duration and set the run le parameter INC FINISHED GRAPHS. (b) Decide what you want the title to be and set the run le parameter INC EXPLANATION. (c) Decide what you want the scales on the graphs to be and set the run le parameters INC GRAPH MAX NUM and INC GRAPH MAX PERCENT. 8. Decide if you want (or need) to process any other loop or car data and set those parameters accordingly. 9. Set the general parameters like the debug level and data directories.

9.3.1 Example 1: Examining Incident Fields

For the rst example we are not going to do any processing on the incidents at all. We are just going to list out all of the incident elds. The way that we will do this is by specifying the incident number that we want to examine in the incident lter like so:
INC_NUMBER = 16

(1)

This will tell the incident lter to only pull out incidents that have an incident number of 16. Of course, there should only be one incident in the incident database that has an incident number of 16. If we wanted to pull out multiple incidents, like incidents 16-20, we could have an incident lter that looks like this:
INC_NUMBER = 16 17 18 19 20

(1)

Note that there aren't any commas between the various numbers. If you wanted the incident lter to extract a lot of incidents then the incident numbers all have to be on the same line - you can't specify two lines for the same eld. The only restriction is that any single line can't be more than 2000 characters long. Hopefully, this is long enough for most needs. To just list out the elds of these incidents the following run le would work just ne:
PROCESS_INCIDENTS INC_RAW_MATCH_OUTPUT INC_RAW_OUTPUT_LEVEL INC_FINISHED_OUTPUT = = = = YES_PROC_INCIDENTS SCREEN_RAW_MATCH_OUTPUT INC_RAW_OUT_VERBOSE NO_FINISHED_OUTPUT

(1) (2) (3) (4)

Line by line, these run le parameters will do the following: 1) Process the incident data. 2) Send the raw incident output to the screen.

132

CHAPTER 9. PROGRAM INPUT: THE INCIDENT FILTER

3) Generate a lot of output for the raw incident output - this will print out all of the incident elds for every incident that matched the lter. There are approximately 50 elds per incident that are printed out. 4) Don't generate any nished output on the incidents. There are a couple of things that were not listed out in the run le above. We didn't list out any general parameters like DEBUG LEVEL or GNU PRINTER, we didn't specify any parameters that dealt with loop or car data, and we didn't list out any parameters that dealt xing the incident data. We didn't specify these parameters because we are assuming that if a parameter is not listed in the run le then it is set to NO or OFF - whichever is appropriate. For a more complete discussion of the various types of incident output see Chapter 16.

9.3.2 Example 2: Accidents With Little Processing

DATA_TYPE LANE_1_AFFECTED INCIDENT_TYPE_2 = F = 1 2 3 4 5 = 1 2

For this example let's lter out all of the incidents that are in-lane accidents. The incident lter should look like this: (1) (2) (3)

This will pull out all of the incidents that are (1) eld data, (2) that occur in lanes 1-5, and (3) that are either a single car or multi-car accident. We assume here that if the accident occurs in one of the lanes that that lane will be listed in the lter eld LANE 1 AFFECTED. If we just wanted to pull out these incidents and list them out without nding the delay or doing any xing of the incident data then we could have a run le that looks like the following:
PROCESS_INCIDENTS INC_MATCH_ZERO_WIDTH INC_RAW_MATCH_OUTPUT INC_RAW_OUTPUT_LEVEL INC_FINISHED_OUTPUT INC_FINISHED_OUT_LEVEL HEADWAY_TIME_VAL = = = = = = = YES_PROC_INCIDENTS YES_MATCH_ZERO_WIDTH_INC SCREEN_RAW_MATCH_OUTPUT INC_RAW_OUT_SPARSE SCREEN_FINISHED_OUTPUT INC_FIN_OUT_MEDIUM 0

(1) (2) (3) (4) (5) (6) (7)

Note that this run le is not complete. The parameters listed out are only the ones speci c to processing the incident data. The lines in the run le do the following (listed according to line number): 1) 2) 3) 4) 5) Process the incident data. Include incidents that were only witnessed once. Send any preprocessed incident output to the screen. Don't generate too much preprocessed incident output. Send any processed incident output to the screen.

9.3. INCIDENT FILTER EXAMPLES

6) Generate a medium amount of processed incident output. 7) Set the additive headway value to zero.

133

This combination of incident lter and run le will do the least amount of processing and the produce the least amount of output. There will be no attempt to x the incident location, duration, or to get the proper delay.

9.3.3 Example 3: Red Cars With Lots Of Processing

For this example let's look at the incidents that happened in the morning in the southbound direction between A-Street and Whipple that involved a red car but that was not a ticketing incident. This incident lter would look like this:
DATA_TYPE SHIFT DIRECTION LOCATION VEHICLE_1_COLOR INCIDENT_TYPE_3 = = = = = = F 0 1 4 5 6 7 8 9 8 0

(1) (2) (3) (4) (5) (6)

And if we wanted to do a bit more processing with these incidents our run le might look something like this:
PROCESS_INCIDENTS FIX_INCIDENT_DATA CORRELATE_CARS_DATABASE FIX_INC_DURATION INC_DUR_EXPAND_FRACTION FIX_INC_DELAY_BOX INC_CONTOUR_DELAY_PLOT INC_MATCH_ZERO_WIDTH INC_RAW_MATCH_OUTPUT INC_RAW_OUTPUT_LEVEL INC_FINISHED_OUTPUT INC_FINISHED_OUT_LEVEL INC_FINISHED_GRAPHS INC_EXPLANATION INC_GRAPH_MAX_NUM INC_GRAPH_MAX_PERCENT HEADWAY_TIME_VAL = = = = = = = = = = = = = = = = = YES_PROC_INCIDENTS YES_FIX_INC_DATA NO_CORRELATE FIX_INC_DURATION_FROM_FILE 50 YES_FIX_INC_DELAY YES_INC_CONTOUR_DELAY_PLOTS YES_MATCH_ZERO_WIDTH_INC SCREEN_RAW_MATCH_OUTPUT INC_RAW_OUT_SPARSE SCREEN_FINISHED_OUTPUT INC_FIN_OUT_MEDIUM YES_FINISHED_GRAPH Morning, southbound, red cars 10 20 0

(1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16) (17)

Where the lines in the run le do the following (listed according to line number): 1) Process the incident data. 2) Attempt to x the location of the incidents from a le read in at runtime.

134

CHAPTER 9. PROGRAM INPUT: THE INCIDENT FILTER

3) Don't attempt to correlate the incident database with the car data. This is taken care of by item 2. 4) Attempt to x the duration of the incidents from a le read in at runtime. 5) Expand the starting and ending times of the incident 50% of the way to when a di erent car passed this location without spotting the incident. 6) Attempt to set the bounding box for the delay of the incidents from a le read in at runtime. 7) Generate the contour, density, and di erential density plots of the loop detector data overlaid with the incident locations. 8) Include incidents that were only witnessed once. 9) Send any preprocessed incident output to the screen. 10) Don't generate too much preprocessed incident output. 11) Send any processed incident output to the screen. 12) Generate a medium amount of processed incident output. 13) Generate a graph of the delay vs duration for all of the incidents. 14) Put the title \Morning, southbound, red cars" on the plots. 15) Set the vertical scale to be 10 cars on one histogram plot. 16) Set the vertical scale to be 20 percent on another histogram plot. 17) Set the additive headway value to zero since this is taken care of by items 4 and 5.

9.3.4 Example 4: Tow Truck Incidents

In this example we are trying to list out all of the incidents that occurred on March 16th or 17th that had a tow truck respond. These are referred to as the assisted incidents. We also want to exclude incidents that started before we arrived or incidents that ended after we left.
DATA_TYPE DATE TOW_ARRIVAL BEGIN_END = = = = F 2/16/93 - 2/18/93 6:00 - 20:00 0

(1) (2) (3) (4)

We list out the tow truck arrival time in line 3 because in order to know if a tow truck showed up we can just check to see if a tow truck arrival time is listed. If it is then we are assured that a tow truck arrived. The BEGIN END eld in line 4 was a eld that we added that is the logical \OR" of elds G and H. A value of \0" for this eld means that we are excluding incidents that started before we got there and incidents that ended after we left. So the only incidents that we want to look at are ones that started and ended during our shift. In this example we are going to assume that we want to process everything from scratch. The run le is listed out below in various parts according to function. The rst section of the run le deals with the car data:
MAIN_DIRECTORY = am021693 1 2 3 4

(1)

9.3. INCIDENT FILTER EXAMPLES

MAIN_DIRECTORY MAIN_DIRECTORY MAIN_DIRECTORY GORE_POINT_OPTION INCIDENT_POINTS INRAD_POINTS SPEED_TIME_PLOTS SPEED_DIST_PLOTS TIME_DIST_PLOTS = = = = = = = = = pm021693 2 3 4 am021793 1 3 4 pm021793 1 2 3 4 YES_CALC_GORE_POINTS YES_INCIDENT_POINTS YES_INRAD_POINTS YES_SPEED_TIME_PLOTS YES_SPEED_DIST_PLOTS YES_TIME_DIST_PLOTS

135 (1) (1) (1) (2) (3) (4) (5) (6) (7)

This section of the run le will process the car data so that it can be used later on when the program needs to x the incident durations and locations. Line by line, this section does the following: 1) Simply list out the car data that we have available for the days of February 16th, and 17th. 2) Find all of the gore points in the car data - used when attempting to x the incident locations. 3) Find all of the places were the drivers pressed an incident key - used when attempting to x the incident locations. 4) Find all of the INRAD points in the car data - once again, used when attempting to x the incident locations. 5) Generate the speed vs. time plots - just nice to have. 6) Generate the speed vs. distance plots - just nice to have. 7) Generate the distance vs. time plots - needed to nd the incident durations. As you can see, the part of the run le that deals with the car data basically tells the program to process the car data and to record everything. The next section of the run le deals with the loop data that we need:
LOOP_DIRECTORY = lp021693 LOOP_DIRECTORY = lp021793 LOOP_START_TIME LOOP_END_TIME LOOP_OUTPUT_PERIOD OUTPUT_FLOW_AVG_FACTOR LOOP_FLOW_PLOTS LOOP_TEXT DROPOUT_TIMES LOOP_HOLES_FIX TRAFFIC_DELAY DELAY_CALCULATION DELAY_TYPE TRAFFIC_LOW_SPEED 1 1 = = = = = = = = = = = = 2 3 4 5 6 7 8 9 10 11 12 13 15 16 17 19 20 (1) 2 3 4 5 7 8 9 10 11 12 13 15 16 17 19 20 (1) 18000 (2) 72000 (3) 300 (4) MATCH_OUTPUT_PERIOD (5) YES_CALC_ALL_FLOW_PLOTS (6) LOOP_ERR_REPORT_ONLY (7) YES_DROPOUT_FILE (8) YES_FIX_HOLE_ERRORS (9) YES_CALC_TRAFFIC_DELAY (10) WRT_CONSTANT_SPEED (11) HAVE_POSITIVE_AND_NEGATIVE_DELAY (12) 55 (13)

136

CHAPTER 9. PROGRAM INPUT: THE INCIDENT FILTER

Much like the last section of the run le, this section will massage the loop data such that it can be used later on when processing the incident data. Line by line, this section of the run le does the following: 1) Simply list out the loop data that we have available for the days of February 16th and 17th. 2) Make the starting time for the loop data 18000 seconds since midnight - 5am. This is the starting time of our loop data. 3) Make the ending time for the loop data 72000 seconds since midnight - 8pm. This is the ending time of our loop data. 4) Generate the loop data every 300 seconds. 5) Make the PPS le be "Counts per output period." See the discussion in Chapter 7 under the parameter OUTPUT FLOW AVG FACTOR for more information. 6) Generate the ow, occupancy, and speed les from the loop data. 7) Generate an error report for the loop data - this is needed to x the holes in the loop data. 8) Generate a report on the holes in the loop data - this is needed to x the holes in the loop data. 9) Actually x the holes in the loop data. This will take the oop les and generate the gloop les. 10) Calculate the tra c delay for each loop. This is used when calculating the delay per incident. 11) When calculating the delay at each loop, perform the calculation with respect to a constant congestion speed. 12) When calculating the delay at each loop, allow the delay to become negative. 13) Use 55 mph as the congestion speed in the delay calculation. Finally, this last section of the run le deals with the processing of the incidents themselves:
PROCESS_INCIDENTS CORRELATE_CARS_DATABASE TIME_ERROR_BOUND INC_CORRELATION_GRAPH NUMBER_INC_CORR_GRAPHS FIX_INC_DURATION INC_DUR_EXPAND_FRACTION INC_CONTOUR_DELAY_PLOT INC_RAW_MATCH_OUTPUT INC_RAW_OUTPUT_LEVEL INC_FINISHED_OUTPUT INC_FINISHED_OUT_LEVEL INC_FINISHED_GRAPHS = = = = = = = = = = = = = YES_PROC_INCIDENTS YES_CORRELATE 360 YES_INC_CORR_GRAPHS YES_NUMBER_INC_CORR_GRAPHS FIX_INC_DURATION_FROM_DATA 100 YES_INC_CONTOUR_DELAY_PLOTS SCREEN_RAW_MATCH_OUTPUT INC_RAW_OUT_SPARSE SCREEN_FINISHED_OUTPUT INC_FIN_OUT_MEDIUM YES_FINISHED_GRAPH

(1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13)

9.3. INCIDENT FILTER EXAMPLES

INC_EXPLANATION INC_GRAPH_MAX_NUM INC_GRAPH_MAX_PERCENT HEADWAY_TIME_VAL = = = = February 16th and 17th 10 20 0

137 (14) (15) (16) (17)

This last section tells the program to use the car and loop data that was processed earlier to attempt to x the durations and locations of the incidents. Line by line, this section of the run le does the following: 1) Simply tells the program to process the incidents. 2) Attempt to correlate the incidents that made it through the lter with the car data that was processed. This will x the locations of the incidents. 3) When doing the correlation expand the incident duration by 360 seconds. See the discussion in Section 5.3.1 for a complete explanation. 4) Make the correlation graphs that give a visual representation of how the car data matches up with the incident database. 5) Put the incident numbers on the correlation graphs. 6) Attempt to x the incident durations from the car data. 7) When xing the durations expand the incident start or end time 100% of the way to when the last car went by the incident location. 8) Make the loop contour plots of delay, density and di erential density with the incidents on them. 9) Send any preprocessed incident output to the screen. 10) Don't send too much preprocessed incident output anywhere. 11) Send any processed incident output to the screen. 12) Generate a medium amount of processed incident output. 13) Generate a graph of the delay vs duration for all of the incidents. 14) Put the title \February 16th and 17th" on the plots. 15) Set the vertical scale to be 10 cars on the histogram plot of the number of incidents. 16) Set the vertical scale to be 20 percent on the histogram plot of the percentage of incidents. 17) Set the additive headway value to zero since this is taken care of by items 6 and 7. The results of this search are given below:
Individual incident statistics: Inc. Type Inc # Date D 1 2 3 Time South Link Loop 4 2/16/93 0 0 2 0 7:34 1 13 12 43 2/16/93 0 0 2 0 16:11 0 7 19 50 2/16/93 0 5 0 0 17:40 0 1 5 68 2/17/93 0 3 0 0 8:38 1 16 15 Good Bad Files Files 13 0 7 0 1 0 16 0 Duration 0:26:01 0:39:44 0:30:24 0:17:41 Delay 7.53 37.81 0.53 28.27

138
87 2/17/93 0 5 0 0

CHAPTER 9. PROGRAM INPUT: THE INCIDENT FILTER

17:23 1 5 20 5 0 1:18:17 10.96

Stats on all incident delays: Match incidents witnessed once = YES ALL results include headway time of = Number of Incidents = 5 Number witnessed once = 1 Min Max Incident Duration 17 78 TT Response ( 5) 0 31 TT Clearance ( 5) 0 28 Incident Delay 0.53 37.81

0:00

Mean 38.42 7.60 7.40 17.02

Std. Dev. 23.66 13.43 11.78 15.47

Std. Error 10.58 6.00 5.27 6.92

Chapter 10

Program Input: The Loop Detector Tests

At the start of the project there was great concern as to whether the loop detectors were performing properly. To address this concern there were a number of tests that were devised to detect problems with the loop data. This chapter describes all of these tests, what parameters they take, and how to initiate them.

10.1 Generating The Tests

Each test has a couple of run le parameters associated with it. One of the parameters is a simple on or o ag to indicate whether to run this test at all. The other parameters for a test are needed to specify the conditions of the test. For example, there is a test to ag when the speed goes above a certain value. In order to run this test you need to set the main parameter, LP SPEED HIGH TEST, to YES. An example of this in a run le is:
LP_SPEED_HIGH_TEST = YES

Once that is done you need to specify what speed you want to have agged. This is done with the parameter LP SPEED HIGH THRESHOLD MPH as in the example below:
LP_SPEED_HIGH_TEST = YES LP_SPEED_HIGH_THRESHOLD_MPH = 65

Finally, since the loop data can tend to be noisy, you can specify the number of times that the speed has to be above the threshold value before it is agged. Remember that the speed on each lane is extracted once every time period as speci ed by the parameter LOOP OUTPUT PERIOD. So if you have the output value set to 60 seconds and you want to ag every time that the speed goes above 65 mph for three times in a row then that would mean that the speed would need to be above 65 mph for three minutes before it is agged. The way to do this is with the parameter LP SPEED HIGH THRESHOLD NUM:
LP_SPEED_HIGH_TEST = YES LP_SPEED_HIGH_THRESHOLD_MPH = 65 LP_SPEED_HIGH_THRESHOLD_NUM = 3

139

140

CHAPTER 10. PROGRAM INPUT: THE LOOP DETECTOR TESTS

If the speed should go above 65 mph for only one or two samples then it will not be agged at all. A graphical illustration of this is given in Figure 10.1.
Too short 70 Long enough

High value

Speed

Car speed

0 Time

Figure 10.1: High Speed Test. Figure 10.1 is a drawing of a ctional speed time plot for some lane on the freeway. The small squares are the actual data points from the loop data and the line just connects them. In reality all of these points would be evenly spaced. In this gure, the speed goes above the high value twice. The rst time that it does so it only stays above the high value for one time period, therefore that event is not agged. The second time that the speed goes above the high threshold it stays there for ve time periods. Since this is longer than the value speci ed by LP SPEED HIGH THRESHOLD NUM this would be agged. When I say that an event will be agged then that means that an entry will be made in the error le. An entry contains the starting time of the event, the ending time, the duration (for those of us who can't subtract), the trap number, and a short description of the problem. An example of an entry in an error le for our example above is:
From 6:00:00 Till 6:04:00 Duration 0:04:00 Trap # 1 Problem SPEED passed high threshold.

This says that the problem started at 6:00am and continued until 6:04am a total of 4 minutes. It was at trap 1 and the problem was that the speed passed the high threshold that we set. There are a few other types of tests. They are \cross" tests and \range" tests. In a cross test we are checking that the values between lanes don't exceed a certain percentage: we are checking across lanes. One of these tests is the cross occupancy test. This is speci ed

10.1. GENERATING THE TESTS

141

by the test parameter LP CROSS OCC TEST. If we wanted to check that the values of the occupancies didn't change more than 5 percent from lane to lane then we would specify the following parameters:
LP_CROSS_OCC_TEST LP_CROSS_OCC_RANGE_PERCENT = YES = 5

A graphical illustration of this is given in Figure 10.2.

100

% Occupancy

Lane 1

Lane 2

Section where difference was more than 5%

0 Time

Figure 10.2: Cross Lane Test. Figure 10.3 is a picture of what the typical section of a loop detector looks like. There are four lanes and the boxes represent the loop detectors. In the cross tests we test the values between the lanes as indicated on the gure. The program knows what the layout of the freeway is and it knows to only check adjacent lanes. On this particular section of freeway for the cross lane occupancy test, the program would check that the occupancies match within 5 percent of each other for lanes 1 and 2, lanes 2 and 3, and lanes 3 and 4, for both the upstream and downstream detectors. There are four di erent cross tests that you can run: occupancies, on times, speeds, and counts. The run le parameters are:
LP_CROSS_OCC_TEST LP_CROSS_ON_TEST LP_CROSS_PPS_TEST LP_CROSS_SPEED_TEST

The range test is basically the same as the cross test except that you test between the upstream and downstream detectors in the same pair. There are two di erent range test that you can run: occupancies, and counts. The run le parameters are:

142

CHAPTER 10. PROGRAM INPUT: THE LOOP DETECTOR TESTS

Upstream Downstream 1 Cross lane test 2 3 4

Range test

Lane number

Figure 10.3: The Loop Detectors In The Freeway.

LP_OCC_RANGE_TEST LP_PPS_RANGE_TEST

There are some things to point out about the error reports. The error criterion that you specify are run on every trap, on every detector, and for every day that you specify. If you specify a lot ot tests to run then this will slow down the analysis quite a bit, so be prepared to wait. For every parameter there are defaults. The defaults are listed out below in the Table 10.2. To turn o a specify test then just set the main parameter to NO instead of YES. At the top of every error le is a listing of the criterion for every test. This is helpful in remembering what tests were actually run. All of the error reports for a certain day are placed in one le in the directory de ned in the include le fsp.h by the de ned variable LOOPDATA SUMMARY DIR. The error le name corresponds to the name of the data directory with the extension .sum. So if you were generating the error report for all of the loop data in the directory lp030193 then the error reports for all of the days is placed in the le lp030193.sum in the directory LOOPDATA SUMMARY DIR. Currently, this directory is de ned as \Reports" and it is always located under the loop output directory. If there are tests being done on something other than speed then there is an extra piece of information in the error le entry. This is the speci c trap which encountered the problem.

10.2. LISTING OF THE VARIOUS TESTS

143

It could have been the upstream trap or the downstream trap. The speed doesn't have this feature because it takes two traps to generate speed data, so there is no upstream or downstream. The extra information looks like this:
From 6:30:00 Till 6:54:00 Duration 0:24:00 Trap # 1 - Down Problem OCC passed range threshold.

Where Down means downstream and Up, paradoxically enough, means upstream. If the parameter DROPOUT TIMES is speci ed correctly then there will be information at the end of the error report on the times that the loop detector didn't collect data.

10.2 Listing Of The Various Tests

All of the tests that can be run on the loop data are listed out below. The parameter to turn the test on or o is referred to as the main parameter and the other parameters are called the auxiliary parameters. The various tests are listed out below alphabetically according to the main parameter. The value given for the typical entry is the default value for the various tests.

LP CROSS OCC TEST This allows the user to specify the maximum percentage change in
occupancy between lanes that is allowable.

OUTPUT IN ERROR FILE: The error le entry contains the two o ending lanes in a two character code. The rst character is either S, for southbound, or N,

for northbound, and the second character is the lane number. In this example the occupancy in the southbound lane 4 was more than the speci ed percentage away from southbound lane 5.
From 8:48:00 Till 8:54:00 Duration 0:06:00 Trap # 4 - Up Problem Cross lanes OCC: S4, S5

AUXILIARY PARAMETERS: The one auxiliary parameter for this test is the percentage change allowable. The typical entry is:
Auxiliary parameters LP_CROSS_OCC_RANGE_PERCENT Default 15

LP CROSS ON TEST This allows the user to specify the maximum percentage change in
on time between lanes that is allowable.

OUTPUT IN ERROR FILE: The error le entry contains the two o ending lanes in a two character code. The rst character is either S, for southbound, or N, for
northbound, and the second character is the lane number. In this example the on time in the southbound lane 4 was more than the speci ed percentage away from southbound lane 5.

144
From 8:48:00

CHAPTER 10. PROGRAM INPUT: THE LOOP DETECTOR TESTS

Till 8:54:00 Duration 0:06:00 Trap # 4 - Up Problem Cross lanes ON: S4, S5

AUXILIARY PARAMETERS: The one auxiliary parameter for this test is the percentage change allowable. The typical entry is:
Auxiliary parameters LP_CROSS_ON_RANGE_PERCENT Default 15

LP CROSS PPS TEST This allows the user to specify the maximum percentage change in
counts between lanes that is allowable.

OUTPUT IN ERROR FILE: The error le entry contains the two o ending lanes in a two character code. The rst character is either S, for southbound, or N,
for northbound, and the second character is the lane number. In this example the counts in the southbound lane 4 was more than the speci ed percentage away from southbound lane 5.
From 8:48:00 Till 8:54:00 Duration 0:06:00 Trap # 4 - Up Problem Cross lanes PPS: S4, S5

AUXILIARY PARAMETERS: The one auxiliary parameter for this test is the percentage change allowable. The typical entry is:
Auxiliary parameters LP_CROSS_PPS_RANGE_PERCENT Default 10

LP CROSS SPEED TEST This allows the user to specify the maximum percentage change
in speed between lanes that is allowable.

OUTPUT IN ERROR FILE: The error le entry contains the two o ending lanes in a two character code. The rst character is either S, for southbound, or N,
for northbound, and the second character is the lane number. In this example the speed in the southbound lane 4 was more than the speci ed percentage away from southbound lane 5.
From 8:48:00 Till 8:54:00 Duration 0:06:00 Trap # 4 - Up Problem Cross lanes SPEED: S4, S5

AUXILIARY PARAMETERS: The one auxiliary parameter for this test is the percentage change allowable. The typical entry is:
Auxiliary parameters LP_CROSS_SPEED_RANGE_PERCENT Default 20

LP OCC HIGH TEST This allows the user to specify the maximum value that the occupancy can take, and for how long.

OUTPUT IN ERROR FILE: This simply states that the value was exceeded.

10.2. LISTING OF THE VARIOUS TESTS

From 8:48:00 Till 8:54:00 Duration 0:06:00 Trap # 4 - Up

145
Problem OCC passed high threshold.

AUXILIARY PARAMETERS: One auxiliary parameter for this test is the maximum
value and the other is the number of times that it should pass this threshold before it is agged.
Auxiliary parameters LP_OCC_HIGH_THRESHOLD_PERCENT LP_OCC_HIGH_THRESHOLD_NUM Default 60 4

LP OCC LOW TEST This allows the user to specify the minimum value that the occupancy
can take, and for how long.
From 8:48:00 Till 8:54:00

OUTPUT IN ERROR FILE: This simply states that the value was too low. AUXILIARY PARAMETERS: One auxiliary parameter for this test is minimum
Auxiliary parameters LP_OCC_LOW_THRESHOLD_PERCENT LP_OCC_LOW_THRESHOLD_NUM Default 5 8 Duration 0:06:00 Trap # 4 - Up Problem OCC passed low threshold.

value and the other is the number of times that it should pass this threshold before it is agged.

LP OCC NUM ZEROS TEST This allows the user to specify the maximum number of
zeros that can occur in a row for the OCC value before it is agged.
From 8:48:00 Till 8:54:00 Duration 0:06:00 Trap # 4 - Down

OUTPUT IN ERROR FILE: This simply states that the value was exceeded. AUXILIARY PARAMETERS: The one auxiliary parameter for this test is the maximum number of zeros that can occur in a row.
Auxiliary parameters LP_OCC_NUM_ZEROS Default 5 Problem OCC was zero too often.

LP OCC RANGE TEST This allows the user to specify the maximum percentage di erence OUTPUT IN ERROR FILE: This simply states that the value was exceeded.
From 8:48:00 Till 8:54:00 Duration 0:06:00 Trap # 4 - Down

in the values of the upstream and downstream detectors for the OCC value. There is no threshold time associated with this test - the instant that this condition is detected it is agged. Note that this is in terms of percentages.
Problem OCC passed range threshold.

146

CHAPTER 10. PROGRAM INPUT: THE LOOP DETECTOR TESTS

AUXILIARY PARAMETERS: The one auxiliary parameter for this test is the maximum percentage di erence in the values of the upstream and downstream detectors.
Auxiliary parameters LP_OCC_RANGE_PERCENT Default 10

LP ON TIME CRITICAL TEST This allows the user to specify the maximum value that OUTPUT IN ERROR FILE: This simply states that the value was exceeded.
From 8:48:00 Till 8:54:00 Duration 0:06:00 Trap # 4 - Down Problem On time passed CRITICAL.

the on time can ever take. If the on time exceeds this value just once then it is agged. This is used to look for serious errors in a detector.

AUXILIARY PARAMETERS: The one auxiliary parameter for this test is the maximum critical value.
Auxiliary parameters LP_ON_TIME_CRITICAL Default 2000

LP ON TIME TEST This allows the user to specify the maximum value that the on time
can take, and for how long. This maximum value is in milliseconds.
From 8:48:00 Till 8:54:00 Duration 0:06:00 Trap # 4 - Up

OUTPUT IN ERROR FILE: This simply states that the value was exceeded.
Problem On time passed threshold.

AUXILIARY PARAMETERS: One auxiliary parameter for this test is the maximum
value and the other is the number of times that it should pass this threshold before it is agged.
Auxiliary parameters LP_ON_TIME_HIGH_THRESHOLD_MSEC LP_ON_TIME_HIGH_THRESHOLD_NUM Default 300 4

LP PPS HIGH TEST - Warning: between match output period and per sec This allows

the user to specify the maximum value that the counts can take, and for how long. Note that if you change the value of OUTPUT FLOW AVG FACTOR then you will a ect the outcome of this test. Just remember that if you are generating count values that are in counts per second then it is never going to get above 2 or 3. But that if you generating count values in counts per output period then you can get very large numbers. You should set your tests appropriately.

OUTPUT IN ERROR FILE: This simply states that the value was exceeded.
From 8:48:00 Till 8:54:00 Duration 0:06:00 Trap # 4 - Down Problem PPS passed high threshold.

10.2. LISTING OF THE VARIOUS TESTS

147

AUXILIARY PARAMETERS: One auxiliary parameter for this test is the maximum
value and the other is the number of times that it should pass this threshold before it is agged.
Auxiliary parameters LP_PPS_HIGH_THRESHOLD_COUNTS LP_PPS_HIGH_THRESHOLD_NUM Default 10 4

LP PPS LOW TEST This allows the user to specify the minimum value that the counts
can take, and for how long. Note that if you change the value of the run le parameter OUTPUT FLOW AVG FACTOR then you will a ect the outcome of this test. Just remember that if you are generating count values that are in counts per second then it is never going to get above 2 or 3. But that if you generating count values in counts per output period then you can get very large numbers. You should set your tests appropriately.

OUTPUT IN ERROR FILE: This simply states that the value was exceeded.
From 8:48:00 Till 8:54:00 Duration 0:06:00 Trap # 4 - Down Problem PPS passed low threshold.

AUXILIARY PARAMETERS: One auxiliary parameter for this test is the minimum
Auxiliary parameters LP_PPS_LOW_THRESHOLD_COUNTS LP_PPS_LOW_THRESHOLD_NUM Default 1 4

value and the other is the number of times that it should pass this threshold before it is agged.

LP PPS NUM ZEROS TEST This allows the user to specify the maximum number of
zeros that can occur in a row for the PPS value before it is agged.
From 8:48:00 Till 8:54:00 Duration 0:06:00 Trap # 4 - Down

OUTPUT IN ERROR FILE: This simply states that the value was exceeded. AUXILIARY PARAMETERS: The one auxiliary parameter for this test is the maximum number of zeros that can occur in a row.
Auxiliary parameters LP_PPS_NUM_ZEROS Default 5 Problem PPS was zero too often.

LP PPS RANGE TEST This allows the user to specify the maximum percentage di erence OUTPUT IN ERROR FILE: This simply states that the value was exceeded.

in the values of the upstream and downstream detectors for the PPS value. There is no threshold time associated with this test - the instant that this condition is detected it is agged. Note that this is in terms of percentages.

148
From 8:48:00

CHAPTER 10. PROGRAM INPUT: THE LOOP DETECTOR TESTS

AUXILIARY PARAMETERS: The one auxiliary parameter for this test is the maxAuxiliary parameters LP_PPS_RANGE_PERCENT Default 10

Till 8:54:00

Duration 0:06:00

Trap # 4 - Down

Problem PPS passed range threshold.

imum percentage di erence in the values of the upstream and downstream detectors.

LP SPEED HIGH TEST This allows the user to specify the maximum value that the speed
can take, and for how long. This maximum value is in miles per hour.
From 8:48:00 Till 8:54:00 Duration 0:06:00 Trap # 4

OUTPUT IN ERROR FILE: This simply states that the value was exceeded. AUXILIARY PARAMETERS: One auxiliary parameter for this test is the maximum
value and the other is the number of times that it should pass this threshold before it is agged.
Auxiliary parameters LP_SPEED_HIGH_THRESHOLD_MPH LP_SPEED_HIGH_THRESHOLD_NUM Default 65 5 Problem SPEED passed high threshold.

LP SPEED LOW TEST This allows the user to specify the minimum value that the speed
can take, and for how long. This minimum value is in miles per hour.
From 8:48:00 Till 8:54:00 Duration 0:06:00 Trap # 4

OUTPUT IN ERROR FILE: This simply states that the value was exceeded.
Problem SPEED passed low threshold.

AUXILIARY PARAMETERS: One auxiliary parameter for this test is the minimum
Auxiliary parameters LP_SPEED_LOW_THRESHOLD_MPH LP_SPEED_LOW_THRESHOLD_NUM Default 20 5

value and the other is the number of times that it should pass this threshold before it is agged.

10.3 The Default Values For The Loop Tests

All of the defaults for the tests are NO, meaning that they are turned o . These are listed here in Table 10.1 only for completeness (not because I wanted to make the manual any longer). All of the default values for the auxiliary parameters are listed out in Table 10.2. Also, listed out in Table 10.3 are the main parameters for the tests and the entries that they place in the error le. The characters XN means the direction and the lane number.

10.3. THE DEFAULT VALUES FOR THE LOOP TESTS

Parameter LP CROSS OCC TEST LP CROSS ON TEST LP CROSS PPS TEST LP CROSS SPEED TEST LP OCC HIGH TEST LP OCC LOW TEST LP OCC NUM ZEROS TEST LP OCC RANGE TEST LP ON TIME CRITICAL TEST LP ON TIME TEST LP PPS HIGH TEST LP PPS LOW TEST LP PPS NUM ZEROS TEST LP PPS RANGE TEST LP SPEED HIGH TEST LP SPEED LOW TEST Default NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO Default 15 15 10 20 4 60 8 5 5 10 2000 300 4 10 4 1 4 5 10 65 5 20 5

149

Table 10.1: Test parameter defaults. Auxiliary Parameter LP CROSS OCC RANGE PERCENT LP CROSS ON RANGE PERCENT LP CROSS PPS RANGE PERCENT LP CROSS SPEED RANGE PERCENT LP OCC HIGH THRESHOLD NUM LP OCC HIGH THRESHOLD PERCENT LP OCC LOW THRESHOLD NUM LP OCC LOW THRESHOLD PERCENT LP OCC NUM ZEROS LP OCC RANGE PERCENT LP ON TIME CRITICAL LP ON TIME HIGH THRESHOLD MSEC LP ON TIME HIGH THRESHOLD NUM LP PPS HIGH THRESHOLD COUNTS LP PPS HIGH THRESHOLD NUM LP PPS LOW THRESHOLD COUNTS LP PPS LOW THRESHOLD NUM LP PPS NUM ZEROS LP PPS RANGE PERCENT LP SPEED HIGH THRESHOLD MPH LP SPEED HIGH THRESHOLD NUM LP SPEED LOW THRESHOLD MPH LP SPEED LOW THRESHOLD NUM

Table 10.2: Auxiliary parameter defaults.

150

CHAPTER 10. PROGRAM INPUT: THE LOOP DETECTOR TESTS

Main Parameter LP CROSS OCC TEST LP CROSS ON TEST LP CROSS PPS TEST LP CROSS SPEED TEST LP OCC HIGH TEST LP OCC LOW TEST LP OCC NUM ZEROS TEST LP OCC RANGE TEST LP ON TIME CRITICAL TEST LP ON TIME TEST LP PPS HIGH TEST LP PPS LOW TEST LP PPS NUM ZEROS TEST LP PPS RANGE TEST LP SPEED HIGH TEST LP SPEED LOW TEST

Error Entry Cross lanes OCC: XN, XN Cross lanes ON: XN, XN Cross lanes PPS: XN, XN Cross lanes SPEED: XN, XN OCC passed high threshold. OCC passed low threshold. OCC was zero too often. OCC passed range threshold. On time passed CRITICAL. On time passed threshold. PPS passed high threshold. PPS passed low threshold. PPS was zero too often. PPS passed range threshold. SPEED passed high threshold. SPEED passed low threshold.

Table 10.3: Main parameters and error entries.

Chapter 11

Program Input: Cross Data Analysis

One goal of the fsp program is to calculate the delay for each speci c incident. In order to do this, quite a few things need to be done. This chapter will explain in detail all of the steps that were taken to calculate the incident delay and all of the formulas that were used. I would like to start out with an overview of how the data is processed. In the following sections I'll explain each step in detail.
FSP Data Flow
Loop Data Incident Data Car Data

Fix Loop Data

Fix Incident data

Calculate Loop Delays Calculate Incident Delays

Output

Figure 11.1: Big Picture For FSP Program. Figure 11.1 is a rough view of what the data ow looks like in the fsp program. There are three main branches of the program: the loop data, the incident data, and the car data. Since the overall goal is to calculate the delay per incident the loop and car branches merge into the incident data branch at various points. The car data is used mainly to correct the location and duration of each incident. The loop data is then used to calculate the delay 151

152

CHAPTER 11. PROGRAM INPUT: CROSS DATA ANALYSIS

per incident. The loop data processing is done in two main steps. First we x the loop data and then we generate the loop delay les. The things that we try to x in the loop data are the various holes that show up and the consistency errors. Both of these xes are discussed in Chapter 5. The loop delay les are simply the delay calculated for each loop for every time segment. The car data is rst read in to generate some diagnostic graphs and then it is used to x various elds in the incident database. The incident data processing involves rst ltering the incidents, then xing their locations, and nally calculating the delay for each incident. At each step in the data ow there are many di erent types of plots and tables that are made to explain what is happening. These are not shown in Figure 11.1 because it would obscure the simple message that I am trying to convey. Below is a list of steps that the program will take when calculating the delay per incident: Loop data processing 1. Convert from raw data to ascii. 2. Fix the loop data. 3. Compute the loop averages. 4. Compute the loop delays. Car data processing 1. Convert from raw data to ascii. 2. Record all key presses. 3. Record all INRAD points. Incident data processing 1. Filter out the proper incidents. 2. Fix the incident locations from the car data. 3. Fix the incident durations from the car data. Calculate the delay per incident 1. Read in the incident bounding boxes. 2. Read in the loop les corresponding to those boxes. In the following sections I will discuss what processing goes on in each of the boxes in Figure 11.1 and in each of the steps in the list above.

11.1 Generating The Loop Speeds

It turns out that there are a couple of di erent ways to calculate the delay on a section of the freeway. The standard equation for calculating the delay at a particular loop segment is: T 1 D = L 60 F V ; V1 (11.1) T

11.1. GENERATING THE LOOP SPEEDS

153

Where D is the delay for a particular segment of the freeway, L is the length, F is the ow, V is the speed, and VT is the speed of congestion. Even though this is pretty straight forward it is not clear exactly how to apply this formula. Since we have the ows and the speeds for each lane at every loop segment should we calculate the delay for each lane and then add them up to get a total delay for each segment? Or should we average the ows and the speeds over the lanes and then calculate the delay? Well, if we look at these two di erent methods then we will see that they are not the same. The delay that we get by rst calculating the delay for each lane and then adding up all of the lanes (assuming that there are N lanes) is the following: T 1 (11.2) Di = L 60 Fi V ; V1 i T N X D = Di (11.3)

T 1 L 60 Fi V ; V1 (11.4) i T i=1 N T X Fi ; Fi D = L 60 (11.5) i=1 Vi VT Note that anything indexed by i is an individual lane. These equations have been carried out D =
this far so that we can compare them to the second way of calculating the delay which is to rst compute the average ow and speed over the freeway and then to just do one delay calculation: N X F = Fi (11.6) i=1 PN i V = P=1 FiVi (11.7) N F i=1 i T 1 (11.8) D = L 60 F V ; V1 T ! ! PN N ! T XF i=1 Fi ; 1 D = L 60 (11.9) PN i V As you can see, equation 11.5 is not the same as equation 11.9. So the question arises, \which one represents the proper delay calculation?" The solution that the fsp program implements is the rst: conceptually it gures out the delay for each lane and then gures out the total delay by summing up over all of the lanes. It does it conceptually because it never actually calculates the delay for each lane. Instead, the fsp program does a calculation like equations 11.6 thru 11.9 but it uses a di erent type of average for the speed. It uses the weighted harmonic average speed instead of the arithmetic speed. If we do this we get a total speed for the freeway as: PN i=1 Vh = PN Fii (11.10) F Plugging this average into equation 11.1 we get: T 1 D = L 60 F V ; V1 h T
i=1 Vi i=1 i=1 Fi Vi T

i=1 N X

(11.11)

154

CHAPTER 11. PROGRAM INPUT: CROSS DATA ANALYSIS

N ! T XF D = L 60 i i=1 N F X

! PN Fi ! 1 i=1 Vi ; PN V
i=1 Fi T

(11.12) (11.13)

T i ; Fi D = L 60 i=1 Vi VT

This is the same as equation 11.5. There are two reasons for wanting to calculate the delay for the segment by using equations of the form 11.6 thru 11.9: In order to x the holes at all we need to have one value for the speed and one value for the ow at the detectors adjacent to each hole. Therefore, we need the averages over all the lanes for all of the loop detectors. Finally, since we can't do the individual lane calculations on the xed data and since we already have the averages we might as well do the speed calculation as in equation 11.10. Equations 11.6 thru 11.9 are more computationally e cient than equations 11.2 thru 11.5. The whole point of the previous discussion is that the average loop speed les contain the weighted harmonic average instead of the arithmetic average. In normal tra c ow conditions these two speeds shouldn't vary by more than a few percent. But when the spread in the speed between the lanes is high, the arithmetic and weighted harmonic averages can vary by up to 20%. Usually, the only time when the speeds across the lanes will vary signi cantly is when there is an incident on a section of the freeway where there is a high occupancy vehicle (HOV) lane. Since cars won't change into the HOV lane to avoid the congestion for fear of a ne, the tra c in the non-HOV lanes tends to build up rather quickly and hence the speeds across the lanes starts to vary.

11.2 Fixing The Loop Data

The rst thing that needs to be done after the speeds have been calculated and before any analysis can take place is to x the loop data. As was discussed in Section 5.2, the loop data has a number of things wrong with it. The fsp program will try to make two main xes: a hole x and a consistency x. I have referred to these as the various stages of the loop data processing. Figure 11.2 shows the loop data ow. Each box produces a di erent type of loop le. There is a short synopsis of each le type below. The sections that follow explain each step in detail.

Raw loop data The raw loop data is an encoded le that holds the data stream from the 170
controller. The les have names like:
loop5.dat.

Extract to ascii text These les are separated according to lane number and data type. This

means that each lane and each type of data ( ows, occupancies, or speeds) is in it's own le. A typical le name from this set of loop les would be: floop3.nc2. This corresponds to the ascii text le from loop detector #3 and the northbound ows from lane 2. These les are called the \ oop" les and are referred to as the rst stage in the loop processing. For more information on the naming scheme of the loop output les see Chapter 15.

11.2. FIXING THE LOOP DATA

Loop Data Flow

155

Raw loop data

Fix holes in loop data

Extract to ascii text

Fix consistency errors

Good loop data

Figure 11.2: Fixing The Loop Data.

Fix holes in loop data These les are exactly like the \ oop" les except that the holes have

been xed. These les have lenames that start with \gloop" and hence are referred to as the \gloop" les. These are generated in the second stage of the loop processing. Fix consistency errors These les are the same as the \gloop" les except that the consistency errors have been corrected. These les have lenames that start with \hloop" and hence are referred to as the \hloop" les. This is the third and nal stage of the loop processing. So when the program gets done processing the loop data there could be three different sets of loop les on your system: oop, gloop, and hloop. The fsp program gives you the option of deleting the sets of loop les that you don't need. This is done via the run le parameters FLOOP CLEANUP, GLOOP CLEANUP, and HLOOP CLEANUP.

11.2.1 The oop Files

We start o with the raw loop data and the rst thing that we do is convert the data from raw form to ascii form. This is called the rst stage and it generates a bunch of les called \ oop" les. The raw data has one le for each loop detector that contains all of the counts, speeds, and occupancies for every lane. For example, let's say that we are looking at loop detector #1. Then the raw loop data le will be loop1.dat. What the rst stage of processing does is it extracts into separate les the data for each lane and for each on and o ramp at that detector, and it does this for the counts, speeds, and occupancies at each lane. Since detector #1 has 5 southbound and 5 northbound lanes the rst stage would generate a total of 36 les for just that detector. These are listed out below:
oriel 1: ls floop1.* floop1.nc1 floop1.ns1 floop1.nc2 floop1.ns2 floop1.nc3 floop1.ns3 floop1.nc4 floop1.ns4 floop1.nc5 floop1.ns5 floop1.ncd floop1.nsd floop1.so1 floop1.so2 floop1.so3 floop1.so4 floop1.so5 floop1.sod

156
floop1.no1 floop1.no2 floop1.no3 floop1.no4 floop1.no5 floop1.nod

CHAPTER 11. PROGRAM INPUT: CROSS DATA ANALYSIS

floop1.sc1 floop1.sc2 floop1.sc3 floop1.sc4 floop1.sc5 floop1.scd floop1.ss1 floop1.ss2 floop1.ss3 floop1.ss4 floop1.ss5 floop1.ssd

As you can see, the reason that these are called the \ oop" les is because they all start with the pre x \ oop." You can also see that this is quite a few les for just one loop detector. The naming scheme for these les is: oopWW.XYZ. Where: oop: this is just the standard le pre x. WW: this is the loop detector number (or cabinet number). X: this is either \n" or \s" for the northbound or southbound direction. Y: explains the type of data and can be one of the following: c: means counts or pps. s: means speed. o: means occupancy. Z: this is the lane number or the on or o ramp number. For example, the le floop1.ns4 is the raw speed data for lane 4 of the northbound direction of detector # 1. If the last character is not a number but a \d" then that means the le is the value of the average of all of the lanes. There are a couple of important things to note about the naming of the loop les but that would take us too far astray. The complete discussion can be found in Section 15.3. Once the \ oop" les have been extracted from the raw data the program can attempt to x the holes that appear in the data. This is called the second stage and it will generate a bunch of les called the \gloop" les. The \gloop" les are just the \ oop" les with the holes lled in. If it turns out that there aren't any holes in a particular \ oop" le then that le is simply copied over to the appropriate \gloop" le. See the discussion in Section 5.2.1 for a complete explanation of how the loop data is recreated. The naming scheme for both sets of les is the same. For example, floop1.sod and gloop1.sod both refer to the average southbound occupancy at detector # 1. It's just that the rst le is the raw data and could have holes in it, whereas the second le is the corrected data and hence won't have any holes at all. There are a couple of important things to note about the hole x algorithm that generates the \gloop" les: The algorithm only operates on the average les, not on the individual lane les. Subsequently, there is no way to x the individual lane les.

11.2.2 The gloop Files

11.3. THE LOOP DELAY FILES

157

The algorithm combines all of the on ramp les into a single le depending on type. So all of the on ramp occupancy les are combined to give a single on ramp occupancy le. The same holds for the ow les on the on ramps. The algorithm combines all of the o ramp les into a single le depending on type exactly like the on ramp les. See the discussion under the run le parameter LOOP_HOLES_FIX for a discussion of what other parameters need to be set in order for this x to run successfully. If you are generate the \gloop" les then you probably don't need any of the \ oop" les on the system anymore. You can tell the program to delete them when it's done with them by setting the run le parameter FLOOP_CLEANUP to be DELETE_EVERYTHING This is discussed in Chapter 7.

11.2.3 The hloop Files

Finally, the program will attempt to x the consistency errors in the loop data. The algorithm can only x the consistency errors in the \gloop" les. This means that in order to x the consistency errors that the user has to rst run the hole xing algorithm. The consistency x algorithm itself is described in Section 5.2.2. The les that this x generates are the same as the \gloop" les in terms of lenames except that there is an \h" where there used to be a \g" and hence these are referred to as the \hloop" les. Once you generate the \hloop" les you can have the program delete the \ oop" and \gloop" les by setting the run le parameters FLOOP_CLEANUP and GLOOP_CLEANUP to DELETE_EVERYTHING.

11.3 The Loop Delay Files

After the xes have been done on the loop data the next major step that the program takes is to calculate the loop delay les. The loop delay algorithm can take in any one of the loop sets, either the \ oop," \gloop," or the \hloop" les. I would recommend that you only run this on the \gloop" or \hloop" les because there are so many holes in the \ oop" data. When we say that we are going to calculate the loop delay we mean that we are going to gure out the following value: ! i = L T Fi 1 ; 1 Dk (11.14) 60 k i V

i Where Dk is the delay on segment k during time slice i, L is the segment length in miles, T is the time slice in minutes, Fki is the ow on segment k during time slice i, Vki is the speed on segment k during time slice i, and VT is the threshold or congestion speed1 . For each loop detector we calculate this value for every time slice. The resulting les are called the loop delay les.
1

Note that the indices here mean something di erent than in equation 11.2.

158

CHAPTER 11. PROGRAM INPUT: CROSS DATA ANALYSIS

11.3.1 The Run le Parameters Needed

The loop delay les are the basis of the delay per incident calculation. The routine in the program that calculates the delay per incident reads in the loop delay les to gure out the delay surrounding an incident. You should be aware that the parameters that you set when calculating the loop delay les also e ect the delay per incident calculation. There are a couple of run le parameters that you can set that govern the generation of the loop delay les. These are all explained in Chapter 7 but are listed here for convenience. These are:

TRAFFIC DELAY Whether or not to calculate the loop delay. DELAY CALCULATION Specify whether to calculate the delay with respect to a constant
congestion speed or the average. TRAFFIC LOW SPEED Specify what the congestion speed should be. DELAY TYPE Specify whether to allow negative delays or not.

The parameter TRAFFIC_DELAY simply tells the fsp whether to run the routine that calculates the loop delay les. In the overall ow of the fsp program the loop data is processed rst followed by the incident data. When the incident data is processed, it needs to read in the loop delay les. Well, these les are not stored in the computer memory, they are stored in speci c directories. So it doesn't matter if the loop delay les were generated by this run of the fsp program or a run that was done last week - the les will still be in the directories. If you had to calculate the delay les every time that you wanted to do something di erent with the incidents then the program would take way too much time. By turning o the calculation of the loop delay les and just using the ones that are on the hard disk you save quite a bit of time. Of course there are problems with this: If somebody deletes the loop delay les and the routine that processes the incidents can't nd them then the program will halt. If you want to change ANY of the parameters that governed the generation of the loop delay les then you have to recalculate them. This includes, but is not limited to: the congestion speed, the relevant time period, the output period, the loop lter factor, etc. The parameter DELAY_CALCULATION is probably the most important run le parameter involved in calculating the delays. This parameter tells the program to calculate the delays with respect to a constant congestion speed or with respect to an average congestion speed. This is the same as setting VT in equation 11.14 to a constant or to an average speed. For a constant congestion speed this can be seen in Figure 11.3. This is a typical speed vs. time plot for a single loop detector. Note that the delay here can be positive or negative - this can be changed so that the delay can only be positive. On our study section there is recurrent congestion at a particular time of day at a particular location and we didn't want this congestion to be counted as delay. We decided that if we nd the average speed over all of the days that this would give us a pretty good measure of where the recurrent congestion was taking place. If the congestion speed is taken to be the average then the picture will look more like Figure 11.4. In order to use the average speeds you need to rst calculate them. In Chapter 12 there is a

11.3. THE LOOP DELAY FILES

Negative Congestion Positive Congestion

159
Main Line Speed

Speed Congestion Speed

Time

Figure 11.3: Delay Calculation wrt A Constant. complete example of how to calculate the average speeds and how to then calculate the loop delay les and the delay per incident. If the run le parameter DELAY_CALCULATION is set to indicate that the congestion speed should be a constant, then the program will get the congestion speed from the parameter TRAFFIC_LOW_SPEED. The parameter DELAY_TYPE tells the program whether or not to allow negative delays. If the value of VT is larger than the value of Vki in equation 11.14 then the delay can be negative. Since it is not known whether it is meaningful for the delay to be negative or not we leave this up to the user. If delays are not allowed to be negative then all negative delays are set to zero.

11.3.2 Extra Loop Files

Even though I don't want to lead the discussion too far astray, I need to mention that there are some other les that are generated, or can be generated, when the program is calculating the loop delay les. On the rst reading the reader can skip to Section 11.4 without any loss of continuity.

The Loop Delay Tables: For each time slice a table is made that holds the various parama eters for the delay calculation. These tables are placed into a L TEX le that can be processed to produce a postscript document that can be printed to any printer. The details on how to do this are given in Chapter 13 with the le naming conventions given in Chapter 15.

The Cumulative Loop Delay Files: For each time period a le is made that is the cumulative loop delay for the whole freeway. This is discussed in Chapter 15.

160
Negative Congestion

CHAPTER 11. PROGRAM INPUT: CROSS DATA ANALYSIS

Positive Congestion Main Line Speed

Speed

Average Speed

Time

Figure 11.4: Delay Calculation wrt The Average.

The Loop Emission Files: The amount of emissions produced on the freeway is calculated

for each loop segment and each time slice. The emissions calculated are for hydrocarbons, nitrogen compounds, and carbon monoxide. Once again, these are discussed in Chapter 15.

11.4 Fixing The Incident Data

In addition to processing the loop les to generate the good loop data, the program also needs to process the car data in order to x various elds in the incident database. Since the processing of the car data and the xing of the incident data are so closely tied together, I will discuss them in the same section. When processing the incident data the rst step that is taken is to lter the incident data. The format of the incident lter is discussed in Chapter 9. Since the ltering of the incidents is pretty straight forward we will assume in this section that the incidents have already been ltered. A more detailed look at the data ow for xing the incidents is given in Figure 11.5. There are two things that the program tries to x about the incidents: the incident position and the incident duration. The box labeled \Fix incident placement" in Figure 11.5 has three di erent arrows pointing to it. The arrow in the middle simply represents the incidents being passed from the routine that lters out the correct incidents. The two other arrows come from the car data and a runtime le. These are meant to represent that the data for the incident location x can come directly from the car data or from a runtime le. Since processing the car data takes so long what we prefer to do is to process the car data once and then save the results in a le. This le can then be read in at runtime instead of processing the car data. This saves a considerable amount of time. The box labeled \Fix incident duration" does almost the same

11.5. FINDING THE DELAY FOR EACH INCIDENT

Incident Data Flow

161

Raw incident data

Car data

Runtime file

Fix incident placement

Runtime file Fix incident duration

Good incident data

Figure 11.5: Data Flow For Fixing The Incidents. thing as the \Fix incident placement" box except that it xes the incident durations instead of their locations. Either of these xes can use the car data or the runtime le independently of the other. There are some run le parameters that you have to set if you want to use the car data to x the incident data. The algorithms used to x the incident data are explained in detail in Sections 5.3.1 and 5.3.2 and examples of doing each of these xes are given in Chapter 12. We will assume that the runtime les are going to be used from now on. There are so many les that are generated during the processing of the car data that I won't even give a quick summary here. A complete list, with examples, is given in Chapter 14.

11.5 Finding The Delay For Each Incident

The nal goal of all of this processing is to gure out the delay for each incident. The data ow of the incident delay calculation looks like Figure 11.6. The routine takes in the loop delay les and ltered incidents and then calculates the delay per incident.

11.5.1 Incident Delays By Distance

On way to calculate the incident delay is to simply sum up the delay over the adjacent loop detectors for the time period of the incident. This can be represented with the following equation:

Dincident =

i2ADJ j 2 Ts Te ]

Dij

(11.15)

162

CHAPTER 11. PROGRAM INPUT: CROSS DATA ANALYSIS

Delay Calculation Flow

Good loop data

Good incident data

Process incidents

Delay bounding box

Delay per incident

Histograms

Delay vs. Duration

Cumulative distributions

Figure 11.6: Processing The Incidents. Where ADJ is the set of adjacent loop detectors de ned below, Ts is the incident start time, Te is the incident end time and Dij is the delay on segment i during time slice j . This is probably the most straight forward way of calculating the delay per incident. The set of adjacent loop detectors, or ADJ in formula 11.15, is de ned by the following run le parameters: DELAY UPSTREAM NUM: This parameter tells the program the number of upstream loop detectors that you want to include in the delay calculation. A value of -1 indicates that you want to go all of the way back to the beginning of the study section. Note that the current loop detector is always included. DELAY DOWNSTREAM NUM: This parameter tells the program the number of downstream loop detectors that you want to include in the delay calculation. A value of -1 indicates that you want to go all of the way down to the end of the study section. This is usually set to zero to indicate that you don't want to look at any detectors downstream. For example, if DELAY_UPSTREAM_NUM was set to 3 and DELAY_DOWNSTREAM_NUM was set to 1 then the 3 upstream detectors and the rst downstream detector from the incident site, for a total of 5 detectors, would be used in the delay calculation. Figure 11.7 is a picture of a typical speed vs. distance plot for a single time slice. In this picture, there was an incident that occurred at detector #6. We can see that the incident caused tra c to slow down upstream of the incident for approximately 4 detectors. We should probably include the upstream detectors 20, 9, 2 and 11, and the downstream detector 18 in our calculation of the delay for this incident.

11.5. FINDING THE DELAY FOR EACH INCIDENT

Speed Incident Loop speed

163

Congestion speed

16 3

1 7 20 9 2 11 6 18 19 13 Distance / Loop Detectors

Figure 11.7: Incident At One Time Slice. The main problem this method of incident delay calculation is that the number of detectors to include in the set ADJ is xed for all of the incidents. When you tell the fsp program that you want to go upstream 4 detectors to calculate the delay then this means you want to do that for every incident. This is obviously going to be a problem. If there are two incidents of di erent duration during di erent periods of tra c ow then there is no reason to expect that the length of the queue buildup would be the same. One possible way to get around this is to use all of the upstream detectors when calculating the delay. But if there are multiple incidents during the same time period then you will be double counting the delay from one of the incidents. The way around these problems is to perform the incident delay calculation a di erent way.

11.5.2 Incident Delays By Bounding Box

There is a di erent way to calculate the delay per incident that is speci c to each incident. This is done by guring out where the e ect of each incident ends and de ning a bounding box around this region. This is done in a few steps: 1. Calculate the density for each loop detector for each time slice - exactly like the loop delay but for tra c density. 2. Make a contour plot of the tra c density for each shift with the incidents plotted on top. 3. Determine from the contour plot how far upstream the e ect of the incident is felt. This can be done by guring out where the density returns to normal. 4. Determine how long the incident has an e ect on the density. This can be done by looking for the time that the density returns to normal.

164

CHAPTER 11. PROGRAM INPUT: CROSS DATA ANALYSIS

5. These parameters form a box in time-space coordinates. Save these parameters, for each incident, to a le. 6. Read this le in at runtime and calculate the delays only over that bounding box. An example of this can be seen in Figure 11.8. Figure 11.8 is a plot of the di erential density
Southbound Diff. Density: lp031993 (Ref spd = AVG)

Ls
17

Distance Loop Detector

Time

Figure 11.8: Density Contour With Incident. over distance and time. The di erential density is the density for a speci c day divided by the average density for the whole study period. This specify plot is for the southbound section on 3/19/93. The only incident plotted on this graph is incident #17. The dark solid box is the time that we think the incident occurred. This duration could be the duration in the incident database or it could be the xed duration - it depends on what parameters you speci ed in the run le. The height of the box has no meaning - it is just there so that you can see the incident. The midpoint of the box is centered where we believe the incident took place. As you can see, there are some contours that start right when our incident starts and then build upstream. Once the incident is cleared the density starts to dissipate. The dotted box on the plot is the bounding box that should be de ned for this incident. Note that it completely covers the bubble in density that was caused by this incident. With this new information the program can calculate the delay for this incident in step 6 above as:

Dincident =

X
0

i2 Le Ls] j 2 Ts Te]

Dij

(11.16)

The bounding box le that is read in at runtime is shown as the circle in Figure 11.6. The run le parameter that you need to set to perform this type of incident delay calculation is FIX_INC_DELAY_BOX. This parameter has two possible values:

11.5. FINDING THE DELAY FOR EACH INCIDENT

165

to calculate the incident delay. YES FIX INC DELAY: This will tell the program to read in the bounding box at runtime and to use equation 11.16 to calculate the delay per incident. Once again, there are a number of problems with using this method: The bounding boxes have to be square. There is no fundamental reason for this other than programming simplicity. If an incident doesn't have a bounding box de ned in the runtime le then the delay for that incident is assumed to be zero. Even when inspecting the density plots by hand it is hard to separate multiple incidents. At present, there is no way to deal with multiple incidents where the congestion, or the queues, overlap.

NO FIX INC DELAY: This will cause the method described in Section 11.5.1 to be used

166

CHAPTER 11. PROGRAM INPUT: CROSS DATA ANALYSIS

Chapter 12

Examples With The Run le

Since manipulating the run le can be pretty daunting I have included some helpful hints and quite a few examples. The hints rst: Always start with another run le. There are usually too many parameters to type in for you to type in everything every time. Don't delete lines in the run le, just comment them out. This will allow you to switch back and forth between di erent options really quickly and you won't have to remember all of those parameter names. The comment character is the \#" symbol. If the program can't read in a line in the run le then try deleting the line entirely and re-typing it. Sometimes control characters can hide themselves in lines. You can not have more than 500 lines in the run le. If you need more lines then you have to change the de ned variable MAX_NUM_RUNFILE_STRINGS in the le fsp.h to be larger and then recompile the program and run it again. You have to have an equals sign in each one of the lines, even if you are just going to use the default value. If you are trying to generate error reports for the loop data and nothing is coming out then make sure that you have speci ed some tests to run. Remember that the default for all of the loop tests is OFF. If you think that some parameter is not being read in then you can put the program in preliminary debug mode. This is done by placing an extra \1" on the end of the command line. Something like:
clair 10: fsp my.runfile my.inc.filter 0 1

This will simply print out all of the parameters that the program nds in the run le. 167

168

CHAPTER 12. EXAMPLES WITH THE RUNFILE

12.1 General Parameters

There are a few general parameters to the run le that are usually never changed. I will list these out here and then assume that they are always speci ed in the following examples. Almost all of the parameter defaults are either \NO" or \OFF," whichever is appropriate. So if a parameter is ever left out of a run le then it is assumed to be set to the default. The following is only a part of a run le. You could say that it's the run le header because it doesn't do anything by itself - it only sets up boring general parameters:
# This is my boring runfile header. GNU_PRINTER = lw273 ERROR_FILE_NAME_EXT = err NAV_DATA_FILE_NAME = nav.dat KEY_DATA_FILE_NAME = key.dat CAR_DIRECTORY_ROOT = car REPORT_DESTINATION = FILE DEBUG_LEVEL = SILENT_DEBUG #DEBUG_LEVEL = MINIMUM_DEBUG #DEBUG_LEVEL = DETAIL_DEBUG #DEBUG_LEVEL = VERBOSE_DEBUG

(1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11)

The numbers after each line are not part of the run le - they are just there for reference purposes. A line by line explanation of the above run le follows: 1) This is a comment. It is ignored by the program. 2) This speci es which printer all of the plots should go to. This string is placed directly in the gnuplot executable les. 3) This will specify the extension for the car error les. 4) This will specify the name of the le that holds the digital compass data. 5) This will specify the name of the le that holds the key presses from the probe vehicles. 6) This will specify the pre x of the directory names that hold the car data. 7) This will send all of the car reports to a le. 8) This will tell the program to not print out any debugging information. 9) Lines 9 - 11 are all comments. I usually leave lines like this in my run le so that I can switch between options without having to remember what the exact spelling is. Most of these parameters won't ever need to be changed. Except for GNU PRINTER, they are all relics from the early days of this project. Instead of taking them out, I have decided to leave them in place in case somebody thinks up a use for them.

12.2. EXAMPLE 1: JUST CAR DATA

169

12.2 Example 1: Just Car Data

This example will deal only with the car data. Let's say that we had three main directories of car data and the rst two had 4 cars worth of data and the last one had 3. So our directory structure inside of the car data directory looked like this:
am111492 | |-|-|-|-pm111492 | |-|-|-|-am111592 | |-|-|-<= one main directory... car1 car2 car3 car4 <= car data...

<= main directory... car1 car2 car3 car4 <= car data...

<= main directory... car1 car2 car3 <= car data...

And we wanted to have a lot of reports and we wanted to delete the intermediate les. Then one possible run le would be:
MAIN_DIRECTORY MAIN_DIRECTORY MAIN_DIRECTORY REPORT_OPTION REPORT_DESTINATION CLEAN_UP_OPTION GORE_POINTS ERROR_FILE_NAME_EXT = = = = = = = = am111492 1 2 3 4 pm111492 1 2 3 4 am111592 1 2 3 EVERYTHING FILE DELETE_FILES YES_CALC_GORE_POINTS

(1) (2) (3) (4) (5) (6) (7) (8)

Things to note: The value of ERROR_FILE_NAME_EXT goes to the default value of \err" because nothing was speci ed. The value of DEBUG_OPTION goes to the default value because it wasn't even listed. When specifying the MAIN_DIRECTORY there is at least one space after the directory name and before the numbers of the car subdirectories. If there wasn't then the program wouldn't be able to distinguish between the main directory name and the car subdirectory numbers.

170

CHAPTER 12. EXAMPLES WITH THE RUNFILE

The gore points are calculated and stored in the appropriate les. The incidents are not calculated and therefore are not stored. The plots of distance vs. time for both the car position and the incident position are saved in appropriate les.

12.3 Example 2: More Car Data

Next, let's say that we had 12 sets of data, some with 4 cars and some with 3, with the names of the various main car directories being:
chevy1 chevy2 chevy3 morning1 morning2 morning3 ford1 ford2 ford3 ford4 evening day1

So the data is spread out over various directories. Then one possible run le would be:
# This is our runfile. ( This line is a comment line ) MAIN_DIRECTORY = chevy1 1 2 3 MAIN_DIRECTORY = chevy2 2 3 4 MAIN_DIRECTORY = chevy3 1 2 3 4 MAIN_DIRECTORY = ford1 1 2 3 4 MAIN_DIRECTORY = ford2 1 2 3 MAIN_DIRECTORY = ford3 1 2 3 MAIN_DIRECTORY = ford4 1 2 4 MAIN_DIRECTORY = morning1 1 2 3 4 MAIN_DIRECTORY = morning2 1 2 3 4 MAIN_DIRECTORY = morning3 1 2 3 4 MAIN_DIRECTORY = evening 1 4 MAIN_DIRECTORY = day1 1 4 CAR_DIRECTORY_ROOT = car REPORT_OPTION = EVERYTHING REPORT_DESTINATION = FILE CLEAN_UP_OPTION = DELETE_FILES ERROR_FILE_NAME_EXT =

In this example the only output that that will be generated is the diagnostic reports for the cars and those will be stored in the directory de ned in the le fsp_dirs.h by the de ned variable CARDATA_REPORTS_DIR.

12.4 Example 3: Lots Of Car Data

This is another car example. In this example we want to generate a couple of di erent plots for the data in the directory am031093 for car 1. The speci cations are as follows: 1. Generate all of the car error reports. 2. Place the car error reports in les.

12.5. EXAMPLE 4: GENERAL LOOP DATA EXAMPLE

3. Clean up the temporary car les that were made. 4. Don't spit out any debug information. 5. Include the information from the GORE points. 6. Don't include the INRAD points. 7. Generate the speed-time plots. 8. Don't generate the speed-distance plots. 9. Use the default speed ltering factor. 10. Specify the printer name as \s307". 11. Use the default of everything else.

171

The run le for this example follows. Note that you shouldn't put the numbers on each line - those are just there to point out which step is which.
# Example runfile # REPORT_OPTION REPORT_DESTINATION CAR_CLEANUP DEBUG_LEVEL GORE_POINT_OPTION INRAD_POINTS SPEED_TIME_PLOTS SPEED_DIST_PLOTS CAR_SPD_FILTER_FACTOR GNU_PRINTER

= = = = = = = = = =

EVERYTHING FILE DELETE_FILES SILENT_DEBUG YES_CALC_GORE_POINTS NO_INRAD_POINTS YES_SPEED_TIME_PLOTS NO_SPEED_DIST_PLOTS s307

(1) (2) (3) (4) (5) (6) (7) (8) (9) (10)

MAIN_DIRECTORY = am031093 1

This run le will process the data in the directory am031093 for car number 1.

12.5 Example 4: General Loop Data Example

Loop data is handled the same way as car data except for the parameter strings. If you had loop data on February 4, 1993 and you had data for the detectors 1, 2, 5, 10, and 15, then the line in the run le would look like this:
LOOP_DIRECTORY = lp020493 1 2 5 10 15

So a full edged loop example looks like this:

172

CHAPTER 12. EXAMPLES WITH THE RUNFILE

REPORT_OPTION = FILE REPORT_DESTINATION = EVERYTHING CAR_CLEANUP = DELETE_FILES DEBUG_LEVEL = SILENT_DEBUG ERROR_FILE_NAME_EXT = NAV_DATA_FILE_NAME = KEY_DATA_FILE_NAME = CAR_DIRECTORY_ROOT = LOOP_TEXT = LOOP_BOTH_REPORTS LOOP_DIRECTORY = lp030993 1 2 3 4 5 6 7 8 9 10 11 12 13 15 16 17 18 19

A few things to note about this example: In this example we still had the parameters that deal with the car data, CAR_CLEANUP, CAR_DIRECTORY_ROOT, etc. This is perfectly all right. Since there is no car data to process these parameters are read in but then nothing is done with them. This example will attempt to produce the text and error report for the loop data set. Since the time periods for the loop data set are not speci ed, the default values will be used. Since LOOP_TEXT was set to LOOP_BOTH_REPORTS, you could assume that the user wanted to generate an error report. But since the default for all of the loop tests is OFF no tests are run and therefore the error report won't have any results in it. This is probably a mistake and the user should specify some tests to perform.

12.6 Example 5: Complicated Loop Data Example

A more sophisticated loop data example would entail the following: 1. Generate all of the car error reports. This setting will have no e ect since we don't specify any car data sets. 2. Place the car error reports in les. This setting will have also no e ect since we don't specify any car data sets. 3. Don't spit out any debugging information. 4. Specify the printer name as \s307". 5. Set the value of PPS to mean \counts per output period." 6. For the loop data generate both an error report and a text report. 7. Start the loop report at 6:00am (i.e.: 21600 seconds since midnight the night before). 8. End the loop report at 8:00am (i.e.: 28800 seconds since midnight the night before).

12.7. EXAMPLE 6: COMPUTING THE DELAY WRT THE AVERAGE

9. For the loop report, print out a value every 60 seconds. 10. For the loop report, generate the speed, occupancy, and count plots.

173

11. For the error reports, only test if the speed or occupancy is above a certain value. Don't test for anything else. The run le for this example follows. Note that you shouldn't put the numbers on each line - those are just there to point out which step is which.
# This runfile was made automatically # by the PC software ftran. # REPORT_OPTION = EVERYTHING REPORT_DESTINATION = FILE DEBUG_LEVEL = SILENT_DEBUG GNU_PRINTER = s307 OUTPUT_FLOW_AVG_FACTOR = MATCH_OUTPUT_PERIOD LOOP_TEXT = LOOP_BOTH_REPORTS LOOP_START_TIME = 21600 LOOP_END_TIME = 28800 LOOP_OUTPUT_PERIOD = 60 LOOP_FLOW_PLOTS = YES_CALC_ALL_FLOW_PLOTS LP_SPEED_HIGH_TEST = YES LP_OCC_HIGH_TEST= YES LP_SPEED_HIGH_THRESHOLD_MPH = 90 LP_SPEED_HIGH_THRESHOLD_NUM = 2 LP_OCC_HIGH_THRESHOLD_PERCENT = 50 LP_OCC_HIGH_THRESHOLD_NUM 5 LOOP_DIRECTORY = lp030993 1 10 16

(1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (11) (11) (11) (11) (11)

12.7 Example 6: Computing The Delay WRT The Average

One of the more complicated things to do is to calculate the delay with respect to the average. The loop averages are the averages over the all of the days of the speeds, counts, occupancies, and densities. These les are used to calculate the delay for each incident with respect to the average and to generate the contour plots of di erential density. The nice thing about the loop averages is that they probably only have to be calculated once. Unfortunately, that rst calculation is a bit hard. For programming reasons this calculation needs to be done in a couple of passes of the program. The steps that we are going to follow are given below:

174

CHAPTER 12. EXAMPLES WITH THE RUNFILE

1. In the rst pass of the program we will calculate the standard speed, ow, occupancy, and density values for each loop detector for each day. We will also calculate the average of these values over the days. 2. In the second pass we will calculate the delay at each loop detector with respect to the average. 3. As a nal step we will copy the delay les to a special directory so that they are not corrupted by further runs of the program. This is done with the fsp-generated program called copydat. Since we are only going to be dealing with the loop data in the run le listings that follow I will not include any parameters that deal with the car data or the incident data. In this pass we will calculate the speeds, ows, occupancies, and densities for the loop data. We will also calculate the averages for these values over the days. Note that the averages are only generated from the loop data speci ed. If you only specify 1 day of loop data then you'll have a pretty boring average. If you look below you will notice that we specify that we want to calculate the tra c delay with respect to a constant. Actually, we don't really care about the tra c delay at this point. The reason that we have to run the routine that calculates the tra c delay is because that's where the densities are calculated as well. The density calculation routine probably shouldn't be mixed in with the delay calculation stu but tradition is a very strong force. Once the standard values are calculated the program will attempt to calculate the average for these values over all the days. It will place these values in a subdirectory named Avg under the main loop output directory. The run le to do all of this is given below. Note that this run le is distributed with the source code for the fsp project. It's name is lp.avg.1.run. In the list that follows there are quite a few run le parameters that have been left out because they don't have anything to do with what I am trying to show. You should set those to appropriate values when running the fsp program.
LOOP_START_TIME LOOP_END_TIME LOOP_OUTPUT_PERIOD OUTPUT_FLOW_AVG_FACTOR CAR_DATA_SET_NUMBER LOOP_DATA_DIRECTORY CAR_DATA_DIRECTORY INCIDENT_DATA_DIRECTORY OUTPUT_DIRECTORY FLOOP_CLEANUP GLOOP_CLEANUP HLOOP_CLEANUP LOOP_FLOW_PLOTS LOOP_TEXT = = = = = = = = = = = = = = 18000 72000 300 MATCH_OUTPUT_PERIOD 1 /home/pal2/FSP/Set1/Loopdata /home/pal2/FSP/Set1/Cardata /home/pal2/FSP/Set1/Incidents /home/pal2/FSP/Tempout DELETE_EVERYTHING DELETE_NOTHING DELETE_NOTHING YES_CALC_ALL_FLOW_PLOTS LOOP_ERR_REPORT_ONLY

12.7.1 The First Pass: Standard Values

(1) (2)

12.7. EXAMPLE 6: COMPUTING THE DELAY WRT THE AVERAGE

175

DROPOUT_TIMES = YES_DROPOUT_FILE (2) LOOP_DATA_COMPRESSED = DATA_IS_COMPRESSED LOOP_CONSISTENCY_FIX = NO_FIX_CONSISTENCY_ERRORS LOOP_HOLES_FIX = YES_FIX_HOLE_ERRORS (2) TRAFFIC_DELAY = YES_CALC_TRAFFIC_DELAY (3) DELAY_CALCULATION = WRT_CONSTANT_SPEED (3) DELAY_TYPE = ONLY_HAVE_POSITIVE_DELAY (3) TRAFFIC_LOW_SPEED = 55 (3) LOOP_AVERAGE = YES_LOOP_AVERAGE (4) LOOP_DIRECTORY = lp021693 1 2 3 4 5 6 7 8 9 10 11 12 13 15 16 17 19 20 LOOP_DIRECTORY = lp021793 1 2 3 4 5 7 8 9 10 11 12 13 15 16 17 19 20 LOOP_DIRECTORY = lp021893 1 2 3 4 5 6 7 8 9 10 11 12 13 15 16 17 18 19 20

There are a few things that should be pointed out about the list above. These items are marked on the right hand side with various numbers: 1. The item marked (1) tells the fsp program to generate the speeds, occupancies, and ows for the loop detectors. 2. The items marked (2) are necessary to specify that the program should x the holes in the loop data. The average probably isn't going to be very good if you don't use the xed loop data. 3. The items marked (3) tell the program to calculate the delay on the loops with respect to a constant. Note that a side e ect of doing this is that the program calculates the density values for the loops and this is what we will use later on. Note that at this point we can not calculate the delay with respect to the average and that it must be done with respect to a constant. The reason for this is that the average les don't exist yet (you are in the process of making them right now). 4. Finally, item (4) tells the program to calculate the loop averages and to place them in the special directory called Avg under the loop output directory. For this run le the complete path name of this directory would be /home/pal2/FSP/Tempout/Loopdata/Avg. The averages in this example will only be over the three days 2/16, 2/17, and 2/18.

12.7.2 The Second Pass: Calculating The Delay

LOOP_START_TIME LOOP_END_TIME LOOP_OUTPUT_PERIOD OUTPUT_FLOW_AVG_FACTOR CAR_DATA_SET_NUMBER LOOP_DATA_DIRECTORY CAR_DATA_DIRECTORY = = = = = = =

In the second pass we will use the loop average les that were computed during the last pass to calculate the delay with respect to the average. The listing is given below:
18000 72000 300 MATCH_OUTPUT_PERIOD 1 /home/pal2/FSP/Set1/Loopdata /home/pal2/FSP/Set1/Cardata

176

CHAPTER 12. EXAMPLES WITH THE RUNFILE

INCIDENT_DATA_DIRECTORY = /home/pal2/FSP/Set1/Incidents OUTPUT_DIRECTORY = /home/pal2/FSP/Tempout FLOOP_CLEANUP = DELETE_EVERYTHING GLOOP_CLEANUP = DELETE_NOTHING HLOOP_CLEANUP = DELETE_NOTHING LOOP_FLOW_PLOTS = NO_CALC_LOOP_FLOW_PLOTS (1) LOOP_TEXT = LOOP_NO_REPORTS DROPOUT_TIMES = NO_DROPOUT_FILES LOOP_DATA_COMPRESSED = DATA_IS_COMPRESSED LOOP_CONSISTENCY_FIX = NO_FIX_CONSISTENCY_ERRORS LOOP_HOLES_FIX = YES_FIX_HOLE_ERRORS (2) TRAFFIC_DELAY = YES_CALC_TRAFFIC_DELAY (3) DELAY_CALCULATION = WRT_AVERAGE_SPEED (3) DELAY_TYPE = ONLY_HAVE_POSITIVE_DELAY TRAFFIC_LOW_SPEED = 55 LOOP_AVERAGE = NO_LOOP_AVERAGE (4) LOOP_DIRECTORY = lp021693 1 2 3 4 5 6 7 8 9 10 11 12 13 15 16 17 19 20 LOOP_DIRECTORY = lp021793 1 2 3 4 5 7 8 9 10 11 12 13 15 16 17 19 20 LOOP_DIRECTORY = lp021893 1 2 3 4 5 6 7 8 9 10 11 12 13 15 16 17 18 19 20

A couple of things to point out about this listing: 1. We no longer need to generate the standard loop les of speeds, occupancies, and ows because this was done in the 1st pass. This is done on the line labeled (1). 2. We still need to specify that we want to use the loop data that has had the holes xed. This is done on the line labeled (2). 3. We now calculate the loop delay with respect to the average instead of with respect to a constant. This is done on the lines labeled (3). 4. Finally, note that on the line labeled (4) that we don't have to compute the average more than once. Once the delay with respect to the average les have been calculated we need to move them to a special directory so that they will not be overwritten by subsequent passes of the fsp program. This special directory is called Delay and it is located in the main loop output directory. Underneath the Delay directory is a directory for each day of loop data. These directories will hold the loop delay les that were computed with respect to the average. Note that safety is not the only reason for moving the loop delay les les to this special directory. When the program attempts to calculate the delay for each incident it reads in the loop delay les that correspond to the space-time box that the incident covers and adds up the delay in that box. Well, there are two di erent places the program can get the delay les from depending on what type of calculation it is doing. If the program is doing the delay calculation with respect to a constant then the loop delay les are pulled out of the normal

12.7.3 The Final Step: Moving The Files To A Safe Place

12.8. EXAMPLE 7: GENERATING THE CONTOUR PLOTS

177

loop day directories. The program assumes that the les there were calculated with respect to a constant. If the program is doing the delay calculation with respect to the average then the loop delay les are pulled out of the Delay directory structure. These les can be moved with the help of a shell script program that is generated by the fsp program in the loop output directory. If you change into the loop output directory you will see that there is a le called copydat. This le will copy all of the loop delay les to the appropriate place under the Delay directory. To run this program simply type copydat at the command line.
clair 10: copydat Starting to copy files... Processing: lp021693 Processing: lp021793 Processing: lp021893 Done

Once you have copied the les the program will be completely set up to take advantage of the average loop delay les.

12.8 Example 7: Generating The Contour Plots

One very helpful analysis tool is to be able to generate the various contour plots of the loop data with the incidents on them. This is helpful when you want to draw the space-time boxes around the incidents so that you can get a more accurate measurement of the delay per incident. The run le that is needed to do this is straight forward. The only requirement is that the loop average les need to have been calculated. This was done in Section 12.7. The steps that we have to take to generate the contour plots are pretty straight forward: 1. We don't have to do any more calculation with the loop data. This, of course, assumes that the loop delays have already been calculated. 2. We need to tell the program to process the incidents and to generate the contour plots with those incidents. 3. We need to create an incident lter to our liking. In the example below we will lter out all of the accidents that occurred within our shift. Once again, a few parameters have been left out because they don't concern us. This run le is also in the source code that came with the fsp program. It is called contour.run:
LOOP_FLOW_PLOTS LOOP_TEXT DROPOUT_TIMES LOOP_CONSISTENCY_FIX LOOP_HOLES_FIX = = = = = NO_CALC_LOOP_FLOW_PLOTS LOOP_NO_REPORTS NO_DROPOUT_FILES NO_FIX_CONSISTENCY_ERRORS YES_FIX_HOLE_ERRORS

(1)

178

CHAPTER 12. EXAMPLES WITH THE RUNFILE

TRAFFIC_DELAY = NO_CALC_TRAFFIC_DELAY LOOP_AVERAGE = NO_LOOP_AVERAGE LOOP_AGGREGATE_VALUES = NO_CALC_AGGREGATE_VALUES LOOP_DIRECTORY = lp021693 1 2 3 4 5 6 7 8 9 10 11 12 13 15 16 17 19 20 LOOP_DIRECTORY = lp021793 1 2 3 4 5 7 8 9 10 11 12 13 15 16 17 19 20 LOOP_DIRECTORY = lp021893 1 2 3 4 5 6 7 8 9 10 11 12 13 15 16 17 18 19 20 PROCESS_INCIDENTS = YES_PROC_INCIDENTS (2) FIX_INC_DURATION = NO_FIX_INC_DURATION (3) FIX_INC_LOCATION = YES_FIX_INC_LOC (3) FIX_INC_DELAY_BOX = NO_FIX_INC_DELAY (3) INC_CONTOUR_DELAY_PLOT = YES_INC_CONTOUR_DELAY_PLOTS (4) CORRELATE_CARS_DATABASE = NO_CORRELATE (5)

Some things to point out about the run le listed out above: All of the loop calculation parameters are turned o . It is assumed that the loop averages have already been made as was done in Section 12.7. We still need to specify that the holes in the loop data were xed as is done in the line labeled (1). Actually, this parameter is used throughout the program to indicate whether we should use the oop, gloop, or hloop les. So it's required that you always specify this. We need to tell the program to process the incidents as is done in the line labeled (2). The various incident xes can be on or o , it doesn't matter. You can see in the lines labeled (3) that I have chosen to x the incident locations but not their durations or the delay boxes. The most important item is on the line labeled (4). This line tells the program to generate the contour plots. The program will make contour plots for the delay, density and di erential density. We don't need to correlate the incident database with the car data (actually, we probably never want to do this because it takes too long). Note that there are a few parameters that deal with the incident output that were not mentioned. As was mentioned above, this example is going to generate the contour plots with the accident incidents on them. Therefore, we need to provide an incident lter that will lter out the accidents. The incident lter that was used to do this is given below:
DATE INCIDENT_TYPE_2 BEGIN_END = 2/16/93 - 2/19/93 = 1 2 = 0

(1) (2) (3)

12.9. EXAMPLE 8: FIXING THE INCIDENT LOCATIONS

179

12.9 Example 8: Fixing The Incident Locations

One useful thing to be able to do is to x the incident locations with the help of the probe vehicle data. This is going to be done with the incident database-probe vehicle correlation routine. Much like the example involving the calculation of the loop averages in Section 12.7, this procedure involves a couple of steps. The steps that we will take to do this are as follows: 1. In the rst pass of the fsp program we will specify the incident and car data that we wish to examine and have the program generate the corresponding correlation plots. 2. Next, we will print these plots out and gure out which incidents should be shifted. We will then code this information into the incident location x le. 3. In the second pass of the fsp program we will tell the program to attempt to x the incident locations with the incident location x le that we just made. 4. In the nal step we will look at the results of the correlation that we just and examine the new incident location x table that the fsp program generates. This table will then become our nal incident x le.

12.9.1 Step 1: Generating The First Plot

In the example that follows I will only deal with one shift of car data and incidents. In reality, you should probably do this for all of the incidents but it would just take too long in this example. The incident lter that we will use only pulls out the incidents that occurred on February 22, 1993 during the morning shift. It is given below:
DATA_TYPE DATE SHIFT = F = 2/22/93 - 2/23/93 = 0

The rst run le that we will need should just process the appropriate car data and then generate the correlation graph. A run le that does this is given below. Note that there are quite a few parameters that aren't provided in the run le. These were left out because they obscure the message. You should set them to appropriate values when attempting this x.
CAR_DATA_SET_NUMBER LOOP_DATA_DIRECTORY CAR_DATA_DIRECTORY INCIDENT_DATA_DIRECTORY OUTPUT_DIRECTORY GORE_POINT_OPTION INCIDENT_POINTS INRAD_POINTS SPEED_TIME_PLOTS SPEED_DIST_PLOTS TIME_DIST_PLOTS MAIN_DIRECTORY = = = = = = = = = = = = 1 /home/pal2/FSP/Set1/Loopdata /home/pal2/FSP/Set1/Cardata /home/pal2/FSP/Set1/Incidents /home/pal2/FSP/Tempout YES_CALC_GORE_POINTS YES_INCIDENT_POINTS YES_INRAD_POINTS NO_SPEED_TIME_PLOTS NO_SPEED_DIST_PLOTS NO_TIME_DIST_PLOTS am022293 1 3 4

(1) (1) (1) (2) (2) (2) (3)

180
PROCESS_INCIDENTS FIX_INC_DURATION FIX_INC_LOCATION FIX_INC_DELAY_BOX INC_CONTOUR_DELAY_PLOT CORRELATE_CARS_DATABASE INC_CORRELATION_GRAPH NUMBER_INC_CORR_GRAPHS INC_MATCH_ZERO_WIDTH = = = = = = = = =

CHAPTER 12. EXAMPLES WITH THE RUNFILE

YES_PROC_INCIDENTS NO_FIX_INC_DURATION NO_FIX_INC_LOC NO_FIX_INC_DELAY NO_INC_CONTOUR_DELAY_PLOTS YES_CORRELATE YES_INC_CORR_GRAPHS YES_NUMBER_INC_CORR_GRAPHS NO_MATCH_ZERO_WIDTH_INC

(4) (4) (4) (5) (5) (5) (6)

A couple of things to point out about this listing: When processing the car data we needed to have the fsp program record the key presses that correspond to incidents. In order to make these more accurate we also need to tell the program to record the gore points and the INRAD points. Remember that these points help to locate the incident key press on the freeway. This is all done on the lines labeled (1). On the lines labeled (2) we tell the program to not generate the various car trajectory plots. We simply don't need them for what we are doing. On line (3) we specify the car data that we want to look at. For this day we only had three cars in the eld. On the lines labeled (4) we tell the program to not attempt to x any part of the incidents. On the lines labeled (5) we tell the program to do the incident database-probe vehicle correlation and to generate the correlation plots. Line (6) tells the program that it should leave out incidents that were only witnessed once. I have done this simply because it makes the correlation plots look better. The normal user might want to leave those incidents in. The main result of the fsp program run with this run le is that there is a correlation le that is saved in the car shift directory. For this example that directory is /home/pal2/FSP/Tempout/Cardata/am022293 and the gnuplot executable to print the le out is called incidentcor.gp. The plot is given in Figure 12.1. This plot gives a really good example of why you would want to attempt to x the incident locations. If we accept that the car key presses mark the correct location of the incidents then it is obvious that incidents 205, 219, 223, and 238 all need to be shifted. You could also see from the textual output below that things are not so good.
Incident database match statistics: Total: # incidents, # covered, ratio = 9, 9, 100.0% Total: # time entries, # matched, ratio = 57, 22, 38.6% Total: # covered incidents, # changed, avg change(ft) = 9, 7, Total: # with new loop, ratio = 0, 0.0% Probe vehicle match statistics:

1715

12.9. EXAMPLE 8: FIXING THE INCIDENT LOCATIONS

Car and database correlation: am022293 10:00

181

9:30

9:00

220

219

8:30
Time

216 213 238 236

8:00

7:30 210 7:00

6:30

205

223

6:00 0 5 10 Position (miles) 15 20

Figure 12.1: Incident Database-Probe Vehicle Correlation Plot.

Total number of entries = 102 Number of entries in study section = 54 # matched entries in study section = 22 ratio = 40.7%

The statistics above are all interpreted in Section 16.2.3, but what we will look at is the last line which says ratio = 40.7%. This means that only 40.7% of the key presses from the probe vehicles were matched with incidents. We will attempt to get this ratio as high as possible.

12.9.2 Step 2: Generating The Location Fix File

From looking at Figure 12.1 you can see how much the incidents need to be moved. Which incidents need to be moved is completely subjective. Take incident 220, for example. There is a key press right before it and a couple right after it. One could argue that this incident should be shifted so that it covers the key press directly to the left. One could also argue that shifting it to the right, to cover the multiple key presses there, is the correct thing to do. Unfortunately, we have not come up with a methodology that will tell us what the drivers actually saw when they pressed their keys. As a result, the shifting of the incidents to cover key presses is completely up to you. I have chosen this day because it is relatively easy to judge what to do for quite a few incidents. If you look at the correlation plots for some of the other days you'll see that in quite a few cases it is nearly impossible to tell how to shift the incidents.

182

CHAPTER 12. EXAMPLES WITH THE RUNFILE

In the input incident directory we will create a le named inc_fix_loc.dat. This le will hold the incident numbers that we would like to move and how much we would like to move them. The format is pretty simple: the rst column is the incident number and the second column is the amount that we would like to shift the incident (in miles). A positive number means that we would like to shift them to the right on the correlation plot and a negative number means that we would like to shift them to the left. When we are shifting the incidents around we would like to make the incident box land right on top of the key presses. So for incident 223 we should probably shift the incident box 1=2 mile to the left. If we did this the entry in the location x le would be:
223 -0.5

A complete incident location x le for this day would look something like this:
205 210 219 220 223 236 238 -0.5 -0.25 -0.25 -0.5 -0.5 -0.1 -0.25

Note that there were a few incidents that were not included. For example, incident 213 is buried in a haze of numbers and key presses. Since I couldn't gure out where to shift this incident I didn't shift it at all. Once the rst incident location x le has been made we can generate the correlation plot again to see how our xes performed. This is done by applying almost the same run le as was used in step 1 except for one change. We need to use the following parameter setting:
FIX_INC_LOCATION = YES_FIX_INC_LOC

12.9.3 Step 3: Adjusting The Incidents

This, of course, tells the program to read in the incident location x le1 that we have just created and use it to shift the incidents around. Note that the shift from the incident location x routine is done before the correlation routine. Once this has been done we can take a look at the textual report and the correlation plot to see how we did. The correlation plot for this second run is given in Figure 12.2 and the textual output is given below:
Incident database match statistics: Total: # incidents, # covered, ratio = 9, 9, 100.0% Total: # time entries, # matched, ratio = 57, 42, 73.7% Total: # covered incidents, # changed, avg change(ft) = 9, 8, Total: # with new loop, ratio = 5, 55.6%
1

739

Note that this le must be in the incident input directory and it must be named \ x inc loc.dat."

12.9. EXAMPLE 8: FIXING THE INCIDENT LOCATIONS

Car and database correlation: am022293 10:00

183

9:30

9:00

220

219

8:30
Time

216 213 238 236

8:00

7:30 210 7:00

6:30

205

223

6:00 0 5 10 Position (miles) 15 20

Figure 12.2: Correlation Plot With Fixed Incident Locations.

Probe vehicle match statistics: Total number of entries = 102 Number of entries in study section = 54 # matched entries in study section = 42 ratio = 77.8%

The textual output indicates that 77.8% of the key presses now match up with some incident. From looking at Figure 12.2 we can see that the incidents now match up nicely with the key presses. It's hard to see how we could possibly match up any more. You would think that these results would indicate that we are done, but we aren't. If we were to stop here then each time that we applied the incident location x the incidents would be shifted only by the amount in the le. The results above say that we only got a 77.8% match, but that was only after the correlation routine shifted the incidents some more. Remember that the correlation routine collects all of the key presses that fall within an incident box and it nds the average location for those key presses. It then sets the new incident location to be this average location. What we want is to make the incident location x le have the correct shifts such that the correlation routine doesn't have to move the boxes around at all. The way to tell if the correlation routine is moving the boxes around is to look at the table it produces:
SUMMARY of all COVERED incidents:

184
Inc # 205 210 213 216 219 220 223 236 238 # Entries # Matched 26 19 3 2 3 3 2 0 2 3 2 1 5 4 3 2 11 8

CHAPTER 12. EXAMPLES WITH THE RUNFILE

Dist(ft) Loop 35640 12 21040 20 41360 17 39600 4 47770 5 29640 18 79400 1 82832 1 68760 19 New Dist(ft) New Loop 35764 13 20474 7 38824 17 39600 4 47619 5 29160 11 79031 20 81901 1 68003 13 Change 0.02 -0.11 -0.48 0.00 -0.03 -0.09 -0.07 -0.18 -0.14

This table was generated after the correlation routine was done a second time. The column labeled \Change" tells how much the correlation routine changed the incident location (in miles). This is simply the distance between the column labeled \New Dist(ft)" and the column labeled \Dist(ft)." Note that the column labeled \Dist(ft)" is the location of the incident after the incident location x was applied. Our goal is to make the values in the column labeled \Change" as small as possible.

12.9.4 Step 4: Adjusting One Last Time

The way to make the values in the \Change" column as small as possible is to add the incident shifts that we already placed in the incident location x le to the values in the column labeled \Change." Fortunately, the fsp program will do this for you. It will even generate a new incident location x table that you can plug directly into the incident location x le. The table that the fsp program generates looks something like this:
Possible new incident location fix table: Incident Shift (miles) 205 -0.48 210 -0.36 213 -0.48 216 0.00 219 -0.28 220 -0.59 223 -0.57 236 -0.28 238 -0.39

You can now take these numbers and place them in the incident location x le, fix_inc_loc.dat and run the fsp program again. The resulting correlation output table will look something like this:
Inc # 205 210 213 # Entries # Matched 26 19 3 2 3 3 Dist(ft) Loop 35746 12 20460 20 38826 17 New Dist(ft) New Loop 35764 13 20474 7 38390 4 Change 0.00 0.00 -0.08

12.10. EXAMPLE 9: FIXING THE INCIDENT DURATIONS

216 219 220 223 236 238 2 2 2 5 3 11 1 3 1 4 2 8 39600 47612 29165 79031 81882 68021 4 5 18 1 1 19 38897 47619 29160 79031 81901 68003 4 5 11 20 1 13 -0.13 0.00 -0.00 0.00 0.00 -0.00

185

As you can see, the values in the \Change" column have almost all gone to zero. This means that the correlation routine is having almost no e ect on the locations of the incidents. In other words, what we have done, by making the incident location x le, is to subtract o the e ect that the correlation routine can have on the incident locations. There are a couple of things to note about the steps that we just took to produce the nal incident location x le: In order for the fsp program to generate the new incident location x table the run le parameter FIX_INC_LOCATION needs to be set to YES_FIX_INC_DELAY. You might be thinking that you could possibly get all of the numbers in the \Change" column to be zero. Actually, that's pretty hard to do. Sometimes when you shift incidents around they get moved over di erent key presses and those key presses pull the incident even farther in the direction that it was just moved. The result is some chatter around a stable point. If you get the values to be almost all zero, or even close, then that should be good enough. A valid question to ask is why don't we just run the incident correlation routine and take the incident location x table that the fsp program suggests and make that the incident location x le for future runs. Well, the correlation routine can't gure out if the key presses lie just outside of an incident box or not. It only takes the key presses that fall inside the incident box and it shifts the new location to be the average location of these key presses. This means that you have to get the incidents close to their correct locations before the correlation routine can be useful.

12.10 Example 9: Fixing The Incident Durations

One x that you can perform on the incident database is the incident duration x. As was discussed in Section 5.3.2, the incident durations that are recorded in the incident database are not accurate. Since the starting and ending times are only the witnessed times, the durations that are in the incident database are all too short. One way to x this is to simply add a xed time to all of the incidents. This is easily done by setting the run le parameter HEADWAY_TIME_VAL to the average probe vehicle headway time. Another, possibly awed2, way to correct for the incident durations is to record the times when probe vehicles passed the incident location and didn't witness the incident. You can then make the corrected incident time (either start time or
2 See the discussion at the end of Section 5.3.2 for an explanation as to why this routine may give biased results.

186

CHAPTER 12. EXAMPLES WITH THE RUNFILE

end time) someplace between the time the incident was witnessed and the time that somebody drove by and it wasn't witnessed. What we will do here in this example is show how to run the routine that adjusts the incident durations by guring out when a probe vehicle passed an incident location and the incident wasn't there. This is done in two steps: First, we will specify what incidents we wish to examine, determine what probe vehicle data we need, and then tell the fsp program to process this data and attempt to x the incident locations from the probe vehicle data. We will then take the incident duration x le that was generated by the fsp program and use that as a runtime le.

12.10.1 Step 1: Using The Probe Data To Correct The Durations

The rst thing that we need to do is to attempt to x the incident durations from the probe vehicle data. To do this we need to specify what incidents we wish to look at and what car data we need. In this example, I will only look at incidents that occurred on February 22, 1993 during the morning shift. An incident lter that will pull these incidents out of the incident database is given below:
DATA_TYPE DATE SHIFT = F = 2/22/93 - 2/23/93 = 0

The run le for this example should tell the program to process the probe vehicle data and to try to correct the incident durations using this data. A run le that will do this is given below. Note that there are quite a few parameters that aren't provided in the run le. These were left out because they obscure the message. You should set them to appropriate values when attempting this x.
CAR_DATA_SET_NUMBER LOOP_DATA_DIRECTORY CAR_DATA_DIRECTORY INCIDENT_DATA_DIRECTORY OUTPUT_DIRECTORY GORE_POINT_OPTION INCIDENT_POINTS INRAD_POINTS SPEED_TIME_PLOTS SPEED_DIST_PLOTS TIME_DIST_PLOTS MAIN_DIRECTORY PROCESS_INCIDENTS FIX_INC_DURATION INC_DUR_EXPAND_FRACTION FIX_INC_LOCATION = = = = = = = = = = = = = = = = 1 /home/pal2/FSP/Set1/Loopdata /home/pal2/FSP/Set1/Cardata /home/pal2/FSP/Set1/Incidents /home/pal2/FSP/Tempout YES_CALC_GORE_POINTS YES_INCIDENT_POINTS YES_INRAD_POINTS NO_SPEED_TIME_PLOTS NO_SPEED_DIST_PLOTS YES_TIME_DIST_PLOTS am022293 1 3 4 YES_PROC_INCIDENTS FIX_INC_DURATION_FROM_DATA 50 YES_FIX_INC_LOC

(1) (1) (1) (2) (2) (3) (4) (5) (6) (6) (7)

12.10. EXAMPLE 9: FIXING THE INCIDENT DURATIONS

CORRELATE_CARS_DATABASE INC_MATCH_ZERO_WIDTH INC_FINISHED_OUTPUT INC_FINISHED_OUT_LEVEL = = = = NO_CORRELATE NO_MATCH_ZERO_WIDTH_INC SCREEN_FINISHED_OUTPUT INC_FIN_OUT_MEDIUM

187

(8)

There are a few things that should be pointed out in the run le above: 1. When processing the car data we needed to have the fsp program record the key presses that correspond to incidents. In order to make these more accurate we also need to tell the program to record the gore points and the INRAD points. Remember that these points help to locate the incident key press on the freeway. This is all done on the lines labeled (1). 2. On the lines labeled (2) we tell the program to not generate the speed vs. time and speed vs. distance car trajectory plots. We simply don't need them for what we are doing. 3. But, on line (3) well tell the program to generate the time vs. distance plot. When the program generates the time vs. distance plot it also records when the probe vehicles passed the various loop detectors. This information is used when attempting to correct the durations. 4. On line (4) we specify the car data that we want to look at. For this example we are just looking at one day. 5. On line (5) we tell the program to process the incidents - the incident duration x routine is in the incident processing section. 6. On the lines labeled (6) we tell the program to x the incident durations from the car data. The expansion fraction is set to 50%. Note that if we hadn't speci ed any car data that the fsp program would not allow us to attempt to x the incident durations using the car data. 7. On line (7) we tell the program to correct the locations of the incidents from the incident location runtime le. We don't have to have this option set - it won't e ect the duration x at all. 8. Finally, on line (8) we tell the program to generate a medium amount of diagnostic information about the incident processing. We do this so that the incident duration x routine will generate a diagnostic table for us. The output that the fsp program generates that we are interested in is in two parts: a diagnostic table that is placed on the screen, and a le that is placed in the incident output directory. The table that was generated by the x incident duration routine is given below:
Incident duration correction statistics: Before New After Inc Start Start Start End End 205 23880 23775 23827 34140 34140 210 27180 26918 27049 28260 28810 New End 34140 28535 Duration 10260 1080 Final Duration 10313 1486

188
213 216 219 220 223 236 238 30060 31080 32760 32940 24180 29220 29820 29672 30440 31564 32521 24180 28211 29479 29866 30760 32162 32730 24180 28715 29649

CHAPTER 12. EXAMPLES WITH THE RUNFILE

30780 31560 33120 33300 25920 30000 33900 31136 32663 33431 34061 26296 30305 33917 30958 32111 33275 33680 26108 30152 33908 720 480 360 360 1740 780 4080 1092 1351 1113 950 1928 1437 4259

This table lists out the start and end times of each incident as well as the times that a probe vehicle went by the incident location but didn't witness it. The columns labeled \New Start" and \New End" are the new starting and ending times of the incident. These should lie somewhere between the original times and the times when the incident wasn't witness. The column labeled \Duration" is the original incident duration and the column labeled \Final Duration" is the corrected duration. The second piece of information that is generated by the x incident duration routine is the le inc.duration.out that is placed in the incident output directory. This le holds columns 1, 3 and 6 from the table above. With these columns you can adjust the incident durations no matter what the expansion fraction is. Now that we have the x incident duration le, inc.duration.out, we no longer have to use the probe vehicle data to x the durations. But before we can use this runtime le we need to copy the le, which was generated in the previous step, to a place where the program will recognize it. In our example the le was place in the incident output directory /home/pal2/FSP/Tempout/Incidents. The fsp program will expect any incident x runtime les to be in the incident data directory which is /home/pal2/FSP/Set1/Incidents. Also, the le needs to be named inc.duration.in instead of inc.duration.out. To copy the le can execute the following command from the incident output directory:
cp inc.duration.out /home/pal2/FSP/Set1/Incidents/inc.duration.in

12.10.2 Step 2: Using The Runtime File To Correct The Durations

Now when we attempt to x the incident durations we can tell the program to use the runtime le instead of the probe vehicle data:
FIX_INC_DURATION = FIX_INC_DURATION_FROM_FILE

This should work exactly the same as using the probe vehicle data but the running time should be a lot faster.

12.11 Example 10: Calculating The Incident Delay With SpaceTime Boxes
Probably the most interesting this to do with the incidents is to calculate the delays. In this example we will go through the steps needed to calculate the delay for each incident by using prede ned space-time boxes. We will assume that the loop delay les have all been calculated,

12.11. EXAMPLE 10: CALCULATING THE INCIDENT DELAY WITH SPACE-TIME BOXES189
and that the contour plots, with the correct incidents on them, have all been generated. These steps were done in Sections 12.7 and 12.8. Since these major steps are out of the way, what we need to do now is the following: Look at each contour plot and decide what the bounding box should be for each incident. Code these boxes into the incident delay box le. Run the fsp program and specify to calculate the incident delay using the bounding boxes. Note that even though we can't really deal with incidents that overlap, this is probably the best way to calculate the delay for each incident. A complete discussion of the di erent incident delay calculation can be found in Chapter 11.

12.11.1 Step 1: Figuring Out The Bounding Boxes

The contour plot that I will use in the example is the delay contour for the southbound, morning shift of 2/18/93. I will assume that the delay contour has already been generated. We will make space-time boxes for all of the incidents on this plot. The contour plot is given in Figure 12.3. You can see on this gure that there are a few incidents where the space-time boxes
Southbound Delay: lp021893 (Ref spd = AVG) 3 1 107 5 15 17 104 108 117 4 12 13 19 112 Det. # 18 6 11 2 105 116 110 9 20 7 1 3 16 5:00 5:30 6:00 6:30 7:00 7:30 Time 8:00 8:30 9:00 9:30

Figure 12.3: Delay Contour Plot. are really obvious and a few where they aren't. After you have printed this contour plot out you should attempt to to draw reasonable space-time boxes around each incident. For example, for

190

CHAPTER 12. EXAMPLES WITH THE RUNFILE

incident number 117 it is pretty obvious that the whole region around the incident box should be included. On the other hand, you'll need to de ne the boundary between incidents 104 and 108 pretty carefully. Code these boxes into an ascii text le with the following 5 columns: incident number, the amount of time, in minutes, that you should extend the box to the left, the number of loop detectors that you should go upstream, the amount of time, in minutes again, that you should extend the box to the right, and nally the number of loop detectors that you should go downstream. So the order of changes that you are describing is left, down, right, up. The number of detectors that you should go upstream includes the current detector. So a value of 1 means that you should only look at this detector, a value of 2 means that you should look at the current detector and the one just upstream, and so on. In some cases where incidents overlapped and there was a small incident that was right in the middle of the delay from another big incident we decided that the delay should be zero. In this case we said that the number of upstream detectors should be 0, which meant that it shouldn't include any detectors. Whether this is the correct thing to do when you have multiple incidents is still up for debate. If you take a look at incident number 112 on Figure 12.3 you can see that this is exactly what happened. In our coding scheme we will make the delay for this incident zero. The incident space-time boxes that I generated for this contour plot are given below:
# Incident 104 105 107 108 110 112 116 117 Left 20 0 10 20 0 0 0 10 Down 4 1 3 11 1 0 1 7 Right 10 0 0 60 0 0 0 20 Up 0 0 0 0 0 0 0 1

Any line that begins with a \#" sign is a comment line. I put the rst line in the le to remind myself what all of the numbers mean. If you look at incident number 104 you'll see that we thought that the bounding box should stretch 20 minutes to the left of the reported incident start time, it should stretch 4 loop detectors upstream, and 10 minutes to the right of the incident end time. For incident number 105 you can see from the coding scheme that we didn't change the times at all and that we speci ed a bounding box that only included the current loop detector. The reason that we did this is because we looked at the contour delay plots and we noticed that there wasn't any appreciable delay. So as a default we simply speci ed that the program should only look at the current detector. Note that there has to be spaces between the numbers. Not commas, not hyphens, but spaces. Finally, this le should be placed in the incident data directory and it should be named fix_inc_delay.dat. Note that the le name is speci c and if the program doesn't nd this le then it will halt. You should also make sure that the program has permission to read this le.

12.11. EXAMPLE 10: CALCULATING THE INCIDENT DELAY WITH SPACE-TIME BOXES191

12.11.2 Step 2: Incident Delays From The Bounding Boxes

Now that the incident delay box le is in the proper place we can run the fsp program and tell it to calculate the incident delays with the bounding boxes. Of course, the key run le parameter to change is:
FIX_INC_DELAY_BOX = YES_FIX_INC_DELAY

A section of the output from this run should look like this:
Individual incident statistics: Inc. Type Inc # Date D 1 2 3 Time South 104 2/18/93 0 0 2 0 6:52 1 105 2/18/93 0 5 0 0 6:56 1 107 2/18/93 0 0 2 0 7:24 1 108 2/18/93 0 0 2 0 7:35 1 110 2/18/93 0 5 0 0 8:05 1 112 2/18/93 0 0 2 0 8:11 1 116 2/18/93 0 5 0 0 8:51 1 117 2/18/93 0 0 2 0 8:57 1 Link Loop 14 4 7 2 17 5 14 4 3 1 8 11 5 20 14 4 Good Bad Files Files 4 0 1 0 3 0 11 0 1 0 8 0 1 0 8 0 Duration 0:07:00 0:19:00 0:33:00 0:09:00 0:06:00 0:09:00 0:17:00 0:19:00 Delay 38.86 0.13 129.55 445.16 0.09 0.00 0.19 211.95

As you can see, the incidents where we de ned large bounding boxes have large delays and the incidents that had small bounding boxes don't. There are a few things to note about calculating the incident delays this way: If an incident is not listed in the delay box le then the incident will be discarded. Note that it is not counted as having zero delay, it is thrown away completely. This takes place after the incidents have passed through the incident lter. If you are using this method to calculate the delay then you should set the vehicle headway time to be zero. It doesn't make any sense to say that you should add some extra time to the incident durations when you are calculating the delays this way. If you use this feature then a few other features become obsolete. These are the incident duration x, and the incident location x. Since we are de ning the incident delay to be only the delay inside the bounding box the actually incident location and duration are irrelevant. You can leave them on if you want to but they won't e ect the delay calculation. It would be nice if the computer could draw these bounding boxes by simply looking at the delay contours. This would eliminate the time consuming and irritating step of having to draw the boxes by hand and then code them in. It seems that from the simple picture above that this would be possible. If you look at a typical delay or density contour plot you will quickly realize that this is almost impossible to do (at least by me).

192

CHAPTER 12. EXAMPLES WITH THE RUNFILE

Chapter 13

Program Output: How To View It

Since the Freeway Service Patrol data set contains so many di erent types of data it is useful to be able to view them graphically. The fsp program can be thought of as a big lter that is used to extract various pieces of data from the I-880 data set and to generate plots. The plots that this program generates are speci cally designed to be used with gnuplot version 3.5, but you can use xgraph to display most of the data.

13.1 GNUPLOT

The gnuplot program comes with the gnu software that is publicly available. If you don't have it you could download it from gatekeeper.dec.com via anonymous ftp. You could also just tell your system administrator that you need the gnuplot program and ask her to get it. Make sure that they get the gnuplot x11 program to display the stu on your screen. It shouldn't be that hard. The gnuplot program needs two les to run. One le is the data le in two columns, x vs. y. This is called the gnuplot data le. The other le is the gnuplot executable le. This is the le that holds all of the information for the plot, like what to use for the title, what range to use for the x and y axis, where to display the plot, etc. My program generates the data les and the executable les automatically. To display a particular set of data then just type: This will nd the data, make the graph and display it on the screen. In certain cases, the fsp program will also make gnuplot executable les that will direct the graph to a printer instead of to the screen. The advantages to using gnuplot is that you can make really nice plots. The labels can be perfect, the axis are exactly how you want them, etc. The bad part, is that if you don't have the gnuplot executable le then it's hard to get anything. If you want to make plots of anything other than what I planned then you probably shouldn't try to do it with gnuplot. The only hard part about using gnuplot is that you have to gure out what the gnuplot executable le is named for each type of plot. Since the fsp program generates many, many di erent types of plots this can sometimes be very confusing. The various gnuplot executable les that the program makes are discussed in Chapters 14, 15, and 16. To plot a particular set of data you just need to nd the gnuplot executable le that goes with it. 193
gnuplot gnuplot.executable.filename

194

CHAPTER 13. PROGRAM OUTPUT: HOW TO VIEW IT

13.2 XGRAPH: An Alternative

The program xgraph is a very quick and simple way to generate graphs. It can be used as an alternative to gnuplot. It only takes in one lename, which is the data in two columns, and then generates a graph. Once this graph is made you can then dump it to a printer. The problem with xgraph is that you can't really set the axis to be whatever you want, the labeling isn't that great, etc. But, if you just want to see the data really fast then this is probably the best way to do it. The really nice thing about xgraph is that in Unix you can use shell wildcard characters in specifying the data sets to graph. For example, if you wanted to graph the counts data from the northbound section of loop 3 for all of the lanes then you could type in:
xgraph xgraph xgraph xgraph xgraph floop3.nc1 floop3.nc2 floop3.nc3 floop3.nc4 floop3.nc5

Each one of these commands will read in the appropriate le and will create a plot on the screen. These le names correspond to the count data for the individual northbound lanes of loop 3. To learn more about the naming convention then see Section 15.3. Once the plots are on the screen there is a button that xgraph presents to you that allows you to print each one of these out and compare them. But, since you allowed to use wildcard characters in naming the les, instead of typing the ve commands listed out above you could type:
xgraph floop3.nc*

and the wildcard character \*" will expand to be all of these les. This is exactly the same as typing in:
xgraph floop3.nc1 floop3.nc2 floop3.nc3 floop3.nc4 floop3.nc5

Either of these last two commands will cause xgraph to display all of the data sets on one graph and then generate a key in the upper right hand corner. If you have a color monitor then each one of the lines will be a di erent color. If you don't have a color monitor then the lines will be various patterns of dots and dashes. This feature is very useful when attempting to compare di erent sets of data. The xgraph program should come with the release of X that is on your system. Talk to your system administrator about where it is on your system. Of course, both of these programs, gnuplot and xgraph, require that you have X running on your workstations in order to run them. If you don't then you won't be able to see the plots at all. You should note that the le that xgraph takes as an argument is the data le whereas the le that gnuplot takes is the special le made by the fsp program speci cally for gnuplot.

a 13.3 L TEX Tables

Most of the output that the fsp program generates is in the form of a plot or a textual table. In some cases it would be nice to have a better table than just an ASCII printout. In those cases

a 13.3. L TEX TABLES

195

a a the fsp program generates L TEX tables that have really nice formatting. L TEX is a typesetting language that allows the user to create nice postscript documents from text les by putting a special commands in the text le. When you have a le that was written with L TEX commands in it you can either view that le on the screen or print it out to a postscript printer. This a section will describe the commands that you need to type to view or print any L TEX les that the fsp program might generate. a There are two steps to processing a L TEX le: a 1. The le rst needs to be converted from a L TEX le to what is called a \dvi" le. A \dvi" le is a le that is device independent. This means that the commands in the le are not speci c to any output device. A complete description of why a device independent le is need would take us too far a eld. The important thing to note is that once you have the \dvi" le that you can display it on the screen with the program xdvi.

2. Once you have the \dvi" if you want to display it on the screen then you can use the command xdvi. If you want to print it out then you have to translate it to a postscript le. This is done with a program called dvi2ps. You can then pipe this le directly to a printer.
a Let's do an example of converting a L TEX le to a postscript le. The le that we will start o with was generated by the fsp program and is named delay.55.tex. This le holds various tables of delay values for each time period. An explanation of these tables is given in Section 15.4.1. We start with the le delay.55.tex and we want to convert it to a \dvi" le so that we can rst view the le on the screen. This is done with the following command:
clair 1: latex delay.55.tex This is TeX, C Version 3.141 (delay.55.tex LaTeX Version 2.09 <14 January 1991> (/usr/local/tex/inputs/book.sty Document Style `book' <24 Nov 89>. (/usr/local/tex/inputs/bk11.sty)) (/usr/local/tex/inputs/amssymbols.sty) No file delay.55.aux. 1] (delay.55.aux) ) Output written on delay.55.dvi (1 page, 2956 bytes). Transcript written on delay.55.log.

a In the output above the L TEX program tells us that it has created a le named delay.55.dvi. This le can then be displayed at your local workstation by the command:
clair 2: xdvi delay.55.dvi

a Note that the le extension on all L TEX les that the fsp program generates is \tex" and that the le extension on all \dvi" les is \dvi." Once the \dvi" le has been generated it can be printed to your local printer by converting it to a postscript le and then dumping it to the printer. This can be done with the following command:

196

CHAPTER 13. PROGRAM OUTPUT: HOW TO VIEW IT

clair 3: dvips delay.55.dvi | lpr -Pyour_printer_name /usr/tools/lib/ps/tex.ps] 1]

Where \your printer name" is the name of your local printer. Note that on some machines, the program dvips will dump the postscript output directly to a printer. In this case, you don't need to pipe the output to a printer as well. If you don't want to print the table out to the printer right away then you can generate a postscript le named delay.55.ps from the \dvi" le with the following command:
clair 3: dvips delay.55.dvi > delay.55.ps /usr/tools/lib/ps/tex.ps] 1]

Once you have a postscript le you can print it out to the printer by simply typing:
clair 4: lpr -Pyour_printer_name delay.55.ps

Although it is not required, it is usually a good idea to make the extension of any postscript a les \ps." There are a few things that you should note about generating and printing L TEX les: All of these commands assume that the appropriate programs are in your path. These programs are all pretty common on workstation machines but you might have to contact your system administrator to gure out where the programs are kept. Whenever the fsp program generates a le of tables there is always one table per output period per direction per page. This means that if the output period is 1 minute and you run the program over the whole time period that there is going to be approximately 1400 a pages of output. Well, this will take a long time for L TEX to process and it will take forever to print out. It is recommend that you only process the tables when the time period of interest is very short or the output period is very long.

Chapter 14

Program Output: The Car Data

The rst type of data output that will be discussed is the car data. This chapter will talk about the various graphs and tables that the fsp program generates for the car data. Graphs that involve both the car data and the incident data, or the car data and the loop data are described in Chapter 16.

14.1 The Car Textual Output

With all of the di erent types of data there are two types of output that the fsp program generates. The rst type of output is text output. This includes error reports, summaries of the data, and estimates of the data validity. The second type of output is graphical. This includes various plots of the data that can be displayed on the screen or printed to a printer. This chapter will discuss the di erent types of car text les that are generated, their di erent formats, and where they are placed in the directory structure. A similar discussion for the car plots will take place a little later on in Section 14.2. The rst type of car textual output that I will discuss are the error reports. The generation of the car error reports is governed by the run le parameter REPORT_OPTION. For more information on the run le parameters see Chapter 7. I will assume that this parameter has been set to EVERYTHING_NUM. This will generate four di erent car error reports: a key one, a huge one, a medium one, and a small one. All of these reports are placed under the car output directory in the directory de ned by the variable CARDATA_REPORTS_DIR, which is de ned in the include le fsp.h. This variable is current de ned to be \Reports." The various les are named with the following scheme: fkey,huge,med,smgZZZZZ.err. This means that the rst few characters are either key, huge, med, or sm corresponding to the key, huge, medium, or small report respectively. The Z's correspond to the 3rd through 7th characters of the run le that was speci ed for this run. That might seem a little strange but you need to remember that the whole process is under computer control from the data disks to the nal reports and this ts into that scheme very nicely. For an overview of the entire data processing ow see Chapter 17. For example, if the run le was called rf09230.run, then the car error reports would be called:
key09230.err huge09230.err med09230.err

197

198
sm09230.err

CHAPTER 14. PROGRAM OUTPUT: THE CAR DATA

The key error report displays statistics about the keys that the drivers press while driving during their shift. This le is only generated when the data set is speci ed as the second data set. In Section 4.3 there was a discussion about how we decided that we needed more detailed information from the cars. In that section I described how to tell what kind of car data you are dealing with. You should refer to that section if you don't know what the two types of car data sets are. To understand what the various keys are you should refer to Figure 4.4. The key error le lists out quite a few things: 1. The starting time of each run (or loop). 2. The number of times that the southbound start and end key was pressed per run. 3. The travel time between the two southbound keys per run. 4. The number of times that the northbound start and end key was pressed per run. 5. The travel time between the two northbound keys per run. 6. The number of times the southbound gore key was pressed per run. 7. The travel time between the two southbound gore keys per run. 8. The number of times the northbound gore key was pressed per run. 9. The travel time between the two northbound gore keys per run. 10. A summary of the number of times that the drivers hit the keys correctly for each type of key. 11. The drivers name and the fraction of correctly pressed keys for the whole day. A short sample of a key error report is given below:
******* Car Data Report: Number of Data Sets: 1 3- 9-93 Car 1 PM TT #North Gore 2 2 1 0 2 3/5 TT 0:11:13 0:02:47 *******

14.1.1 The Key Error Report

Loop#

#South #North #South Start Points TT Points TT Gore 15:20:21 1 15:51:04 2 0:14:54 2 0:14:27 2 2 16:23:25 2 0:22:15 2 0:15:05 2 3 16:54:15 2 0:13:15 2 0:16:08 2 4 17:27:41 2 0:12:41 1 0 5 17:59:09 2 0:09:30 1 2 5/5 3/5 4/5 driver = Hisham Noeimi score = 75%

0:09:56 0:05:04 0:07:59 0:07:35

0:07:21

14.1. THE CAR TEXTUAL OUTPUT

199

This is the key error report for car number 1 on the afternoon shift of March 9, 1993. The label \TT" stands for \Travel Time." The travel times are for the type of key press directly to the left of the column. For example, the fth column of data, which is the rst column that says \TT", lists the travel times for the southbound points. Since we need to have two key presses of a certain type in order to get a travel time if there aren't two key presses then a travel time is not calculated and there is just a blank. If you look at the travel time for the northbound points then you'll see that in the 4th and 5th loop the driver only pressed the northbound key once. This means that they forgot to press it at the start of the run or at the end of the run. Since we don't have two points, we can't calculate a travel time for these cases. The summary at the bottom is just the total number of times that the driver correctly hit two key presses of a certain type in a single run. The score is the percentage of times that they hit all of the di erent types of keys correctly. It seems that this driver, Hisham Noeimi, did very well for the rst two runs and then got lazy later on in the day.

14.1.2 The Huge Car Error Report

The huge car error report displays statistics on every run that every car makes. It lists the starting time, the run time, the total distance traveled, and even tries to give an estimate as to whether the run was good or not. It should be pointed out that this estimate might not be accurate. The best way to see if a particular run was good or not is to plot out the trajectory as explained in Section 14.2. A short sample of a huge error report is given below:
******* Car Data Report: Number of Data Sets: 1 3-10-93 AM Car Loop# 1 1 2 3 4 5 6 3 1 2 3 4 5 6 *******

Start time 6:32:55 6:38:29 7:13:04 7:41:02 8:27:23 8:57:54 9:21:17 6:06:04 6:08:50 6:52:58 7:30:09 8:19:30 8:52:32 9:22:06

#Points 10820 2074 1679 2781 1831 1403 717 12449 2774 2245 2988 1982 1571 889

Run time 3:20:20 0:34:34 0:27:59 0:46:21 0:30:31 0:23:23 0:11:57 3:29:28 0:46:14 0:37:25 0:49:48 0:33:02 0:26:11 0:14:49

Distance 105.9 19.7 19.3 20.1 18.1 19.2 9.4 109.1 28.5 19.7 19.3 19.1 19.8 2.8

Suggestion Good run Good run Good run Bad distance Good run Bad distance

Bad distance Good run Good run Good run Good run Bad distance

This is the huge error report for cars number 1 and 3 for the morning shift of March the 10th. The rst line of each car lists out the total run time and the total distance traveled for the whole shift. Each line with a loop# lists out the run time and the distance traveled only for

200

CHAPTER 14. PROGRAM OUTPUT: THE CAR DATA

that particular loop. If you look at car 3, loop 1, you will see that the distance traveled for that loop was 28.5 miles. Since the whole course is only around 19 miles it is a pretty safe bet that there was something wrong with that particular loop. A closer study is de nitely warranted. The suggestion that is given in the last column is merely an attempt to determine if the data is correct. Don't take this suggest as the nal word on whether or not a particular loop is valid.

14.1.3 The Medium Car Error Report

The medium car error report only lists out the drivers name, the number of loops that they made during the shift, the total distance driven during the shift, and an estimate as to whether the GPS data was any good. To estimate whether the GPS data is any good the program just tries to see if the GPS data falls within some bounding box. If it does then it is labeled as good, and if it doesn't then it is labeled as bad. Clearly a better test could be devised. A sample of a medium error report is listed out below:
******* Car Data Report: Number of Data Sets: 1 3-10-93 Car # 1 3 AM Driver name Jun Huang Adnan Qadeer *******

#Loops 6 6

Start time 6:32:55 6:06:04

Tot distance 105.9 109.1

GPS sug Good data. Too noisy.

This medium error report is for cars 1 and 3 for the morning shift on March the 10th.

14.1.4 The Small Car Error Report

The small car error report just records if there was data taken at all for the car on the speci c day. A sample is listed out below:
Quick Data Summary: car1 3-10-93 AM X car2 car3 X car4 car5

Note that this doesn't give very much information, but if you just want to know if you got the correct data then it could be helpful.

14.2 The Car Graphical Output

There are quite a few plots that are made from the car data. There are plots that are made for each run, or loop, of each car and then there are plots that are made for all of the cars for a particular shift. I will discuss the two di erent types of plots separately.

14.2. THE CAR GRAPHICAL OUTPUT

201

14.2.1 The Graphs For Each Loop

When the car data is collected in the eld there is only one le, called nav.dat, that contains the location data for all of the runs that car made for the entire shift. The rst thing that the fsp program does is to parse up this large le into the various runs that the car made. It then takes these single run les and generates various types of plots. The various types of plots generated for each run of each car are listed out below: 1. x-y plots 2. time-distance plots 3. speed-distance plots 4. speed-time plots When the program generates the individual run les by parses the main nav.dat le it names them according to the following scheme: \cXloopY.*" Where \X" is the car number, \Y" is the loop, or run, number, and \*" is the le type extension. The le pre x \cXloopY" will be referred to as the base le name. For example, if we were talking about the second loop that car 1 took then the base le name would be \c1loop2" and the base le name for the third loop of car 5 is \c5loop3." These les are all stored in the individual car directories. For example, the input car directory structure will look something like this:
am110492 | |-- car1 |- fsp.dat |- nav.dat |- key.dat |- gps.dat | |-- car2 | |-- car3 . . <= This is the main car directory <= Sub car dir 1

<= Sub car dir 2 <= Sub car dir 3

After processing the output car directory would look like this:
am110492 <= This is the main car directory | |-- car1 <= Sub car dir 1 |- c1loop1.cxy <= New file |- c1loop2.cxy <= New file |- c1loop3.cxy <= New file

202

CHAPTER 14. PROGRAM OUTPUT: THE CAR DATA

For each type of graph there are ve di erent les. There is the car trajectory, the incident locations, the INRAD locations, the gnuplot executable to view the plot on the screen, and the gnuplot executable to print the plot to the printer. Before I discuss the various le types I would like to explain how the le extensions are created. The base le name, as discussed above, is always going to be of the form \cXloopY." Well, the le extension is three letters long and it is of the form \WZZ." Where \W" signi es the data type and \ZZ" signi es the plot type. The various possible values are listed out below. 1. Data types: (a) Car trajectory: \c" (b) Incident locations: \i" (c) INRAD locations: \r" (d) Gnuplot executable to view plot: \v" (e) Gnuplot executable to print plot: \p" 2. Plot types: (a) X-Y plot: \xy" (b) Time-distance plot: \td" (c) Speed-distance plot: \sd" (d) Speed-time plot: \st" For example, the le that holds the car trajectory on the speed vs. distance plot would have an extension of \csd." Or the gnuplot plot executable le that would generate a graph on the screen of the time vs. distance plot would have a le extension of \vtd." If we combine this with what we learned above about the base le names then we can form the whole le name. So the le that holds the incident locations for the speed vs. time plot for the second run of the the third car is named \c3loop2.ist." Figure 14.1 is a quick reference to help you gure out the le extensions based on the plot type and the data type. The two holes that occur in the INRAD row are there because

14.2. THE CAR GRAPHICAL OUTPUT

Plot type Data type X-Y Time-Dist Speed-Dist Speed-Time

203

Car Traj. Incident Inrad Gnu view Gnu print

.cxy .ixy .rxy .vxy .pxy

.ctd .itd .rtd

.csd .isd

.cst
INCIDENT POINTS

.ist

INRAD POINTS

.vtd .ptd

.vsd .psd

.vst .pst

TIME DISTANCE PLOTS X-Y PLOTS

SPEED TIME PLOTS

SPEED DISTANCE PLOTS

Figure 14.1: Car File Name Extensions. the INRAD points aren't plotted on the speed vs. distance or speed vs. time graphs, so the les aren't generated by the fsp program. An explanation of the various graph types and the les that go with them follows.

X-Y plots: These plots are the plots of the car trajectory on an X-Y graph. They also have
the INRAD points and the incidents marked on the graph. File type Car trajectory on X-Y plot INRAD points on X-Y plot Incidents on X-Y plot gnuplot le to view plot gnuplot le to print plot File to view all X-Y plots for car File to print all X-Y plots for car .cxy .rxy .ixy .vxy .pxy viewxy printxy Extension/File name

An example of this naming scheme for car 1, loop 1 would be:

204
c1loop1.cxy c1loop1.rxy c1loop1.ixy c1loop1.vxy c1loop1.pxy viewxy printxy <= <= <= <= <= <= <=

CHAPTER 14. PROGRAM OUTPUT: THE CAR DATA

Data file: car position on X-Y plot Data file: INRAD points on X-Y plot Data file: Incidents on X-Y plot gnuplot file: Executable to view plot gnuplot file: Executable to print plot Script file: View all of the X-Y plots Script file: Print all of the X-Y plots

Time-distance plots: These plots are the plots of the car trajectory on a time vs. distance
File type Car trajectory on T-D plot INRAD points on T-D plot Incidents on T-D plot gnuplot le to view plot gnuplot le to print plot File to view all T-D plots for car File to print all T-D plots for car Extension/File name .ctd .rtd .itd .vtd .ptd viewdt printdt

graph. They also have the INRAD points and the incidents marked on the graph. I have used the abbreviation T-D for time vs. distance below.

An example of this naming scheme for car 1, loop 1 would be:

c1loop1.ctd c1loop1.rtd c1loop1.itd c1loop1.vtd c1loop1.ptd viewtd printtd <= <= <= <= <= <= <= Data file: car position on T-D plot Data file: INRAD points on T-D plot Data file: Incidents on T-D plot gnuplot file: Executable to view plot gnuplot file: Executable to print plot Script file: View all of the T-D plots Script file: Print all of the T-D plots

Speed-distance plots: These plots are the plots of the car trajectory on a speed vs. distance
graph. They also have the incidents marked on the graph. I have used the abbreviation S-D for speed vs. distance below. File type Car trajectory on S-D plot Incidents on S-D plot gnuplot le to view plot gnuplot le to print plot File to view all S-D plots for car File to print all S-D plots for car Extension/File name .csd .isd .vsd .psd viewsd printsd

14.2. THE CAR GRAPHICAL OUTPUT

An example of this naming scheme for car 1, loop 1 would be:
c1loop1.csd c1loop1.isd c1loop1.vsd c1loop1.psd viewsd printsd <= <= <= <= <= <= Data file: car position on S-D plot Data file: Incidents on S-D plot gnuplot file: Executable to view plot gnuplot file: Executable to print plot Script file: View all of the S-D plots Script file: Print all of the S-D plots

205

Speed-time plots: These plots are the plots of the car trajectory on an speed vs. time graph.
They also have the INRAD points and the incidents marked on the graph. I have used the abbreviation S-T for speed vs. time below. File type Car trajectory on S-T plot Incidents on S-T plot gnuplot le to view plot gnuplot le to print plot File to view all S-T plots for car File to print all S-T plots for car Extension/File name .cst .ist .vst .pst viewst printst

An example of this naming scheme for car 1, loop 1 would be:

c1loop1.cst c1loop1.ist c1loop1.vst c1loop1.pst viewst printst <= <= <= <= <= <= Data file: car position on S-T plot Data file: Incidents on S-T plot gnuplot file: Executable to view plot gnuplot file: Executable to print plot Script file: View all of the S-T plots Script file: Print all of the S-T plots

The les that start with \print" or \view" are script les that allow the user to view or print all of a certain le type right in a row. For example, if the user were to type \printxy" then that would print the x-y plots for all of the loops for that car to the printer without prompting for a return before each le. If there were ve loops then this would be the same as typing:
gnuplot gnuplot gnuplot gnuplot gnuplot c1loop1.pxy c1loop2.pxy c1loop3.pxy c1loop4.pxy c1loop5.pxy

206

CHAPTER 14. PROGRAM OUTPUT: THE CAR DATA

If you look at the le \printxy", you'll see that that's exactly what it does. The \viewxy" le would allow you to view all of the x-y plots right in a row but it will prompt you between each one for a carriage return. You will notice that there are basically two types of les in each category: the data les and the gnuplot executable les. You should note that you can always print the data les with something like xgraph instead of using gnuplot. Of course, you won't get the fancy labeling, but you can generate plots very quickly this way. Examples of all of the car plots are given in Section 14.3.

14.2.2 The Graphs For Each Shift

The second category of car plots that the fsp program generates deal with the travel times as the cars travel northbound and southbound. The program will generate four di erent types of plots: 1. Travel times from INRAD points 2. Travel times from northbound gore points 3. Travel times from southbound gore points 4. Travel times from southbound INRAD and southbound gore points These plots are for all of the cars for a speci c shift. These les are all stored in the main car output directory. For example, the nal directory structure after the fsp program was run would look something like this:
am110492 | |-| |-| |-| |-| |-|-|-<= This is the main car directory car1 car2 car3 car4 inrad.dat inrad.gtp inrad.gtv . . . <= Sub car dir 1 <= Sub car dir 2 <= Sub car dir 3 <= Sub car dir 4 <= New file <= New file <= New file

The actual starting and ending points that are used to calculate the travel times are either the gore points or the INRAD points. Unfortunately, there is only one INRAD point on the northbound run so we couldn't calculate any travel times for the northbound section based on the INRAD data. There aren't nearly as many travel time plots as there are individual car loop les and therefore the naming scheme is pretty straight forward. An explanation of the various le types follows.

14.3. THE CAR PLOTS

the southbound run. The total distance traveled is about 5.5 miles.
inrad.dat <= Data file: INRAD data points inrad.gtv <= gnuplot file: Executable to view plot inrad.gtp <= gnuplot file: Executable to print plot

207

Travel times: INRAD: These are the travel times as computed from the INRAD points for

Travel times: Northbound gore points: These are the travel times as computed from the
gore points for the northbound run. The total distance traveled is about 7.0 miles.
ngore.dat <= Data file: gore data points ngore.gtv <= gnuplot file: Executable to view plot ngore.gtp <= gnuplot file: Executable to print plot

Travel times: Southbound gore points: These are the travel times as computed from the
gore points for the southbound run. The total distance traveled is about 7.0 miles.
sgore.dat <= Data file: gore data points sgore.gtv <= gnuplot file: Executable to view plot sgore.gtp <= gnuplot file: Executable to print plot

Travel times: Southbound INRAD and gore points: These are the travel times as computed from the INRAD points and the gore points for the southbound run. This just uses the other data les to generate the plot - it doesn't need any of its own.
stimes.gtv <= gnuplot file: Executable to view plot stimes.gtp <= gnuplot file: Executable to print plot

14.3 The Car Plots

Figures 14.2 thru 14.9 are the various plots that can be made from the car data. The gnuplot executable le that was used to view each plot is listed in the caption.

208
1

CHAPTER 14. PROGRAM OUTPUT: THE CAR DATA

Car and incident data: /am021693/car1/c1loop2 Incidents INRAD points

-1

-2
Position (miles)

-3

-4

-5

-6

-7

-8 0 1 2 Position (miles) 3 4 5

Figure 14.2: Car Trajectory (X-Y). Gnuplot le: c1loop2.vxy

Car and incident data: /am021693/car1/c1loop2 7:40 Incidents INRAD points

7:35

Time

7:30

7:25

7:20

7:17 0 5 10 Position (miles) 15 20

Figure 14.3: Car Trajectory (time vs. distance). Gnuplot le: c1loop2.vtd

14.3. THE CAR PLOTS

Car and incident data: /am021693/car1/c1loop2 70 3 7 9 18 4 11 13 5 15 17 12 19 6 2 20 1 16 Incidents

209

50
Speed (mph)

10 16 0 0 1 20 2 6 5 19 12 17 5 15 4 13 18 11 10 7 3 8 20

10 15 Position (miles) (start time = 7:17:20)

Figure 14.4: Car Trajectory (speed vs. distance). Gnuplot le: c1loop2.vsd
Car and incident data: /am021693/car1/c1loop2 70 3 7 9 18 4 11 13 15 5 17 12 19 6 2 20 1 16 Incidents

50
Speed (mph)

10 16 0 | | 1 20 | 2 | 6 19 | 17 12 | | 7:25 5 | | | | | 7:30 Time 15 | | 4 | 13 11 7 18 10 3 | | 7:35 | | 8 | | | 7:40

| | 7:20

Figure 14.5: Car Trajectory (speed vs. time). Gnuplot le: c1loop2.vst

210
20:00

CHAPTER 14. PROGRAM OUTPUT: THE CAR DATA

INRAD travel times: am021693 INRAD (5.5) 18:00 16:00 14:00
Travel time (minutes)

12:00 10:00 8:00 6:00 4:00 2:00 0:00 6:00

6:20

6:40

7:00

7:20

7:40 8:00 8:20 Start of travel time

8:40

9:00

9:20

9:40

10:00

Figure 14.6: Travel Times With INRAD Points. Gnuplot le: inrad.gtv
Gore travel times (northbound): am021693 20:00 North Gore (6.9) 18:00 16:00 14:00
Travel time (minutes)

12:00 10:00 8:00 6:00 4:00 2:00 0:00 6:00

6:20

6:40

7:00

7:20

7:40 8:00 8:20 Start of travel time

8:40

9:00

9:20

9:40

10:00

Figure 14.7: Travel Times With nbd Gore Points. Gnuplot le: ngore.gtv

14.3. THE CAR PLOTS

Gore travel times (southbound): am021693 20:00 South Gore (7.0) 18:00 16:00 14:00
Travel time (minutes)

211

12:00 10:00 8:00 6:00 4:00 2:00 0:00 6:00

6:20

6:40

7:00

7:20

7:40 8:00 8:20 Start of travel time

8:40

9:00

9:20

9:40

10:00

Figure 14.8: Travel Times With sbd Gore Points. Gnuplot le: sgore.gtv
INRAD and southbound gore travel times: am021693 20:00 18:00 16:00 14:00
Travel time (minutes)

South Gore (7.0) INRAD (5.5)

12:00 10:00 8:00 6:00 4:00 2:00 0:00 6:00

6:20

6:40

7:00

7:20

7:40 8:00 8:20 Start of travel time

8:40

9:00

9:20

9:40

10:00

Figure 14.9: Travel Times With Gore And INRAD Points. Gnuplot le: stimes.gtv

212

CHAPTER 14. PROGRAM OUTPUT: THE CAR DATA

Chapter 15

Program Output: The Loop Data

Like the car data there are various types of output for the loop data. This chapter will discuss the textual and graphical output for just the loop data. The discussion of the output that results from the mixture of the loop data with either the car data or the incident database is deferred until Chapter 16.

15.1 The Loop Textual Output

There are three di erent kinds of text output from the loop data: 1. Text reports for the loop data set. 2. Error reports for the loop data set. 3. Dropout times for the loop data set. A more thorough discussion of the loop error reports is given in Chapter 10. Below is a brief description of each type of output le.

Text reports for the long data set: These les hold the actual text of the loop data for the

long data set. The format of the text records is described in Chapter 4. These les are named in the following scheme: loopZZ.txt, where \ZZ" is the loop number. So if you wanted to nd the text report for the long data set for loop number 2 then the le would be named loop2.txt. The le extension is de ned in the le fsp_ext.h as follows:
#define LOOP_TEXT_FILE_EXTENSION "txt"

This can be changed to whatever you prefer. Whether these les are generated or not is determined by the run le parameter LOOP_LONG_TEXT. It needs to be set to either:
LOOP_LONG_TEXT_REPORT_ONLY or LOOP_LONG_BOTH_REPORTS

213

214

CHAPTER 15. PROGRAM OUTPUT: THE LOOP DATA

in order for these les to be made. See the discussion in Chapter 7 for a detailed description of the run le parameters. You should note that these les take up a lot of space and you should only generate them as a last resort. These les are stored under the loop output directory in the individual day directories.

Error reports for the long data set: These les hold the error reports from the loop data

for the long data set. The format of each line in the error report is described in Chapter 10. These les are named in the following scheme: loopZZ.err, where \ZZ" is the loop number. So if you wanted to nd the error report for the long data set for loop number 15 then the le would be named loop15.err. The le extension is de ned in the le fsp_ext.h as follows:
#define LOOP_ERROR_FILE_EXTENSION "err"

This can be changed to whatever you prefer. Whether these les are generated or not is determined by the run le parameter LOOP_LONG_TEXT. It needs to be set to either:
LOOP_LONG_ERR_REPORT_ONLY or LOOP_LONG_BOTH_REPORTS

in order for these les to be made. See the discussion in Chapter 7 for a detailed description of the run le parameters. These les are stored under the loop output directory in the individual day directories.

Dropout times for the long data set: This le holds the list of times that the cabinets were
not taking data. Sometimes the cabinets skip an output period or two and sometimes they stop working for hours at a time. What this le holds is a list of the times that there is no data at all from the cabinets. A short segment of one of these les is given below:
Summary of Loop Data Dropout Times: The requested data times are: 5:00 - 10:00, 14:00 - 20:00 /home/clair0/PATH/FSP/Set1/Loopdata/lp031893/loop1: /home/clair0/PATH/FSP/Set1/Loopdata/lp031893/loop2: 15:47 - 15:49 17:19 - 17:21 17:30 - 17:32 /home/clair0/PATH/FSP/Set1/Loopdata/lp031893/loop3: /home/clair0/PATH/FSP/Set1/Loopdata/lp031893/loop4: /home/clair0/PATH/FSP/Set1/Loopdata/lp031893/loop5: /home/clair0/PATH/FSP/Set1/Loopdata/lp031893/loop6: 8:29 - 9:45 /home/clair0/PATH/FSP/Set1/Loopdata/lp031893/loop7: 8:56 - 8:58

15.1. THE LOOP TEXTUAL OUTPUT

/home/clair0/PATH/FSP/Set1/Loopdata/lp031893/loop8: /home/clair0/PATH/FSP/Set1/Loopdata/lp031893/loop9: /home/clair0/PATH/FSP/Set1/Loopdata/lp031893/loop10:

215

The le lists at the top the times that the le covers. In this case the times are from 5:00am until 10:00am and then from 2:00pm until 8:00pm - the whole data set. The program places on each line the lename for each cabinet and then places on the lines below it the times that that cabinet didn't have any data. So cabinet #1 is the rst one and there are no lines below it with times. This means that there weren't any times when cabinet #1 didn't have data. But if we look at cabinet #2, it seems that it didn't have data for three di erent time periods. Something very important to note is that the data is checked only for every output period. So if the output period is set for 15 minutes then there might be a 10 minute segment in the middle of the period where the cabinet isn't taking data and this program wouldn't spot it. To avoid this you should make the output period as ne as possible. The trade o , of course, is speed: the smaller the output period the longer the running time. The output period is set by the run le parameter LOOP_LONG_OUTPUT_PERIOD. Refer to the discussion in Chapter 7 for more details. The dropout times le for the long data set is named long.bad.times. The lename is de ned in the le fsp_ext.h as follows:
#define LONG_DROPOUT_TIMES_FILENAME "long.bad.times"

This can be changed to whatever you prefer. Whether these les are generated or not is determined by the run le parameter DROPOUT_TIMES. It needs to be set to either:
LONG_DROPOUT_FILE or BOTH_DROPOUT_FILES

in order for this le to be made. See the discussion in Chapter 7 for a detailed description of the run le parameters. This le is stored under the loop output directory in the individual day directories.

Text reports for the short data set: These les hold the actual text of the loop data for
the short data set. They are identical to the les that hold the text for the long data set except that they hold the data for the short set and the le extension is di erent. These les are named: loopZZ.stxt. The le extension is de ned in the le fsp_ext.h as follows:
#define LOOP_SUM_TEXT_FILE_EXTENSION "stxt"

This can be changed to whatever you prefer. Whether these les are generated or not is determined by the run le parameter LOOP_TEXT. It needs to be set to either:

216

CHAPTER 15. PROGRAM OUTPUT: THE LOOP DATA

LOOP_TEXT_REPORT_ONLY or LOOP_BOTH_REPORTS

Error reports for the short data set: These les hold the error reports from the loop data

for the short data set. These les are almost the same as the long error report les. The di erence is that these les hold all of the error reports for all of the loops from a single day and the data dropout report for that day as well. All of these reports are just stored one after the other with the data dropout report, if it is generated, being last. These les are named in the following scheme: XXXXXX.sum. Where \XXXXXX" is the name of the loop directory. So the error reports for the short data set are stored in terms of days instead of in terms of cabinets. If you wanted to nd the error report for the short data set for March 10th then the le would be named, according to the naming scheme that I have on my machine, lp031093.err. The le extension is de ned in the le fsp_ext.h as follows:
#define LOOP_SUMMARY_FILE_EXTENSION "sum"

This can be changed to whatever you prefer. Whether these les are generated or not is determined by the run le parameter LOOP_TEXT. It needs to be set to either:
LOOP_ERR_REPORT_ONLY or LOOP_BOTH_REPORTS

in order for these les to be made. The data dropout report will only be placed at the end of the le if the run le variable DROPOUT_TIMES is set appropriately. See the discussion in Chapter 7 for a detailed description of the run le parameters. These les are stored in the loop output reports directory de ned by the variable LOOPDATA_SUMMARY_DIR in the le fsp.h. This is currently de ned to be Reports. Dropout times for the short data set: This le holds the times when the data is not available from the di erent cabinets. This is basically the same as the long dropout report except that it just covers the short data set. The dropout times for the short data set are placed at the end of the short error report and in the le named short.bad.times. This lename is de ned in the le fsp_ext.h as follows:
#define DROPOUT_TIMES_FILENAME "bad.times"

This can be changed to whatever you prefer. Whether these les are generated or not is determined by the run le parameter DROPOUT_TIMES. It needs to be set to:

15.2. THE LOOP TEXT REPORTS SUMMARY

YES_DROPOUT_FILE

217

in order for this le to be made. See the discussion in Chapter 7 for a detailed description of the run le parameters.

15.2 The Loop Text Reports Summary

Table 15.1 is a short summary of the key points about each type of output text le. File Type Run le Parameter Default Extension Output Place Loop Text LOOP_TEXT .stxt Loop directory Loop Error LOOP_TEXT .sum LOOPDATA_SUMMARY_DIR Loop Dropout DROPOUT_TIMES bad.times Loop directory, and error le Table 15.1: Summary of loop output text les.

15.3 The Basic Data Set

The loop data les that are generated from the raw loop data can be divided into two categories: the basic data set and the calculated data set. The basic data set contains values that were already in the raw data, and the calculated data set contains values that were calculated from the basic data set. Unfortunately, it can get a little more complicated than that. By manipulating the run le properly you can apply di erent xes to the loop data and each loop x generates a di erent set of lenames. These complications will be discussed at the appropriate places below. The basic data set consists of the ows, speeds, and occupancies for each individual loop detector. This data is extracted into an individual le for each value and for each lane at every loop detector. The le has two columns: the rst column is the number of seconds since midnight and the second column is the value for that time period. There are also gnuplot executable les that are made to display or print each value. The basic data lename looks something like this:
{f,g,h}loopXX.{n,s}{s,c,o}Y

This is basically a mess when you rst look at it. The notation ff,g,hg means that there is either an \f," \g," or an \h" at that one spot. So the rst character of the le can either be an \f," \g," or an\h." Let me explain what all of these symbols mean: ff,g,hg The rst character of the le can be one of these three characters. These characters correspond to the various xes that can be applied to the loop data. The les with the \f" character mean that there has been no x applied, the \g" means that the holes in the loop data were xed, and the \h" means that the holes were xed and the consistency errors were corrected. A complete discussion of the various xes is given in Section 5.2. Which set of data gets generated is of course determined by the parameters in the run le. In the rest of the discussion here I will assume that we are dealing with the \gloop" les because some of the calculations can only be done on the \gloop" les.

218

CHAPTER 15. PROGRAM OUTPUT: THE LOOP DATA

XX The \XX" mean the loop detector number. So the le name pre x \gloop7" corresponds

to the loop data from loop 7 that has had the holes corrected. fn,sg This corresponds to either the northbound or southbound detectors. For most loop stations there are southbound as well as northbound detectors. This character distinguishes between the two. fs,c,og This corresponds to the type of data that the le holds. The character \s" means speed, \c" means counts, or ows, and \o" means occupancies. So the le pre x \ oop3.sc" means the ow data from the southbound direction of loop #3 that hasn't had any xes done to it. Y This last character can either be a number or the character \d." A number will correspond to either a speci c lane or an on or o ramp. The character \d" means that the le is for the average over all lanes. Let's take a look at a speci c example. Let's say that we want the speed data from loop 4, northbound, lane 2. This means that XX, the loop number, will be 4, and Y, the lane number, will be 2. Finally since this is northbound speed data we have our nal lename of:
floop4.ns2

I don't mean to mislead you to thinking that the individual lane les are easy to identify - they aren't. But the complications are discussed a little bit later on. The fsp program also makes gnuplot executable les to facilitate viewing the various loop data values. The gnuplot executable lenames have a speci c pattern to them so that you can recognize them. It is:
{f,g,h}loopXX.g{s,c,o}{v,p}

You'll notice that this looks a lot like the loop data les. It was done that way on purpose. The rst thing that is di erent with the lename is that you now no longer specify whether you want the northbound or southbound. Instead you put a \g" in that spot. This is because each gnuplot executable makes plots of both the northbound and southbound values. The second thing that is di erent is that the last character no longer speci es the lane. Instead it speci es whether the gnuplot le will generate a plot to view or a plot to print. For example, if you wanted to view the occupancy data for the average over all of the lanes at loop 7, which is stored in the data les named floop7.nod and floop7.sod (assuming that you wanted the un xed data), then you would need to use the gnuplot executable le named floop7.gov. To actually view the le you would type:
gnuplot floop7.gov

To print this le out to the printer you would just use the extension \gop" instead of \gov". Note that the gnuplot executable les can only generate plots of the average data, not of the individual lanes. Examples of all of the loop plots are given in Section 15.5. Remember that the printer where the output goes is speci ed by the run le variable GNU_PRINTER. So if you have

15.3. THE BASIC DATA SET

219

a favorite printer then you need to change this parameter in the run le before you run the fsp program. If you have already generated the les and you want to choose a di erent printer without rerunning the program then simply edit the gnuplot executable le and substitute your new printer name for the old one. Below is a listing of all of the loop plot le type extensions. The le pre x, when there is one, is enclosed in parentheses. PPS Individual lanes (gloopXX) Summary (gloopXX) GNU view 1 (gloopXX) GNU print 1 (gloopXX) GNU view all of 1 (gnuview) GNU print all of 1 (gnuprint) GNU view everything GNU print everything .fn,sgcY .fn,sgcd .gcv .gcp .pps .pps gnuview.all gnuprint.all SPD .fn,sgsY .fn,sgsd .gsv .gsp .spd .spd OCC .fn,sgoY .fn,sgod .gov .gop .occ .occ

To view a whole bunch of les right in a row then you would use the shell script gnuview.*, or gnuview.all. For example, if you wanted to view all of the PPS data right in a row without having to type in all of the individual commands you would type
gnuview.pps

Let's look at some examples of this naming scheme. Below is a listing of a certain portion of the output:
clair 1: ls floop6.* floop6.gcp floop6.gov floop6.gcv floop6.gsp floop6.gop floop6.gsv floop6.ncd floop6.nod floop6.nsd floop6.scd floop6.sod floop6.ssd

These are the output les that are generated from the data le loop6.dat when the following parameters are speci ed in the run le:
LOOP_FLOW_PLOTS = LOOP_TEXT = YES_CALC_ALL_FLOW_PLOTS LOOP_NO_REPORTS

220

CHAPTER 15. PROGRAM OUTPUT: THE LOOP DATA

Note that there are other parameters that you have to specify but these are the main ones. The question that I am trying to answer is, \What are all of these les?" Let's rst look at just one le: floop6.ncd. As we said above the \f" in front of the word \loop" means that it's the un xed loop data. The \6" means that it's for loop #6. And the extension, \ncd", means North Counts Data. The rest of the les follow the same naming convention:
floop6.ncd floop6.nod floop6.nsd floop6.scd floop6.sod floop6.ssd <<<<<<Northbound Northbound Northbound Southbound Southbound Southbound Counts Data Occupancy Data Speed Data Counts Data Occupancy Data Speed Data

The gnuplot executable les follow a similar type of naming scheme:

floop6.gcp floop6.gcv floop6.gop floop6.gov floop6.gsp floop6.gsv <<<<<<Gnuplot Gnuplot Gnuplot Gnuplot Gnuplot Gnuplot Counts Print (to printer) Counts View Occupancy Print (to printer) Occupancy View Speed Print (to printer) Speed View

So the gnuplot executable le floop6.gcv would display the plots of the counts data on the screen. It will rst display the northbound plot and then it will prompt you for a return. When you have pressed return it then displays the southbound plot. If you had chosen the le floop6.gcp, meaning Gnuplot Counts Print, then the two graphs would be printed out to the printer and the program would not prompt you for a return. As was said above, if you wanted to view all of the PPS data les for the current directory then you can just use the le gnuview.pps. Note that the les that start with the key word \gnu", like gnuview and gnuprint, are not gnuplot executable les. They are shell script les that can be run from the command line by just typing their name. Finally, as promised, the last thing to discuss about the loop les is the individual lanes les and the individual ramp les. When the program generates the les for the main line lanes it rst goes through and pulls out all of the data for the individual lanes and places them in les. If the program is told to pull out the on ramp and o ramp data then it does this at the same time. Well, this generates a lot of les and as you can imagine, the naming problem becomes quite complex. Just to recap, for the individual lane les the basic lename is: VloopWW.XYZ. Where: V: this is either \f," \g," or \h" depending on what gets xed. WW: this is the loop number (or cabinet number). X: this is either \n" or \s" for the northbound data or the southbound data. Y: this is one of: c: means counts or pps.

15.3. THE BASIC DATA SET

s: means speed. o: means occupancy.

221

Z: this is the lane number or the on or o ramp number. This is a little tricky so let me explain a little bit more. The Z value is a value that starts at 1 with the rst le name, which corresponds to the inside most lane, and then counts up with each successive lename, and each lane. The way that the les are ordered, or saved, is: 1. main line lanes 2. on ramps 3. o ramps 4. ramp demand detectors 5. ramp queue detectors So the main line lane lenames get the lower numbers and the ramp queue detectors get the higher numbers. I don't want to lead you to believe that they get any arbitrary higher number - there is a set pattern. Let's look at an example. If we had 5 main lanes, 1 on ramp, 2 o ramps, 2 demand detectors, and 2 queue detectors then the labeling scheme would go like this:
floopWW.XY1 floopWW.XY2 floopWW.XY3 floopWW.XY4 floopWW.XY5 floopWW.XY6 floopWW.XY7 floopWW.XY8 floopWW.XY9 floopWW.XY10 floopWW.XY11 floopWW.XY12 lane lane lane lane lane 1 2 3 4 5 data data data data data

- on ramp 1 data - off ramp 1 data - off ramp 2 data - demand detector 1 data - demand detector 2 data - queue detector 1 data - queue detector 2 data

Notice how the \Z" parameter kept on increasing with each new le name. Let's look at a real example. If we wanted to take a look at cabinet #4 we would see that we have: Southbound: 4 main lanes, 1 o ramp

222

CHAPTER 15. PROGRAM OUTPUT: THE LOOP DATA

Northbound: 4 main lanes, 2 on ramps, 2 demand, and 2 queue detectors So the labeling scheme for the PPS data would be like this:
floop4.nc1 floop4.nc2 floop4.nc3 floop4.nc4 floop4.nc5 floop4.nc6 floop4.nc7 floop4.nc8 floop4.nc9 floop4.nc10 floop4.ncd floop4.sc1 floop4.sc2 floop4.sc3 floop4.sc4 floop4.sc5 floop4.scd northbound northbound northbound northbound lane lane lane lane 1 2 3 4 data data data data

- northbound on ramp 1 data - northbound on ramp 2 data - northbound demand detector 1 data - northbound demand detector 2 data - northbound queue detector 1 data - northbound queue detector 2 data - northbound main line data aggregate southbound southbound southbound southbound lane lane lane lane 1 2 3 4 data data data data

- southbound off ramp 1 data - southbound main line data aggregate

Notice how the \Z" parameter started back over from 1 when it switched to a di erent kind of le: it went back to 1 when it started generating the southbound les. Also, notice that if you don't know what the structure of the freeway is at a particular point then it is very hard to gure out from the lenames what is what. My point being that you have to know what the lane structure is before you can gure out what the lenames mean.

15.4 The Calculated Data Set

When I refer to the calculated data set I mean the data les that were calculated from the basic loop data. These les are used later on by the fsp program to calculate things like incident delay and to generate the contour plots. But since they are generated only from the loop data they are discussed here instead of in Chapter 16 where the rest of the cross data analysis output is discussed. There are two major types of calculated data, these are the delay les and the a emission les. With each type data the fsp generates some raw data les and some L TEX tables a that can be processed with L TEX and printed out on any postscript printer.

15.4. THE CALCULATED DATA SET

223

15.4.1 The Loop Delay And Density Files

The rst set of calculated les are the delay and density les. There are a couple of di erent types of delay les. There are les that hold the data for each time period, or instantaneous les, there are les that hold the cumulative delay over the whole study section, and then there are les that hold tables of delay values.

15.4.1.1 Instantaneous Loop Files

The program calculates the delay, density and di erential density for each time period for every loop detector. These values are then used later on to calculate the delay for each incident and to generate various contour plots. A short list of these les is given below: 1. The delay data les. These are the delay at each loop detector for each time period. 2. The density data les. These are the density of tra c at each loop detector for each time period. 3. The di erential density data les. These are percentage that the current density is over the average density for that loop detector for every time period. These les are referred to as data les because they hold only the raw calculated values and they have the standard fsp le format of two columns: the rst column being the time in seconds since midnight and the second column being the value for that time. The le naming conventions for these three di erent les are exactly the same as for the basic loop data except for one character. So the naming scheme is:
{f,g,h}loopXX.{n,s}{t,d,e}d

Where the \t" stands for the delay les, the \d" stands for the density les, and the \e" stands for the di erential density les. There are a couple of things that I should point out about these les: 1. The last character in the lename of these les is always \d" which means that the le is for the whole section of freeway, not for a single lane. These les are not generated for each individual lane. 2. These les were not meant to be viewed as individual les like the basic data set. Therefore, no gnuplot executable les are made to display them. 3. These les are used by a di erent section of the program to generate contour plots. The contour plots are described in Chapter 16.

15.4.1.2 The Cumulative Delay Files

Along with the instantaneous delay les the fsp program will also generate a cumulative delay le for the whole study section. The fsp program will calculate the total delay at each time period for the whole freeway by summing up the delay at each loop detector. It will then generate a le that has the cumulative delay over the whole time period. There is one le for each direction. The les are named according to the following format:

224

CHAPTER 15. PROGRAM OUTPUT: THE LOOP DATA

Figure 15.1: Cumulative Loop Delay.

delay.{n,s}tc.ZZ

Where the \ZZ" stands for the reference speed of the congestion. The les are stored with respect to the reference speed so that multiple runs of the fsp program can be run without overwriting the les. If the delay calculation is done with respect to the average speed then \ZZ" will be an \a." The cumulative speed le can be viewed with xgraph in the following manner:
xgraph delay.ntc.55

This will generate a plot on your screen that looks like Figure 15.1. The horizontal axis of Figure 15.1 is the number of seconds since midnight (5am is 18000 and 2pm is 50400). The vertical axis is the cumulative delay in vehicle-hours. Notice that there is a spot in the middle of the graph from 36000 until 50400 that is at. During this time there was no data collected and therefore there are no delay values. There is a line there because the xgraph program draws it's own line from point to point and it doesn't car if there is a gap in the data. If the time period of interest doesn't cover the dead zone then you won't have this a ect.

15.4.1.3 The Loop Delay Tables a The fsp program also generates a L TEX table of the delay values. Section 13.3 explains how
a to view and print any L TEX table. Figure 15.2 is an example of one page of a table that was

15.4. THE CALCULATED DATA SET

225

Figure 15.2: Loop Delay Table. generated by the fsp program. This table is for the time period from 5:01 am until 5:02 am in the northbound direction on February 16th, 1993. There is one table for each output period and each direction. The table in Figure 15.2 has at the top a few lines about the conditions under which the delay was calculated. We can see in this example that the delay was calculated with respect to a congestion speed of 55 mph. The table itself lists out the parameters and conditions at each loop detector and the calculated delay. You'll notice that the calculated delay for most of the loops is zero. This is because the congestion speed is 55 mph and most of the speeds on the freeway are higher than that. The number at the bottom that is labeled \TOTAL" is the sum of the delay over all of the loop detectors.

15.4.2 The Loop Emission Files

The second type of calculated data set are the emissions les. These les hold the emissions of carbon monoxide, hydrocarbons, and nitrogen compounds for the loop data. The nice thing about these les is that they are exactly like the loop les except for one character. The naming

226 scheme of these les is as follows:

CHAPTER 15. PROGRAM OUTPUT: THE LOOP DATA

{f,g,h}loopXX.{n,s}{g,h,n}Y

You can see that the le naming scheme is a lot like the regular loop les. The only di erence is the second character in the le extension. The \g," \h," and \n," stand for the carbon monoxide, hydrocarbon, and nitrogen emissions, respectively. Some things to note about the emissions output: The emissions generation routine is exactly like the loop delay generation routine. You can calculate the emissions with respect to the average speed or with respect to a constant speed.
a The fsp program will generate emission L TEX tables just like the loop data. These are named emissions.{co,voc,no}.tex. You need to process these the same way as the delay tables.

A cumulative emissions le is also made (just like the cumulative delay les). The le naming scheme is emissions.{co,voc,no}.{n,s}c.Z where the \Z" is the reference speed at which the calculation was done. The emissions les are all placed in the individual loop day output directories.

15.4.3 The Aggregate Loop Files

One useful thing that the fsp program does1 is it will calculate the total delay and the total number of vehicle-miles traveled for each individual loop directory. This is only done when the run le parameter LOOP_AGGREGATE_VALUES is set to YES_CALC_AGGREGATE_VALUES. When this happens the following table is generated for each day:
Aggregate Delay: Loop data: /home/pal2/FSP/Set1/Loopdata/lp021693 Southbound delay am, pm = 69.56, 851.71 Northbound delay am, pm = 229.35, 423.51 Aggregate Vehicle Miles: Loop data: /home/pal2/FSP/Set1/Loopdata/lp021693 Southbound veh-mi am, pm = 108856.43, 114284.34 Northbound veh-mi am, pm = 113834.71, 113697.62

This simply gives the the delay and vehicle-miles traveled for each direction and each shift. Note that the delay is in vehicle-hours and that the vehicle-miles traveled is in vehicle-miles (who would have though?). There are some things that I should point out about the aggregate tables:
1

Maybe the only useful thing.

15.5. THE LOOP PLOTS

227

The aggregate values are only summed up over a speci c time period. These time periods are from 6:30am until 9:30am, for the morning shift, and 3:30pm until 6:30pm, for the evening shift. These were the times that we had probe vehicles driving around on the freeway. The routine that does the aggregate calculation assumes that the proper loop les have already been calculated. If they haven't then all of the results will be zero. The aggregation routine can only be run on the loop les that have had the holes xed. The fsp program will not allow it to run on the un xed loop data. The aggregate tables are only printed out to the screen - there are never saved to a le. If you want to save them then you'll need to either cut and paste with the mouse or redirect the output of the fsp program to a le. After processing all of the loop data the aggregation routine will generate a table that sums up all of the values. A sample of one of these tables is given below:
Total Aggregate Delay: Southbound total delay am, pm = Northbound total delay am, pm = Overall total delay = Total Aggregate Flow: Southbound total veh-mi am, pm = Northbound total veh-mi am, pm = Overall total flow = 302.35, 562.49, 2865.70 1083.40 917.46

208387.78, 221243.72, 879031.02

224509.69 224889.83

Total Delay per 10^6 vehicle miles: Southbound total delay/10^6 veh-mi am, pm = Northbound total delay/10^6 veh-mi am, pm = Overall total delay/10^6 veh-mi =

1450.91, 2542.39, 3260.06

4825.62 4079.58

The total aggregate values are simply the summation of the various values for all of the days. The only thing that is new here is the delay per million vehicle-miles. We thought that this was an interesting statistic so we had the program calculate it. You can relate this to the delay caused by so many incidents per million vehicle-miles.

15.5 The Loop Plots

Table 15.2 is a print out of the six di erent plots from one loop. They could be generated by using the following commands:
gnuplot floop6.gcv gnuplot floop6.gsv gnuplot floop6.gov

228

CHAPTER 15. PROGRAM OUTPUT: THE LOOP DATA

Northbound flow (PPS) data (6 min samp): /lp031893/floop2 2000 2000 Southbound flow (PPS) data (6 min samp): /lp031893/floop2

1500
Flow (veh/lane/hour) Flow (veh/lane/hour)

1500

1000

500

0 14:00

15:00

16:00

17:00 Time

18:00

19:00

0 14:00

15:00

16:00

17:00 Time

18:00

19:00

Northbound speed (SPD) data (6 min samp): /lp031893/floop2 100 100

Southbound speed (SPD) data (6 min samp): /lp031893/floop2

Speed (mph)

0 14:00

15:00

16:00

17:00 Time

18:00

19:00

0 14:00

15:00

16:00

17:00 Time

18:00

19:00

Northbound occupancy (OCC) data (6 min samp): /lp031893/floop2 100 100

Southbound occupancy (OCC) data (6 min samp): /lp031893/floop2

Occupancy (%)

0 14:00

15:00

16:00

17:00 Time

18:00

19:00

0 14:00

15:00

16:00

17:00 Time

18:00

19:00

Table 15.2: Loop plots.

Chapter 16

Program Output: The Incident and Cross Data Analysis

Probably some of the most interesting output that the fsp program generates comes from the incident data. Since one of the main goals of the program was to be able to calculate the delay per incident there is a lot of emphasis on the incident output. As a matter of fact, the default setup for the program is to only print out incident statistics and to hide all of the loop and car data output. The fsp program generates quite a bit of output that deals with the incidents. It reports on the correlation between the incident database and probe vehicle trajectory data. It reports on the various xes that are applied to the incident data to make it more accurate. It reports on the delay calculations that are performed for each incident. It reports on quite a few things. But the point that I am trying to make is that most of the reports made on the incident involve one of the other data sources. As a result, it is hard to talk about the output that only deals with the incidents without mixing in something else. As a result, this chapter will discuss the incident output and the cross data analysis output.

16.1 Quick Overview Of The Incident And Analysis Output

When the fsp program processes the incidents it basically has two things that it can report on. These are the various xes that it has applied to the incident data, and the incident delay calculations. As was shown before, Figure 16.1 show us a simple conceptual picture of what the program does to x the incident data. Depending on what the user tells the program to do, it can attempt to x the incident data directory from the probe vehicle data or it can x the incident data from the already generated incident x les. Whichever option the user chooses the program will want to report on how it did attempting to x the incidents. For the delay calculations, the program would like to report not only on what the delays were for each incident, but also how it got those delay. So there is some text that is printed to the screen reminding them of the delay calculation conditions. The program will also generate some graphs of the analysis. A review of what this process looks like can be seen in Figure 16.2. In that gure you can see that there are a few di erent graphs that the program will generate: histograms, cumulative distributions, and incident delay versus incident duration. Finally, the contour plots are also generated in the incident processing section. The reason that 229

230CHAPTER 16. PROGRAM OUTPUT: THE INCIDENT AND CROSS DATA ANALYSIS
Incident Data Flow

Raw incident data

Car data

Runtime file

Fix incident placement

Runtime file Fix incident duration

Good incident data

Figure 16.1: Data Flow For Fixing The Incidents. this is done here instead of in the loop data processing section is because the contour plots have the incidents on them. In order for the program to know what the incidents are it rst needs to lter them out and process them.

16.2 Textual Output

The fsp program gives the user many options on how much text they would like to see with the incident and data analysis output. These options are set by the run le parameters INC_RAW_OUTPUT_LEVEL and INC_FINISHED_OUT_LEVEL. The various categories of output are listed out below: Working directories. Incident lter listing. Initial number of matched incidents. Basic characteristics of initial incidents. Complete characteristics of initial incidents. . Incident database - probe vehicle correlation results. Incident duration x results. ? Incident distribution over the various days. ? Delay calculation conditions.

16.2. TEXTUAL OUTPUT

Delay Calculation Flow

231

Good loop data

Good incident data

Process incidents

Delay bounding box

Delay per incident

Histograms

Delay vs. Duration

Cumulative distributions

Figure 16.2: Generating The Incident Delays.

? ? ? ?

Vital characteristics of nished incidents. Incident space-time boxes for delay calculation. Incident queue length analysis. Delay calculation results.

The item that is listed with a \ " is something that always shows up no matter how you set the options. This can be considered the base case output. The items that are listed with a \ " are generated depending on how the parameters are set for the raw incident output. The item with a \." beside it is generated by the correlation analysis. If you run the correlation analysis then this will be generated. The incident duration x results - the item with the beside it - are generated when you attempt to x the incident durations either from the probe data or from a premade le. Finally, the items listed out with a \?" are items that are generated depending on how the parameters are set for the nished incident output. In the subsections that follow we will discuss rst the base case output, then the raw incident output, then the incident database - probe vehicle correlation results, and nally the nished incident output options.

16.2.1 The Base Case Output

If you are processing the incident data then you aren't guaranteed to get any output at all. The run le parameters INC_RAW_MATCH_OUTPUT and INC_FINISHED_OUTPUT, which I will call

232CHAPTER 16. PROGRAM OUTPUT: THE INCIDENT AND CROSS DATA ANALYSIS the incident output control parameters, dictate if you will get any output. If these are both set to indicate that no output should be generated then the only thing that will come up on the screen is the following:
clair 1: fsp Runfiles/rf11111.run Incidents/my_inc.dat 0 Start of fsp Using the following data directories: Loopdata directory = /home/pal2/FSP/Set1/Loopdata Cardata directory = /home/pal2/FSP/Set1/Cardata Incident directory = /home/pal2/FSP/Set1/Incidents Data output directory = /home/pal2/FSP/Out5min Loop output directory = /home/pal2/FSP/Out5min/Loopdata Car output directory = /home/pal2/FSP/Out5min/Cardata Incident output directory = /home/pal2/FSP/Out5min/Incidents

******

END OF PROGRAM

******

This is not very interesting. This simply reminds the user what directories the fsp program is using to read in data and where it will place the output. For analyzing the incident data this is worthless. So it is imperative that you set the two incident output control parameters such that you actually get some output. The raw incident output is generated from the incidents that justed passed through the incident lter. No xes have been applied to them and their delays have not been calculated. This is sort of a rst check to make sure that everything is going ok. In order to get any output here at all the raw incident control parameter, INC_RAW_MATCH_OUTPUT, needs to be set to something other than NO_RAW_MATCH_OUTPUT. We will assume that it is set to SCREEN_RAW_MATCH_OUTPUT so that the output comes up on the screen. If this was set to FILE_RAW_MATCH_OUTPUT then the results would have been placed in the le named inc.matched.raw in the incident output directory. For a complete listing of the various options see Chapter 7. If the raw incident output level parameter, INC_RAW_MATCH_OUTPUT, is set to INC_RAW_OUT_SPARSE then the raw incident output section will look something like this:
Matching incident structure: Field Heading Values 0 DATA_TYPE F 2 DATE 2/16/93 Incidents matched: 46

16.2.2 The Raw Incident Output

2/17/93

This will list out all of the elds that the program is using to lter incidents with. In this case the incident lter is looking for eld data that occurred only on 2/16/93. Remember that in

16.2. TEXTUAL OUTPUT

233

the incident lter in order to specify one date you have to have the start date and the end date be one day apart (like they are above). It will also list out the number of incidents that made it through the lter. If INC_RAW_MATCH_OUTPUT is set to INC_RAW_OUT_MEDIUM then in addition to the listing above there will be a listing that contains a few basic characteristics of each incident. It will look something like this:
Stats on raw incident match: Incident # Date Time 1 2/16/93 6:49 2 2/16/93 6:54 3 2/16/93 7:00 South 1 1 1 Link # 3 3 8

You can see that this listing is only very basic. It only lists out the date, time, direction, and link number of the incident. Note that the column labeled \South" is simply the eld in the incident database that holds the direction. So a 1 in this column means that it's in the southbound direction and a 0 means that it's in the northbound direction. If INC_RAW_MATCH_OUTPUT is set to INC_RAW_OUT_VERBOSE then instead of the sparse listing above, the program will print out all of the elds of every incident. The start of this output looks something like this:
Field 0 1 2 3 4 Heading DATA_TYPE INC_NUMBER DATA_TYPE SHIFT TIME . . . Value F 1 2/16/93 0 6:49 Meaning Field data Incident number Date AM Shift Time

If you are ltering out more than a just a few incidents then this is probably so much output that it's not useful. Actually, there probably isn't much need to ever use anything more than the sparse output on the raw data - you can get everything else that you need from looking at the nished incident output.

16.2.3 Incident Database - Probe Vehicle Correlation Results

The incident database - probe vehicle correlation is done when the program is trying to gure out the correct locations for the incidents. The program reads in the probe vehicle data and records the locations of all of the key presses. It then reads in the incident database and attempts to match up the incidents with the key presses. When the program is nished with that process it generates some text to inform the user of the results and it generates some graphs so that the user can see how the correlation turned out. The graphs are discussed in Section 16.3.2 below. The correlation routine will generate two levels of text depending on the setting of the nished incident output level parameter INC_FINISHED_OUT_LEVEL. If this run le parameter

234CHAPTER 16. PROGRAM OUTPUT: THE INCIDENT AND CROSS DATA ANALYSIS is set to INC_FIN_OUT_SPARSE then the output from the correlation routine will look like the following:
Correlation Results: Incident database match statistics: Total: # incidents, # covered, ratio = 46, 46, 100.0% Total: # time entries, # matched, ratio = 151, 89, 58.9% Total: # covered incidents, # changed, avg change(ft) = 46, 29, Total: # with new loop, ratio = 8, 17.4% Probe vehicle match statistics: Total number of entries = 154 Number of entries in study section = 117 # matched entries in study section = 89 ratio = 76.1%

1160

The rst thing that you will note is that there are two types of statistics: the incident database match statistics and the probe vehicle match statistics. When the correlation routine tries to match the two data sets up it keeps statistics on how well each data set matched the other. These values might seem a little confusing at rst so a line by line explanation is given below. The rst set of statistics that I will explain deal with the incident database:
Total: # incidents, # covered, ratio = 46, 46, 100.0%

This is the number of incidents that made it through the incident lter. The number of covered incidents is the number of incidents that had some probe data that coincided with it that was speci ed in the run le. In this case, every incident had some probe data that covered the same time period. If, for example, in the incident lter you speci ed that you wanted to look for the incidents that occurred on February 19th, but in the run le you only speci ed the car data for March 3rd then these two data sets would not overlap. In that case, none of the incidents would have been covered.
Total: # time entries, # matched, ratio = 151, 89, 58.9%

For each incident in the incident database there is a listing of the number of times that the incident was witnessed by the probe vehicle drivers. The number of time entries here, is the summation, over all of the incidents, of the number of times each incident was witnessed. The number matched is the number of these entries that the computer matched with a speci c key press from the probe vehicles, and the ratio is just the percentage that were matched.
Total: # covered incidents, # changed, avg change(ft) = 46, 29, 1160

The number of covered incidents here is the same as in the rst line - it's just the number of incidents that had coinciding car data with them. The number changed is the number of incidents that had their location changed due to the correlation routine. The \avg change" is the average amount of change in feet for all of the incidents.

16.2. TEXTUAL OUTPUT

Total: # with new loop, ratio = 8, 17.4%

235

This is the number of incidents that were changed enough to have a new loop number assigned to them. If this number is zero then the correlation with the car data had no e ect. If this number is zero then it could be that the key presses all matched up exactly with where the drivers said that incidents occurred. Unfortunately, a more likely explanation is that all of the key presses were outside of the incident boxes. This second set of statistics deal with the probe vehicle data:
Total number of entries = 154

This is the total number of times that the drivers in the probe vehicles hit a key indicating that they were driving past an incident.
Number of entries in study section = 117

This is the number of entries that fell within the study area on the freeway. There was a section of the road that already had the Freeway Service Patrol tow trucks operating on it and so we took all of the incidents in this area out of the database. Therefore, we should exclude the key presses that show up in that area as well. This number should be the same as \# time entries" in the incident statistics above but it usually isn't.
# matched entries in study section = 89

This is the number of key presses that the computer thinks it can match up with driver recorded witness points in the incident database. This number is the same as \# matched" in the incident statistics above.
ratio = 76.1%

This is the ratio of the number matched to the number of entries in the study section (this is still only within the probe vehicle data). We usually use this as a measure of how good our t is. The closer this number is to 100% the better. If the nished output level parameter is set to INC_FIN_OUT_MEDIUM or INC_FIN_OUT_VERBOSE then the output from the correlation routine, in addition to the output described above, will include the following table:
SUMMARY of all COVERED incidents: Inc # # Entries # Matched Dist(ft) Loop 205 26 19 35640 12 210 3 2 21040 20 213 3 3 41360 17 216 2 0 39600 4 219 2 3 47770 5 New Dist(ft) New Loop 35764 13 20474 7 38824 17 39600 4 47619 5 Change 0.02 -0.11 -0.48 0.00 -0.03

236CHAPTER 16. PROGRAM OUTPUT: THE INCIDENT AND CROSS DATA ANALYSIS This table lists out for each incident the number of entries in the incident database, the number of those entries that got matched up with a key press in the probe vehicle data, the original location (in feet) of the incident1 , the original loop detector of the incident, the new incident location and loop detector, and nally, the change in miles between the old distance and the new. Note that although the distance may change this doesn't necessarily mean that there will be a new loop detector. Also note that the distance in feet is from the starting point of the probe vehicle run. Since the probe vehicle starts in the southbound direction rst, if an incident occurs on the northbound section then the distance to that incident is the distance from the starting point all the way to the turn-around point and then back up (north) to the incident. The nal thing to notice is that if there are more key presses in an incident box than there are entries in the incident database then the program will still allow those key presses to be matched to that incident. You can see that this happened for incident #219 above. Finally, if the nished output level parameter is set to INC_FIN_OUT_VERBOSE then the correlation routine will print out one additional table. This table is an incident location shift table than can be used as the new incident location x le. This table is only generated when the run le parameter FIX_INC_LOCATION is set to YES_FIX_INC_DELAY. A small sample of one of these tables is given below:
Possible new incident location fix table: Incident Shift (miles) 205 -0.48 210 -0.36 213 -0.48 216 0.00 . .

A complete example of how to use this table is given in Section 12.9. The basic idea is that by using these values in a new incident location x le you could possibly reduce the e ect of the correlation routine nothing. This is very handy if you don't want to have to process the car data and run the correlation routine each time that you want to get accurate incident locations. One thing that you will notice about the correlation statistics is that they should probably have been generated for each shift and not for the study period as a whole. While that may be true, we still needed an overall measure of how well the correlation routine was doing. As a result we opted for the large measure instead of a bunch of smaller measures.

16.2.4 The Incident Duration Fix Output

The incident duration x output is only generated when the fsp program is attempting to x the incident durations by looking at when the di erent probe vehicles drove by an incident and didn't witness it. It doesn't matter if the duration x is being derived from the probe data or from a runtime le, this table will alway be generated. The methodology behind this type of duration x is discussed in Section 5.3.2 and an example of how to do this with a run le is
1

This location is the location after the incident location x has been applied

16.2. TEXTUAL OUTPUT

237

given in Section 12.10. A sample of the table that the incident duration x routine generates is given below:
Incident duration correction statistics: Before New After Inc Start Start Start End End 205 23880 23794 23837 34140 34150 210 27180 26717 26948 28260 28829 213 30060 29686 29873 30780 31152 New End 34145 28544 30966 Final Duration 10308 1596 1093

Duration 10260 1080 720

Besides the incident number, which is in the rst column, all of the values in this table are in seconds. The second column, which is labeled \Start," is the starting time of the incident that is recorded in the incident database. The column right after it, which is labeled \Before Start" is the last time before an incident occurred when any probe vehicle drove by the incident location and didn't witness the incident. The column labeled \New Start" is the adjusted start time that should be between the original start time and the time when the previous probe vehicle passed the incident location. The next three columns, columns 4-6, deal with the incident ending time. They follow the same format as the start time columns: \End" is the incident ending time, \After End" is the rst time a probe vehicle drove by and didn't witness the incident, and \New End" is sometime between the two. The column labeled \Duration" is the original duration and the \Final Duration" is the new duration. This table is only generated when the nished incident level parameter, INC_FINISHED_OUT_LEVEL, is set to INC_FIN_OUT_MEDIUM or INC_FIN_OUT_VERBOSE. This table is placed either on the screen on in the nished incident output le as determined by the parameter INC_FINISHED_OUTPUT.

16.2.5 The Finished Incident Output

The nished incident output is generated from the incidents after all of the xes have been applied and the delay for each incident has been calculated. To get output for the nished incidents the nished incident control parameter, INC_FINISHED_OUTPUT needs to be set to something other than NO_FINISHED_OUTPUT. We will assume that it is set to SCREEN_FINISHED_OUTPUT so that the output comes up on the screen. If this was set to FILE_FINISHED_OUTPUT then the results would have been placed in the le named inc.finished in the incident output directory. For a complete listing of the various options see Chapter 7. If the nished incident output level parameter, INC_RAW_MATCH_OUTPUT, is set to INC_FIN_OUT_SPARSE then the nished incident output section will contain three distinct parts: the incident distribution over the various days, the delay calculation conditions, and the delay calculation results. The incident distribution section is simply a listing of the number of incidents that occurred on each day during the study period and whether or not they occurred during the morning or the afternoon shift. A section of this table is given below:
Incident count by day: Date #Incs/Day 2/16/93 46 2/17/93 0 . #Incs/Shift AM 24 AM 0

PM PM

22 0

238CHAPTER 16. PROGRAM OUTPUT: THE INCIDENT AND CROSS DATA ANALYSIS
. 3/19/93 Average # incs: 0 1.9 AM AM 0 1.0 PM PM 0 0.9

Note that all of the days of the study section are listed out even if there aren't any incidents on those days (I cut out a large section in the middle for space considerations). Since in this example we are only looking at incidents on 2/16/93, nothing shows up on any of the other days. The next piece of text that is generated under the nished incident routine is a listing of the various conditions that were used to calculate the delay for the incidents. This section looks like this:
Delay Calculation Conditions: Incident Explanation = Car Headway = Delay Calculation = Delay Calc Type = Congestion Speed = Fix Loop Holes Option = Incident Delay Method = Num Upstream Det. = Num Downstream Det. = All incidents 420 seconds WRT_AVERAGE_SPEED ONLY_HAVE_POSITIVE_DELAY 55 mph YES_FIX_HOLE_ERRORS Fixed number of detector: -1 0

The incident explanation is the user supplied title that is put on the incident graphs that are discussed in Section 16.3.1. The car headway is the average headway time between the probe vehicles. Whether this gets used in the calculation is determined by the line below labeled \Incident Delay Method." If this line says \Fixed number of detectors," like it does now, then the car headway, along with a xed number of detectors, is used to de ne the the incident space-time box that the delay is calculated from. If the \Incident Delay Method" instead says \Prede ned space-time boxes" then the user de ned space-time boxes are used and the headway time is ignored. The rest of the lines are pretty straight forward. The last piece of output generated by the nished incident section under the output level parameter of INC_FIN_OUT_SPARSE is the delay calculation results. This is probably the section that will be used the most. It contains summary information on quite a few things:
Stats on all incident delays: Match incidents witnessed once = YES ALL results include headway time of = Number of Incidents = 46 Number witnessed once = 23 Min Max Incident Duration 7 165 TT Response ( 4) 0 37 TT Clearance ( 3) 0 28 Incident Delay 0.00 446.74 7:00

Mean 27.80 16.25 17.33 22.77

Std. Dev. 43.72 18.50 15.37 69.84

Std. Error 6.45 9.25 8.88 10.30

16.2. TEXTUAL OUTPUT

Incident delay vs. Slope Intercept Sigma_slope Sigma_intercept Chi^2 duration line: = 0.915 = -2.671 = 0.197 = 10.149 = 147485.766

239

The rst two lines tell the user whether the program attempted to match the incidents that were only witnessed once and what headway time the program used. The third line is the total number of incidents and the fourth line is the number of incidents that were witnessed once. The table below that gives the minimum, maximum, mean, standard deviation, and standard error for incident duration, tow truck response, tow truck clearance, and incident delay. Note that the numbers after the tow truck response and clearance headings are the number of each type. So in the table above, there were 4 incidents that had a tow truck respond, and the incident database had the tow truck clearance time for 3 incidents. The statistic that we used the most was the mean incident delay. The incident delay versus duration section gives the results of an attempt to t a straight line to a plot of incident delay versus incident duration. This plot is discussed in Section 16.3.1. These are the basic incident and data analysis statistics. The two other levels of the nished incident control parameter simply give a more detailed picture of the xes that were done on the incident data and the delay calculation. If the nished incident output level parameter, INC_RAW_MATCH_OUTPUT, is set to INC_FIN_OUT_MEDIUM then in addition to the output above, the nished incident output section will contain a table that lists out all of the vital statistics on the incidents. A section of this table looks like this:
Individual incident statistics: Inc. Type Inc # Date D 1 2 3 Time South Link Loop 1 2/16/93 0 5 0 0 6:49 1 5 20 2 2/16/93 0 3 0 0 6:54 1 4 7 3 2/16/93 0 5 0 0 7:00 1 17 5 4 2/16/93 0 0 2 0 7:34 1 13 12 Good Bad Files Files 5 0 4 0 17 0 13 0

Duration 0:00:00 0:27:00 0:06:00 0:00:00

Delay 1.54 4.36 1.32 0.58

The various columns to this table are as follows: Inc # : This is simply the incident number. Date : This is the date that the incident took place. Inc. Type D : This is eld P in the incident database that is labeled \Incident Type" in Section 4.5 and has the incident lter parameter INCIDENT_DESCRIPTION. This eld basically tells you whether or not the incident is debris or not. Inc. Type 1 : This is eld Q in the incident database that is labeled \Type 1" in Section 4.5 and has the incident lter parameter INCIDENT_TYPE_1. This eld tells you whether or not the incident is a breakdown or not.

240CHAPTER 16. PROGRAM OUTPUT: THE INCIDENT AND CROSS DATA ANALYSIS

Inc. Type 2 : This is eld R in the incident database that is labeled \Type 2" in Section 4.5

and has the incident lter parameter INCIDENT_TYPE_2. This eld tells you whether or not the incident is an accident or not. Inc. Type 3 : This is eld S in the incident database that is labeled \Type 3" in Section 4.5 and has the incident lter parameter INCIDENT_TYPE_3. This eld tells you whether or not the incident is a CHP ticketing incident. Time : This is the time that the incident was rst witnessed by a probe vehicle. South : This is a 1 if the incident occurred in the southbound direction and a 0 if the incident occurred in the northbound direction. Link : This is eld I in the incident database that is labeled \Link Identity" in Section 4.5 and has the incident lter parameter LINK_ID. This simply tells you the rough location of the incidents. Loop : This gives you the loop number that is just upstream of the incident. Good Files : If you are attempting to calculate the incident delay based on the non- xed loop data then certain loop delay les might not be present. When the program reads in the loop delay les to calculate the incident delay it realizes that some of the les might not be there. This column gives the number of les that it did nd. Bad Files : This is the counterpart to \Good Files." This gives the number of les that it attempted to nd and couldn't. If you are allows working with the corrected loop data then this column should always be zero. If it isn't then something is wrong. Duration : This is the uncorrected duration of each incident. Delay : This, of course, is the incident delay in vehicle- hours. The table above is probably all that you'll ever need when working with the incident delays. But, if for some reason you would like to have an even more detailed analysis of what the program has done then you can set the nished incident output level to INC_FIN_OUT_VERBOSE. This will give you two more pieces of information. The rst is another table that has some extra elds in it:
Summary of fixes to incidents: Inc # 1 2 3 4 Start 6:49:00 6:54:00 7:00:00 7:34:00 End 6:49:00 7:21:00 7:06:00 7:34:00 Dur. 0:00:00 0:27:00 0:06:00 0:00:00 Fixed Start 6:45:30 6:50:30 6:56:30 7:30:30 Fixed End 6:52:30 7:24:30 7:09:30 7:37:30 Fixed Start Dur. Lp Lp 0:07:00 20 16 0:34:00 7 16 0:13:00 5 16 0:07:00 12 16 End Lp Delay 20 1.54 7 4.36 5 1.32 12 0.58

This table basically lists out the nal space time box that the program uses to calculate the delay for each incident. An explanation of each column is given below:

Inc # : This is simply the incident number.

16.2. TEXTUAL OUTPUT

241

Start : This is the original starting time of the incident. End : This is the original ending time of the incident. Dur. : This is the original duration of the incident. Fixed Start : This is the xed starting time of the incident. Fixed End : This is the xed ending time of the incident. Fixed Dur. : This is the xed duration of the incident. Lp : This is the number of the loop detector that is just upstream from the incident. Start Lp : This is the number of the loop detector upstream of the incident that the program
will start to calculate the delay from.

End Lp : This is the number of the loop detector downstream of the incident where the
program will stop calculating the delay.

Delay : This is the incident delay in vehicle-hours.

The second piece of information that the program will generate under the verbose setting is a short analysis of the queue length for each incident. The program will generate a table for each incident that has the total cumulative delay versus the number of detectors upstream of the incident. A typical table would look like this:
Analysis of incident delay/queue length: Detector Back Delay Incident #: 36 1 4.90 2 6.48 3 6.92 4 16.11 5 20.88 6 21.65 7 21.66 8 21.66 . .

Note that the column \detector back" is just the number of detectors upstream of the incident - it is not the incident detector number. For this incident you can see that the delay tapered o to zero right after the seventh detector upstream from this incident. This probably means that the queue only extended back to the seventh detector as well. I must strongly warn you to look at the contour delay plots when attempting to interpret these tables.

242CHAPTER 16. PROGRAM OUTPUT: THE INCIDENT AND CROSS DATA ANALYSIS

16.3 Graphical Output

The fsp program will generate a couple of di erent types of incident and data analysis graphs. These are: Incident histograms. The incident delay versus duration. The correlation plots. The contour plots. The rst two types of plots, the incident histograms and the delay versus duration plot, are placed in the incident output directory. The correlation plots are placed in the individual car shift output directories and the contour plots are placed in the loop data output directories.

16.3.1 The Incident Plots

If the user sets the run le parameter INC_FINISHED_GRAPHS to YES_FINISHED_GRAPH then the fsp program will generate four di erent plots: A histogram plot with the number of incidents. A histogram plot with the percentage of incidents. A cumulative distribution plot. An incident delay vs. duration plot. These are: There are a couple of run le parameters that determine how these plots turn out.

INC EXPLANATION : This is an explanation that is placed at the top of all of the plots.

There is some other information that is also placed in the plot title that the user has no control over. The maximum length that you should probably make any title is around 50 characters. INC GRAPH MAX NUM : This sets the range of the y-axis on the histogram plot with the number of incidents. This allows the user to set the range to a pleasing level. The reason that we don't let gnuplot set this is because gnuplot will always set the range to the maximum value. If we want to compare two di erent plots side-by-side then this can be very irritating. Unfortunately, what this means is that you have to rst run the fsp program to see what the appropriate ranges should be and then come back and set the ranges in the run le and then run the program again. INC GRAPH MAX PERCENT : This sets the range of the y-axis on the histogram plot with the percentage of incidents. This is just like the parameter above.

16.3. GRAPHICAL OUTPUT

Histogram, All incidents (N=46, Avg=20.80, Sd=43.72) 40

243

Number of Incidents

0 0 20 40 60 80 100 Corrected duration (minutes) 120 140

Figure 16.3: Histogram Of The Number Of Incidents. A sample of each one of these plots is given on the next couple of pages by Figures 16.3 - 16.6. There are a couple of things to note about generating these plots: The maximum duration that an incident can have is set in the program to be 150 minutes - just over two hours. Any incident that falls outside of that range is discarded. Since this length of time covered our study period this shouldn't be too much of a problem. The disconcerting thing is that the fsp program spits out the following error message each time that it has to discard an incident:
ERROR: Incident histogram overflow: Have to discard an incident.

You should just ignore these messages. The line that is draw on the delay vs. duration plot is only a linear t of the data. There no is evidence to suggest that the relationship between the duration and the delay should be linear. as follows: The lenames that are used to save these plots in the incident output directory are

chist.dat.X : This is the data le for the cumulative histogram plot. del.dur.dat.X : This is the data le for the delay versus duration plot. fhist.dat.X : This is the data le for the histogram of the percentage of incidents.

244CHAPTER 16. PROGRAM OUTPUT: THE INCIDENT AND CROSS DATA ANALYSIS
Histogram, All incidents (N=46, Avg=20.80, Sd=43.72) 20

% of Incidents

0 0 20 40 60 80 100 Corrected duration (minutes) 120 140

Figure 16.4: Histogram Of The Percentage Of Incidents.

gnuprint.ddX : This is the gnuplot executable le that will print the delay versus duration
plot out to the printer.

gnuprint.hX : This is the gnuplot executable le that will print the histogram plots out to
the printer. gnuview.ddX : This is the gnuplot executable le that will allow the user to view the delay versus duration plot.

gnuview.hX : This is the gnuplot executable le that will allow the user to view the various
histogram plot.

hist.dat.X : This is the data le for the histogram of the number of incidents.
The \X" in each of the le names above represents the incident le number or run number. Each time that the fsp program is run a run number is passed to it. This run number is used to index all of the output les so that the user can save multiple runs without having to copy les around. If you are using the xfsp program then this is taken care of automatically.

16.3.2 The Correlation Plots

The correlation plots are generated as a results of the program attempting to correlate the incident database and the probe vehicle data. A complete discussion of how the correlation plots are generated is given in Section 5.3.1. A typical correlation plot is given in Figure 16.7. The useful thing about the correlation plots is that they can be used to adjust the incident

16.3. GRAPHICAL OUTPUT

Cumulative Distribution, All incidents (N=46, Avg=20.80, Sd=43.72) 100

245

Percentage (%)

0 0 20 40 60 80 100 Corrected duration (minutes) 120 140

Figure 16.5: Cumulative Distribution Plot. location via the incident location x runtime le. An example of this is given in Section 12.9. There are a couple of run le parameters that need to be set in order for the correlation plots to be made: Since the correlation routine is part of the incident processing section you need to tell the fsp program to process the incidents. This is done by setting the run le parameter PROCESS_INCIDENTS to YES_PROC_INCIDENTS . The correlation routine is only turned on when the parameter CORRELATE_CARS_DATABASE is set to YES_CORRELATE. The correlation routine needs to be turned on in order for any graphs to be made. The run le parameter INC_CORRELATION_GRAPH needs to be set to YES_INC_CORR_GRAPHS. This will tell the correlation routine to generate the graphs. Whether the incident numbers are placed on the plots is determined by the run le parameter NUMBER_INC_CORR_GRAPHS . Even though you probably want to have the incident numbers on the plots, if there are too many incidents then it can get a little hard to see which number goes with which box. If this parameter is set to YES_NUMBER_INC_CORR_GRAPHS then the numbers will be placed on the plots. You have to process some car data so that the correlation routine will know where the key presses are. This means that you have to specify some car data and you have to tell the program to look for the incident key presses in the car data by setting the run le parameter INCIDENT_POINTS to YES_INCIDENT_POINTS.

246CHAPTER 16. PROGRAM OUTPUT: THE INCIDENT AND CROSS DATA ANALYSIS
Duration vs Delay, All incidents (N = 46, Ref spd = AVG) del.dur.dat.0 Linear_fit(x) 500

400

Delay (veh-hr)

300

200 y = 0.91x-2.67 100

-100 0 50 100 Duration (min., 420 min. headway) 150 200

Figure 16.6: Incident Delay Versus Duration. The incidents that are placed on the correlation plots are only the ones that make it through the incident lter. Therefore you should generate an incident lter that will allow everything to pass through. There is only one correlation plot for each shift of car data so the naming scheme is pretty straight forward. There are two main les that generated by the correlation routine that are named incidentcor.gp and incidentcor.gv. Both of these les generate a correlation plot but the rst one dumps it to the printer and the second one displays it on the screen. The way to remember this is to think of the le extension as \Gnuplot Print" or \Gnuplot View." Although the only les the normal user would have to deal with are the two les mentioned above, there are a few di erent les that the correlation routine generates that are placed in the car shift directories. The naming scheme of these auxiliary les is as follows:

carX.idt : These les hold the key presses that the drivers made when they passed by an
incident. The \X" stands for the car number. dYY.b : These les hold the incident locations. The \YY" stands for the incident number there is one le for each incident. These les have such short lenames due to a restriction in gnuplot on the length of the command line. There is nothing that can be done about this. So a typical shift directory might look something like this:
car1/ d10.b d19.b d3.b

16.3. GRAPHICAL OUTPUT

Car and database correlation: am021693 10:00

247

9:30 14 9:00 11 8:30

Time

29 12 13 28 10 25

8:00 56 7:30

9 24 23 4 19 2 3 1 18 15 16 17 21 20

7:00

6:30

6:00 0 5 10 Position (miles) 15 20

Figure 16.7: Incident Correlation Plot.

car1.idt car2/ car2.idt car3/ car3.idt car4/ car4.idt d1.b d11.b d12.b d13.b d14.b d15.b d16.b d17.b d18.b d2.b d20.b d21.b d23.b d24.b d25.b d28.b d29.b d4.b d5.b d6.b d9.b incidentcor.gp incidentcor.gv

As you can see, there are quite a few les with names of the form dYY.b and hence quite a few incidents. Note that I have left out the all of the travel time les that are normally found in this directory. All of the correlation les are stored under the car output directory in the individual shift directories.

16.3.3 The Contour Plots

When told to do so, the fsp program will generate contour plots of the loop data with the incidents placed on them. One important use of the contour plots is that they give you an easy way to gure out where the end of the queue is that built up behind an accident. This is important if you are attempting to gure out the incident space-time boxes for the delay calculations. An example of doing this is given in Section 12.11. The program will make three di erent types of contour plots: Delay : These are plots where the contour lines are delay, which is in vehicle-hours. The root le name for these is contour. I know that it probably should have been delay but it

248CHAPTER 16. PROGRAM OUTPUT: THE INCIDENT AND CROSS DATA ANALYSIS just didn't turn out that way.

Density : These are plots where the contour lines are density, which is in vehicles per mile.

The root le name for these is density1. Di erential density : These are plots where the contour lines are the percentage over the average density. So if the density of tra c for one day at one spot was 200 vehicles/mile and the average density for that spot was 100 vehicles/mile then the di erential density would be 1, which means 100% over the average. So the di erential density are percentages. The root le name for these is density2. For each type of contour plot the program will generate a plot for each direction and for each shift, for a total of 4 di erent plots for each day. The lenames for the gnuplot executable les that generate the contour plots have two parts: a root le name and an extension. The root le name tells what the contour lines are (either delay, density or di erential density) and the extension speci es the direction, time, and output device. The naming convention for the gnuplot executable les is given below:
contour.g{n,s}{a,p}{p,v} density1.g{n,s}{a,p}{p,v} density2.g{n,s}{a,p}{p,v}

As was discussed above, the individual plot types each have their own root le name, but the extensions all have the same format. The brackets in the extensions above each represent one character that can be chosen out of the two characters inside the brackets. Something like {n,s}, which represents the second character in the extension, means that you can only choose the \n" or the \s" but not both. So the naming scheme is as follows: the second character in the extension signi es the northbound or southbound direction, the third character signi es the AM or PM shift, and the fourth character signi es whether to print the plot to a printer or to view it on the screen. For example, to view the delay contour plot for the northbound, AM shift you would use the gnuplot executable le contour.gnav. To print out the di erential density plot of the southbound, evening shift you would use the gnuplot executable le density2.gspp. There are also a couple of data les that the gnuplot executable les read in when making the plots. The naming scheme for these les is similar to the gnuplot executable les:
contour.{n,s}{a,p} density1.{n,s}{a,p} density2.{n,s}{a,p}

The rst character in the extension signi es the direction, and the second character signi es the shift. Since these les hold the raw data, they were not meant to be read or processed by normal users - they are only read in by the gnuplot executable les. There are couple of run le parameters that need to be set in order to generate the contour plots: Since the contour plot generation routine is part of the incident processing section you need to tell the fsp program to process the incidents. This is done by setting the run le parameter PROCESS_INCIDENTS to YES_PROC_INCIDENTS .

16.3. GRAPHICAL OUTPUT

249

The parameter INC_CONTOUR_DELAY_PLOT controls whether the contour plots are generated or not. This needs to be set to YES_INC_CONTOUR_DELAY_PLOTS. The incidents that are placed on the correlation plots are only the ones that make it through the incident lter. Therefore you should make an incident lter to your liking. One suggestion is to just lter out the accidents and see what kind of congestion they cause. The contour plots are all placed in the individual loop day output directories. In Section 12.8 there is an example that shows how to generate the contour plots. Note that you rst need to generate the loop averages before you can make the contour plots. Figures 16.8 through 16.10 give examples of the various contour plots that the program can generate.
Southbound Delay: lp021693 (Ref spd = AVG) 3 1 35 36 33 39 32 401 4 Det. # 31 38 5 15 17 4 12 13 19 18 6 11 2 9 30 20 7 1 34 14:00 14:30 15:00 15:30 16:00 16:30 17:00 17:30 18:00 18:30 19:00 19:30 Time 3 16

Figure 16.8: Contour Plot Of Delay.

250CHAPTER 16. PROGRAM OUTPUT: THE INCIDENT AND CROSS DATA ANALYSIS
Southbound Density: lp021693 254 170 85.6 5 36 33 39 32 401 4 Det. # 31 38 15 17 4 12 13 19 18 6 11 2 9 30 20 7 1 34 14:00 14:30 15:00 15:30 16:00 16:30 17:00 17:30 18:00 18:30 19:00 19:30 Time 3 16

Figure 16.9: Contour Plot Of Density.

Southbound Diff. Density: lp021693 (Ref spd = AVG) 5 36 33 39 32 401 4 Det. # 31 38 15 17 4 12 13 19 18 6 11 2 9 30 20 7 1 34 14:00 14:30 15:00 15:30 16:00 16:30 17:00 17:30 18:00 18:30 19:00 19:30 Time 3 16

Figure 16.10: Contour Plot Of Di erential Density.

Chapter 17

A Larger Picture: The Whole FSP Data Flow

Up to this point I have talked almost exclusively about how to run the fsp once the data is on the hard drive. Well, due to the large size of the data set, this begs the question, \How did the data get on the hard drive in the rst place?" In this chapter I will try answer this question and to also give a slightly larger picture of the whole process than what I have done previously. The data started o being generated in the test cars and the loop detectors. There were four probe cars that drove up and down the freeway for three hours in the morning and three hours in the afternoon. During that time period the loop detectors were also taking data. All of this data was stored on 3 1 inch oppy disks. Every few days the data from the cars and 2 the loop detectors was collected and brought to the lab where they were transferred to the Sun Workstation. All of this is represented in Figure 17.1. As you can see, the data started with the cars and the loop detectors which are underneath label 1 in this picture. The transfer of the data was done with the help of a PC and a device called a disk loader. A disk loader is an add on device to the PC that allows you to stack a bunch of disks in a hopper and then to automatically feed them into a disk drive one by one. A software program runs on the PC to control the transfer of the data from the oppy disks to the Sun. This program, called ftran, controls the disk loader, stores the data on the PC hard drive temporarily - step 3 in Figure 17.1 - and then transfers the data to the Sun across the local ethernet in step 4. The ftran program actually does quite a bit of setup on the Sun every time that it runs. The rst thing that it does is to create the directory structure that the fsp program is expecting. It then places the data in these directories. Next, it makes a run le that corresponds to this data and places it in the run le directory. It then makes a log le that lists out the what data was just transferred and places this in the log le directory. Finally, it makes a special script le and places it in the home directory of the main user. When run, this special script le will execute the fsp program with the recently generated run le and will print out the error reports to the local printer. Once the analysis on the data has been run, the data can be transferred to a magnetic tape for easy storage. Currently, all of the data for an entire month can be stored on one 8mm tape. Since an 8mm tape costs about $9, this is a very cost e ective way to store the data if you are done with it. 251

252

CHAPTER 17. A LARGER PICTURE: THE WHOLE FSP DATA FLOW

FSP

Cars:

Disk Loader

FSP

Loops:

x 20

Ethernet

Workstation

Figure 17.1: The Larger Picture.

253 Just to sum up what the ftran program does: Control the disk loader such that it can read in all of the disks. Figure out what data is present on the disks. Make a run le that corresponds to the data. Make a log le that corresponds to the data. Log onto the Sun. Create the appropriate directory structure on the Sun. Place the car and loop data in these directories. Transfer the new run le and log le. Create a script le to run the fsp program with the new run le and to print the error reports out to the printer. 10. Transfer the special script le to the home directory of the main user. 11. Log o the Sun and delete the data from the PC hard drive. The program was designed this way so that somebody that was not very familiar with the fsp program could analyze the data. In order to run through the whole process, from the disks to the printouts of the error reports, they would only have to do a few tasks: 1. 2. 3. 4. Place the disks in the disk loader. Run the ftran program on the PC. Log onto the Sun and run the special script le. Pick up the printouts. 1. 2. 3. 4. 5. 6. 7. 8. 9.

The slowest part in this whole process was the reading of the oppy disks by the disk loader. What was envisioned was that we could stack a bunch of disks in the disk loader and then go out to lunch. When we came back, all of the data would be transferred to the Sun waiting for us to run the analysis program. At the point, this process works pretty well. One nal point should be made about the way the ftran program names the run les that it generates and transfers to the Sun. Since le names on a PC can only be 8 characters long I had to come up with a naming scheme that had only 8 characters. What I came up with was the following format: rfXXYYZ.run. Where \XX" stands for the month, \YY" stands for the day, and \Z" stands for the transfer number of that day. The ftran program keeps track of the transfers that it does and it marks each one with a speci c number for that day. This needed to be done so that the le name wasn't dependent on just the date. If it was and somebody transferred two batches of disks to the Sun then there is a possibility for confusion in what to name the les. For example, if there were 5 batches of disks that were transferred to the Sun on March 10th, then the run les would be named:

254

CHAPTER 17. A LARGER PICTURE: THE WHOLE FSP DATA FLOW

rf03101.run rf03102.run rf03103.run rf03104.run rf03105.run

Appendix A

Frequently Asked Questions and Warnings

This appendix contains a list of frequently asked questions and warnings about the fsp program. These were collected by having a few people around the country beta test the program. The points noted here are mainly from the questions that they asked. Since most people just want to work with the loop data, most of the information deals with that. Note that these questions only deal with the current version of the software which is fsp 1.1. If you are using an earlier version, you might want to rst glance at the changes that have been made. They are listed out in Appendix B.

A.1 General

Pointer: Before downloading the support software for the xfsp program, you should check to

see if it is already on your system. The xfsp program was written in a scripting language called Expect. In order for you to run the xfsp program you need to have the program expectk on your system. You can download the Expect software from the ftp server at UC Berkeley and install it yourself, but you should rst check to see if it is installed on your machine. It is a very common program and most system administrators will have already installed this program. To see if you have the program expectk try the command: which expectk. This will tell you if you have it or not. Chapter 3 has instructions on how to download and install the program if you don't already have it.

Question: Can I process data from both the before study and the after study at the same time? No, you can't. The fsp program can only process one type of data at a time. You can't
work with two di erent data sets in the same run le. You have to split up the work into two run les. Question: Can I ask the author any questions? Of course. I'd be happy to answer any questions that you might have. You can just send me email at pettyk@eecs.berkeley.edu. 255

256

APPENDIX A. FREQUENTLY ASKED QUESTIONS AND WARNINGS

A.2 The Loop Data

Pointer: Download the processed loop data instead of generating it yourself.
You should always try to download the processed loop data and use that. Learning to use the fsp program can be a pain. There are usually a couple of di erent processed data sets on the ftp server in the directory /pub/PATH/FSP/Data/Processed. The loop data les are in two columns. The rst column is the number of seconds since midnight and the second column is the value - either speed, occupancy, ow, delay, etc. You should look at the warnings about the units of the loop data les to make sure that you realize what each le contains. The units for the various loop data ow les are all di erent. The units for the individual lane ow les are in vehicles per time period. So if your output time period is 60 seconds, then the units are the number of vehicles per 60 seconds. An individual lane le is a loop output le that ends with a number. So the le floop3.nc1 is the le that contains the counts, or ow, at detector #3 in the northbound direction for lane #1. A more thorough explanation of the loop le naming scheme is given in Section 15.3. The units for the loop ow data that has been averaged over all of the lanes is in vehicles per lane per hour. These les all have extensions that end with the letter \d". The units for the on and o ramps are in vehicles per time period.

Question: What is the format of the loop data?

Warning: The units for the loop ow data les are not consistent.

Question: I made the individual lane les but there are lots of holes in the data. Why is this?
Can this be xed? The short answer is \no." The individual lane les have holes in them due to the 170 loop controllers being buggy. The program won't do anything to x these holes. What the program does x is the data that is aggregated over all of the lanes. There is an extended discussion of this point in Section 11.2.

Question: I created the loop data speed les and I noticed that at some times the speed was

409 (miles/hour). How could that happen? The loop detector speed is calculated by guring out the amount of time that it takes for a vehicle to pass over both loop detectors. What the program does is it looks at the time di erence in the falling edges of the pulses generated by a vehicle moving over the loop detectors. You should refer to Figure 4.5 and the discussion there if you don't know how speeds are calculated. The key thing is that the vehicle needs to be picked up by both detectors. There are couple of things that could happen that could cause the loop speeds to be incorrect:

If a truck goes over the loop detector, the loop detector might pick up each axle as a separate vehicle. This is probably the most likely cause of incorrect speeds.

A.2. THE LOOP DATA

257

If a car is switching lanes and it is picked up by the rst detector but not the second then this could mess up the speeds. On the other hand, if a car is switching into the lane then it's possible that the second detector will pick up the car but not the rst. The thresholds in the loop detectors could be calibrated incorrectly. This would be more likely to cause the occupancy reading to be incorrect than the speed to wrong, though. The best way around this is to use data of a higher output time period. This will cause the spurious spikes to be averaged out. Warning: The speed for the loop les averaged over all of the lanes is not the normal average. The speed in the loop output speed les is the weighted harmonic mean speed. This is slightly di erent from the mean average speed. The mean average speed would be something like: PN i Vm = P=1 FiVi N
i=1 Fi

and the weighted harmonic mean speed is:

PN i=1 Vh = PN Fii : F
i=1 Vi

Where Fi is the ow for lane i of the freeway, V is the speed for lane i, and N is the number of lanes. You should refer to Section 11.1 to see why the speed is calculated this way. Question: I generated the loop speeds for a 1 second output period and there are a lot of values that are zero. Then I tried to lter this data with the exponential lter and the average wasn't correct. Why is this? What's going on here is that whenever you are ltering the loop data and there is a zero speed on the freeway the fsp program just sticks in the last speed. So if there is a whole series of zero speeds, then there could be a whole series of values that are the same. This was done because if the data aggregation period is small then in the early morning periods there were times when there wouldn't be any cars travelling over the detectors and the fsp program was simply putting zeros in those spots. When we went to lter this data (with our exponential lter) all of those zeros were causing the ltered speed data to be arti cially low. Hence our delay calculations were completely o . The way that we xed this is to have the speed at a detector be the last speed when no cars went over the detector. The reason that this is ok, for our purposes, is because we always want to get the delay or the density. And this involves multiplying the speed by the ow. So whenever no cars have past over the detector, and hence the ow is zero, the speed doesn't matter.

258

APPENDIX A. FREQUENTLY ASKED QUESTIONS AND WARNINGS

If you need to have the speed data be zero when there are no cars that travel over the detector then just don't lter the data and this feature will be turned o . So if you generate the loop data with a 1 second output period without ltering then there will be a lot of time periods that have zero speeds. If you want the program to carry speeds forward but you don't want to lter the data then you can specify a lter value of 0:01. This is such a small lter value that the e ect on the data will be negligible.

Warning: The loop data speed value lter is reset in the morning.

If the loop speed starts o at zero, which is very common in the early morning, then the lter is reset the rst time it changes from zero. This way the lter doesn't get \stuck" at a low number. So if you are ltering the loop data with a large lter value you may notice that for the morning period there is a jump in the speed, that shouldn't happen in a true lter, when it changes from zero to some positive value.
PM period never includes 2:00 pm. If you are generating the loop data with an output period of 5 minutes, the loop data reported for some time is the data corresponding to the previous 5 minutes. The program simply sums and/or averages the data over the previous 5 minutes and reports it to you. Since there is a skip from 10am until 2pm the 5 minutes previous to 2pm are not in the raw loop data. Therefore, the program has to wait until 2:05 to make its rst report.

Warning: Although the data for the PM period starts at 2:00 pm, the rst data point for the

Warning: The AM data is missing the rst second of data.

The rst line of each loop data le is read in and used to setup the system (things like con gure the output, initialize the variable structures). This line of data is then discarded. The program then starts reading in the data for real. Since each line of raw loop data corresponds to a second of data, the rst second is always missing. The problem arises when the program tries to get an average for the di erent variables. The program thinks that the data was collected for an entire time period, not for a time period minus one second. Therefore, the data for the rst time period will be slightly o . It might even be fractional. The le extensions are too long for a PC. There are les that have le name extensions of more than three characters, like floop4.ss10. If you try to untar these les then they will be saved with only three characters in the extension. This means that the le floop4.ss10 will be saved as floop5.ss1. This is unfortunate because this will overwrite the proper le by that name. If you need to have these les then what you need to do is to extract the troublesome les one at a time and then move them to a safe place. This can be done by specifying to the tar program which les you want to extract. For example, if you were trying to extract the les floop13.sc1 and floop13.sc10 from the tar le lp021693.tar then the steps would look something like this:

Warning: The loop data le extensions are longer than three characters.

A.2. THE LOOP DATA

pettyk 1: ls lp021693/ lp021693.tar pettyk 2: tar xvf lp021693.tar lp021693/floop13.sc1 x lp021693/floop13.sc1, 554287 bytes, 1083 tape blocks pettyk 3: ls lp021693/ lp021693.tar pettyk 4: ls lp021693 floop13.sc1 pettyk 5: mv lp021693/floop13.sc1 lp021693/lp13sc1.dat pettyk 6: tar xvf lp021693.tar lp021693/floop13.sc10 x lp021693/floop13.sc10, 554293 bytes, 1083 tape blocks pettyk 7: ls lp021693 floop13.sc1 lp13sc1.dat pettyk 8: mv lp021693/floop13.sc1 lp021693/lp13sc10.dat pettyk 9: ls lp021693 flp13sc1.dat lp13sc10.dat

259

As you can see above, I rst extracted the le floop13.sc1 from the tar le and then I moved it to a di erent le: lp13sc1.dat. Then, I extracted the le floop13.sc10 from the tar le. Note that this le was saved as floop13.sc1 because of the le extension limitation. I then moved this le to lp13sc10.dat. Question: Can I use the xfsp program without downloading all of the raw data? The answer is \Yes" but the explanation is rather long - so bear with me. Before I answer the question, I think that I should point out why it is being asked. What this person wanted to do was to nd the delays for various incidents but they didn't have enough disk space to download the raw loop data. So they wanted to know if it would be possible to put only the processed data on their machine and then use the xfsp program to calculate the delays. If you are just using the fsp program without the xfsp program the the answer to this is \yes" because when the fsp program is calculating the delay for an incident, it doesn't need to have the raw loop data les on the system - only the processed loop data. To do this you simply specify in the run le that you don't want to regenerate the processed data from the raw data. The fsp program will notice this in the run le and it won't look for the raw loop data les. It will only look for the processed les because that's what it needs to calculate the delay for each incident. So if you were using only the fsp program then you would have to download only the processed data and not the raw loop data. But a problem shows up when you try to do this with the xfsp program. One of the screens of the xfsp program presents the user with a list of the raw loop detector data that is available. The program gets this list by searching through the loop data directories for loop data les of the form loop3.dat or loop3.dat.Z. For each le that it nds in that format it makes a button in the loop data select window that you can set to indicate whether to use that data or not. The problem with not downloading the raw loop data is that the xfsp program will nd the loop directories but it won't nd the raw loop data les inside of them. Therefore it will get confused and say something bad.

260

APPENDIX A. FREQUENTLY ASKED QUESTIONS AND WARNINGS

But you can fool the xfsp program into thinking that it has the raw loop data les when it fact it doesn't. To do this you need to create a \stub le" for each possible raw loop data le. A stub le is a le that has the same name as a raw loop data le, but the le itself is empty. This way, when you click on the \Loop Data Select" button the xfsp program will see these les and mistakenly think that it has them (the program will not check the size of the les and see that they have nothing inside them). You can download the stubs from the anonymous ftp server at UC Berkeley. See the discussion in Section 2.1 if you don't know how to download stu using ftp. The les are in the following locations:
/pub/PATH/FSP/Misc/lp.stub.set1.tar.Z /pub/PATH/FSP/Misc/lp.stub.set2.tar.Z

To successfully fool the xfsp program, you will need to do a couple of things: 1. Grab one or both of the stub les. 2. Uncompress and untar this le. You will get a directory called Loopdata (make sure that you untar this in a place that doesn't already have a \Loopdata" directory). 3. When you run the xfsp program specify the directory that you just made as the \Loop data directory". You should be able to open up the \loop data select" button and see all of the loop les. 4. Place the processed loop data les that you downloaded under an output directory. You should probably change the permissions on these les to make then un-writable. The reason for this is that there are options in the fsp program to delete certain output les and you wouldn't want to lose them accidentally. 5. When you run the xfsp program specify the output directory to the proper directory. Your nal directory structure should look something like this:
A) /home/FSP/Set1/Input/Loopdata B) /home/FSP/Set1/Input/Cardata C) /home/FSP/Set1/Input/Incdata D) E) F) G) H) I) J) /home/FSP/Set1/Output /home/FSP/Set1/Output/Loopdata /home/FSP/Set1/Output/Loopdata/lp031093 /home/FSP/Set1/Output/Loopdata/lp031193 /home/FSP/Set1/Output/Loopdata/lp031293 /home/FSP/Set1/Output/Loopdata/lp031393 .

So your input loop directory is (A). This is where you should place the stub directories and les. The main output directory is (D). You should place the processed loop data les that you downloaded from UC Berkeley in directory (E). Examples of these processed loop le directories are (F) - (J). Note that you don't need to create the directories (B) or (C). You only need these if you want to do something with the car data or the incident data.

A.3. THE PROBE VEHICLE DATA

261

A.3 The Probe Vehicle Data

Question: What is the probe data used for?
Unfortunately, the probe data was not very reliable. There are long discussions in Sections 5.1 and 5.3 discussing the problems with the probe vehicle data. In summary I will say that we didn't use the probe vehicles for anything in our study other than generating the incident logs.
passed an incident and didn't see it) the time are the same as the time that the incident was rst witnessed. This can happen if the rst probe vehicle at the start of the shift witnessed the incident. In this case, there were no probe vehicles that went down the freeway before the rst one. Therefore, there wasn't a vehicle that drove by the incident location and didn't see the incident. In this case, the program simply says that the before pass time is the same as the time that the incident was rst witnessed. You should see Section 16.2.4 for a discussion of the incident pass times.

Question: Sometime when I generate the incident pass times (the times when a probe went

Question: What exactly are the distances travelled by the probe vehicles?

The distance travelled down the freeway by the probe vehicles can be broken down into four di erent components:

Southbound travel distance: This is the distance on the freeway that the vehicle travway that the vehicle needs to travel to get back on the freeway heading northbound. It is the distance of the southbound o ramp, the freeway overpass, and the northbound on ramp. Northbound travel distance: This is the distance on the freeway that the vehicle travels in the northbound direction. Northern turn-around distance: This is the same as the souther turn-around distance but in reverse. So the equation for the total distance traveled per loop would look like:

Southern turn-around distance: This is the distance at the southern end of the free-

els in the southbound direction.

Dtot = Southbound distance] + Southern turn around]

+ Northbound distance] + Northern turn around]

The values given in Table A.3 are the starting and ending distances of the parameters and they are in feet. Note that the values for the southbound and northbound travel distances are the entire length of the freeway - they are not the distance over which we have loop detector data. Also note that we don't have a lot of con dence in these numbers. If you are looking for these distances in the car run les then you might not nd them. Some of the reasons that these les might be messed up are as follows:

262

APPENDIX A. FREQUENTLY ASKED QUESTIONS AND WARNINGS

Parameter Start Southbound travel distance 0 Southern turn around 47600 Northbound travel distance 49870 Northern turn around 97620 End Length 47600 47600 49870 2270 97620 47750 100000 2300

Table A.1: Travel Distances (in feet). 1. If the driver didn't press the start key during one of their runs then there will be two runs pushed together. This is a very common mistake - but it is easy to spot because the le will be twice as long. 2. The vehicles didn't always make a loop when they were driving during the study period. Sometimes, if they arrived too early, they were told to drive to the Denny's by the entrance of the freeway. Since this data is stored at the end of the le (because the program doesn't know that the run is over), the total length of each run might vary. 3. There are many driver errors. Sometimes the drivers forgot to press the start keys at the start of the run and instead pressed them once they were down the road a ways. The program of course assumes that when the start keys were pressed that the car was at one speci c location. What this means is that the car distance le for this run will be incorrect. This is a very hard error to spot. 4. I thought that the turn around point in the run had changed during the course of the experiment. But it seems that the distance that that change was not signi cant. A more thorough discussion of the probe vehicle data is given in Section 4.3 and in Chapter 14.

A.4 The Incident Database

Question: Do I have to specify an incident lter? What if I don't want to lter any incidents?
The incident lter always has to be speci ed on the command line. If you don't want to do anything with the incidents then you need to set the following run le parameter:
PROCESS_INCIDENTS = NO_PROC_INCIDENTS

This will tell the program to not lter any incidents. If you want to make a dummy incident lter le you can create a le with the following lines:
#DATA_TYPE #INC_NUMBER = F =

Actually, you can have any size le as long as the rst characters in all the lines are #'s (which is the comment character for the incident lter).

A.4. THE INCIDENT DATABASE

263

Question: How do I gure out the tow truck assisted incidents?

In order to know if a tow truck showed up we can just check to see if a tow truck arrival time is listed. If it is then we are assured that a tow truck arrived. So in the incident lter, you should have the following line:
TOW_ARRIVAL = 6:00 - 20:00

Since we only have probe vehicle data from 6:30am until 9:30am and then again from 3:30pm until 6:30pm, the time period from 6:00am until 8pm should cover all of the tow truck arrival times. You should look at the example given in Section 9.3.4. Question: How do I nd out how many incidents occurred at some section of the road during some time period? You can do this by specifying the correct incident lter. The best thing to do is to review the examples presented in Section 9.3. They talk about the way to lter di erent stu out of the incident database. A terse list of what to do is given below: 1. Look at the table in Section 4.5 that discusses the incident database and gure out the incident database elds that you need to lter. To lter out the incidents for a certain section of the road and a certain time period, then you want the elds:
Column E I Name Time: Link Identity: Description Time listed in military time Link identity according to between exits

2. Look at Tables 9.1 and/or 9.2 to learn what the parameters are in the incident lter that correspond to these elds. In this case they are:
Column E I Name Time Link Identity Field Descriptor TIME LINK_ID

3. Specify the desired quantities for these parameters in the incident lter. For example, if you want incidents that occurred on the link between A-Street and Winton from 2pm until 4pm you would put the following lines in the incident lter: 4. Run the fsp program with this incident lter and a run le that processes the incidents. Question: Is the time recorded in the \time" eld of the incident database when an operator discovered it, when police, etc reported it, or what has been determined to be the start of the incident? The time eld in the incident database is the time that the rst probe vehicle witnessed the incident. Note that since there were only four probe vehicles, with an average headway time between them of seven minutes, the starting and ending times of the incidents are sampled by seven minutes. One part of the fsp program attempted to x this but it didn't quite work. See the discussion in Sections 5.3.2 and 16.2.4 for more information.
TIME LINK_ID = 14:00 - 16:00 = 4

264

APPENDIX A. FREQUENTLY ASKED QUESTIONS AND WARNINGS

The DATA TYPE descriptor was meant to distinguish between incidents from di erent sources. The \F" meant that the incident was from our eld data, the \C" meant that the incident was from the CADD database, and the \T" meant something that I can't remember. As it turns out, we never included the incidents from any source other than our eld data. As a result, you don't need to lter on this descriptor because every incident in the database has this as an \F".

Question: What does the DATA TYPE eld mean in the incident lter?

Appendix B

Changes From Version 1.0 to 1.1

This appendix contains a list bugs that were xed, and changes that were made, since the rst release of the fsp software. They are more or less in descending order of importance. The xfsp program no longer uses the extended version of Tcl or BLT. These program were extensions to the standard Tcl/Tk program that were needed to control the running of the fsp program from the xfsp program. Now the xfsp program uses the standard program Expect which should already be installed on most systems. This should reduce the amount of time it takes to install the xfsp program considerably. The fsp program no longer has a short and a long data set. There is only a short data set and it is only referred to as the data set. I realized that there was no reason to have a long data set because all of the subroutines only worked with the short data set. Note that this means that the run le parameters have changed. Although you can still use the old run le parameters, I would encourage you to use the new ones. The correction factors for the loop data were put in the code. You can now x the loop data when there are consistency errors. Quite a bit of code was changed in log_fsp.c to accommodate this. The les that this generates are the hloop les. For a more thorough discussion of the consistency correction see Sections 5.2.2 and 11.2.3. If the duration of the incident is zero and there is no user-added headway then the delay is automatically zero. The program used to sometimes pull in the delay for that one time period but now it doesn't. This was changed in the le inc_util.c. The program now spits out the processed loop data les with only one digit past the decimal place. This should reduce the amount of space needed to store the data by 1 in 3 some cases!!! The program used to carry the loop speed over when the current speed was zero. This was only done because we needed to lter the speed and all of those zeros were pulling down the loop speed. Now, if the loop ltering factor is zero, the speeds are not carried over. In the le fsp_calc.c I changed an error in fprintf() where I wasn't passing the le name. 265

266

APPENDIX B. CHANGES FROM VERSION 1.0 TO 1.1

In the le fsp_calc.c I xed the calculation of the interpolated speed so that it checks for a zero before doing the division. What was happening before is that I wasn't checking to make sure that the divisor wasn't zero before doing division. I increased the number of holes in the loop data that you can ll. This was de ned in the parameter MAX NUM LOOP HOLES in fsp.h. If you were generating the data for a very small output period then it was possible for the table used to hold the holes to run out of room and cause the program to crash. There was a problem with the rst entry after the start of the pm time period. I had to rede ne the start of the PM period to be 50401 instead of 50400, reset the data structures once we got to the PM period, and reset the loop lter. The result is that there is one less value in the PM study now.

Bibliography
1] John K. Ousterhout. Tcl and the Tk Toolkit. Addison-Wesley, 1993. 2] Don Libes. Exploring Expect: A Tcl-based Tookit for Automating Interactive Applications. O'Reilly and Associates, Inc., 1994. 3] A. Skabardonis, H. Noeimi, K. Petty, D. Rydzewski, P. P. Varaiya, H. Al-Deek. Freeway Service Patrols Evaluation. Technical Report UCB-ITS-PRR-95-5, Institute of Transportation Studies, University of California, Berkeley, June 1994.

267

Index
average car data, 84 contour plots, 177 loop data, 102, 103 loop speed, 152 car data, 261 distances travelled, 261{262 downloading, 37 via World Wide Web, 40 lter factor, 84 output les, 197{207 raw data format, 41{45 size of data set, 40 CAR_CLEANUP, 83 CAR_DATA_COMPRESSED, 83 CAR_DATA_DIRECTORY, 84 CAR_DATA_SET_NUMBER, 84 CAR_DIRECTORY_ROOT, 84 CAR_SPD_FILTER_FACTOR, 84 Chen, L., 15 con guration les car, 73 incident, 78 loop, 75 consistency errors, 61 contour plot, 163, 247{249 delay, 248 delay calculation, 164 density, 248 run le example, 134, 137, 188{191 run le parameter, 89, 93 with loop averages, 99 CORRELATE_CARS_DATABASE, 85, 245 correlation routine example, 179 explanation, 64 268 output, 233 plots, 244 run le parameter, 85 data car data, see car data downloading, 37, see netscape, see ftp incident data, see incident data loop data, see loop data size, 40 data dropouts, 58 DEBUG_LEVEL, 86 debugging, 86 delay calculating, 59, 157 incident, 161{165 DELAY_CALCULATION, 86 DELAY_DOWNSTREAM_NUM, 87 DELAY_TYPE, 87 DELAY_UPSTREAM_NUM, 87 delete car les, 83 loop les, 91, 93 density calculating loop delay, 163{165 correcting, 62 output contour plots, 247{249 run le example, 173{177 run le parameter, 93 directories input, 72 car, 72, 84 incident, 78, 97 loop, 74, 100 output, 79, 105 loop, 79 DROPOUT_TIMES, 87

INDEX
EMISSION_CALC, 88 ERROR_FILE_NAME_EXT,

269 88 title, 94 xgraph, 194

HEADWAY_TIME_VAL,

errors car reports, 197 huge, 199 key, 198 medium, 200 small, 200 histogram over ow, 243 loop reports, 213 examples car data, 169, 170 x incident durations, 185 x incident location, 179 general parameters, 168 loop averages, 173 loop data, 171, 172 space-time boxes, 188 Expect, 13, 23, 25, 255 installing, 28 lter car data, 84, 107, 108, 171 incident, see incident data, lter loop data, 63, 102 FIX_INC_DELAY_BOX, 89 FIX_INC_DURATION, 89 FIX_INC_LOCATION, 90, 185, 236 FLOOP_CLEANUP, 91, 155 FSP_DATA_FILE_NAME, 91 ftp, 17, 26, 37, 193 locations, 27 GLOOP_CLEANUP, 91 GNU_PRINTER, 92 gnuplot car les, 202{207 density plots, 248 incident les, 244 loop les, 218{220 printer, 92 GORE_POINTS, 92 GPS, 14, 45, 106, 200 graph, 193 gnuplot, 193 incident, 95

histogram, 242 axis, 96 le names, 243 title, 94 HLOOP_CLEANUP, 93 HOV lane, 154

93, 185

INC_CONTOUR_DELAY_PLOT, 93, 249 INC_CORRELATION_GRAPH, 94, 245 INC_DUR_EXPAND_FRACTION, 94 INC_EXPLANATION, 94 INC_FINISHED_GRAPHS, 95 INC_FINISHED_OUT_LEVEL, 95 INC_FINISHED_OUTPUT, 95 INC_GRAPH_MAX_NUM, 96 INC_GRAPH_MAX_PERCENT, 96 INC_MATCH_ZERO_WIDTH, 96 INC_RAW_MATCH_OUTPUT, 96 INC_RAW_OUTPUT_LEVEL, 97

incident database coding scheme, 49 incident data assisted incident, 134 downloading, 37 via World Wide Web, 40 lter, 48, 262 example, 131{134, 263 lter elds, 48{52, 128 lter format, 127 incident duration, 68{70, 261, 263 incident location, 64{68 output les, 229{249 raw data format, 48{53 size of data set, 40 INCIDENT_DATA_DIRECTORY, 97 INCIDENT_POINTS, 97, 245 INRAD_POINTS, 97
KEY_DATA_FILE_NAME,

a L TEX tables, 194 loop data, 224

270 long data set, 48 loop data averaging, 103 downloading, 37 via World Wide Web, 40 dropout times, 58{61 errors consistency, 61{63 lter, 103, 257, 258 lter factor, 102 xing, 256 consistency, 61{63, 100, 155, 157 dropout times, 58{61, 100, 155, 156, 256 output les, 213{227, 258 output format, 217, 256 raw data format, 45{48 size of data set, 40 validity tests, 139{148 LOOP_AGGREGATE_VALUES, 98, 226 LOOP_AVERAGE, 98 LOOP_CONSISTENCY_FIX, 100 LOOP_DATA_COMPRESSED, 100 LOOP_DIRECTORY, 100, 101 LOOP_END_TIME, 102 LOOP_FILTER_FACTOR, 102 LOOP_FLOW_PLOTS, 102 LOOP_HOLES_FIX, 100 LOOP_OUTPUT_PERIOD, 103 LOOP_START_TIME, 103 LOOP_TEXT, 103 lynx, 40
MAIN_DIRECTORY, PERCENT_GAS_TRUCKS,

INDEX
106 Petty, K., 255 probe data, see car data PROCESS_INCIDENTS, 106, 245, 248 ramp con guration, 48, 76 deleting les, 91{93, 109 le names, 156, 220{222 output les, 157 output units, 105 REPORT_OPTION, 106 run number, 13, 21, 34, 244 run le, 81 examples, 167 parameters, 82{109 Rydzewski, D., 15, 48 Sanwal, K., 15, 61 short data set, 48 Skabardonis, A., 16 speed harmonic average, 153, 257 loop speeds, 152{154 errors, 256 SPEED_DIST_PLOTS, 107 SPEED_TIME_PLOTS, 107 Tcl/Tk, 13, 23, 255 downloading, 27 environment variables, 29 installing, 27 TIME_DIST_PLOTS, 108 TIME_ERROR_BOUND, 108 tow truck, 134, 239, 263 TRAFFIC_DELAY, 109 TRAFFIC_LOW_SPEED, 109 travel time, 42, 56 gore points, 92, 207 INRAD points, 97, 207 plots, 206, 210, 211 tables, 198 Varaiya, P., 16 World Wide Web, 40

map, 37 mosaic, 40

103 104 104, 245 105

NAV_DATA_FILE_NAME,

netscape, 40 Noeimi, H., 15, 48

NUMBER_INC_CORR_GRAPHS, OUTPUT_DIRECTORY, 105 OUTPUT_FLOW_AVG_FACTOR,

PERCENT_DIESEL_TRUCKS, 106

INDEX
xfsp, 13, 23 downloading, 26 installing, 29{31 run le, 81 run le parameters to windows, 121 running, 31, 33, 259{260 setup les, 33 support software, 23{25 windows to run le parameters, 121 xfspview, 34 xgraph, 194 wildcards, 194

271

Intrusion Detection Honeypots
From Everand
Intrusion Detection Honeypots
Chris Sanders
3/5 (2)
Aws Networking Fundamentals
100% (1)
Aws Networking Fundamentals
322 pages
Computer Science for Kids: A Storytelling Approach
From Everand
Computer Science for Kids: A Storytelling Approach
Jen Looper
No ratings yet
Artificial Intelligence Programming with Python: From Zero to Hero
From Everand
Artificial Intelligence Programming with Python: From Zero to Hero
Perry Xiao
4/5 (1)
Exam Ai 102 Designing and Implementing A Microsoft Azure Ai Solution Skills Measured
No ratings yet
Exam Ai 102 Designing and Implementing A Microsoft Azure Ai Solution Skills Measured
15 pages
Risk Analysis
From Everand
Risk Analysis
Terje Aven
No ratings yet
Manual - Festo - Ladder
No ratings yet
Manual - Festo - Ladder
306 pages
Deep Dive: Exploring the Real-world Value of Open Source Intelligence
From Everand
Deep Dive: Exploring the Real-world Value of Open Source Intelligence
Micah Hoffman
No ratings yet
Blender Unleashed: Mastering the Art of 3D Creation
From Everand
Blender Unleashed: Mastering the Art of 3D Creation
Kameron Hussain
No ratings yet
Automated Data Collection with R: A Practical Guide to Web Scraping and Text Mining
From Everand
Automated Data Collection with R: A Practical Guide to Web Scraping and Text Mining
Simon Munzert
3/5 (1)
Bare Metal C: Embedded Programming for the Real World
From Everand
Bare Metal C: Embedded Programming for the Real World
Stephen Oualline
No ratings yet
Programming the TI-83 Plus/TI-84 Plus
From Everand
Programming the TI-83 Plus/TI-84 Plus
Christopher Mitchell
No ratings yet
C Programming for the Pc the Mac and the Arduino Microcontroller System
From Everand
C Programming for the Pc the Mac and the Arduino Microcontroller System
Peter D Minns
No ratings yet
Google Ads Keyword Research: Your Bedside Guide
From Everand
Google Ads Keyword Research: Your Bedside Guide
Jay Nans
No ratings yet
Content Creation Revolution with chatGPT
From Everand
Content Creation Revolution with chatGPT
Maria Cowen
No ratings yet
Gray Hat Hacking the Ethical Hacker's
From Everand
Gray Hat Hacking the Ethical Hacker's
Çağatay Şanlı
5/5 (1)
Keras to Kubernetes: The Journey of a Machine Learning Model to Production
From Everand
Keras to Kubernetes: The Journey of a Machine Learning Model to Production
Dattaraj Rao
No ratings yet
Plain JavaScript: Learning the Front-End
From Everand
Plain JavaScript: Learning the Front-End
Roger Beans-Rivet
No ratings yet
Creality Ender 3 and Creality Slicer Tutorial for 3D printers and tips and tricks.
From Everand
Creality Ender 3 and Creality Slicer Tutorial for 3D printers and tips and tricks.
Armin Snyder
3/5 (1)
Modern JavaScript: Coding for Today and Tomorrow
From Everand
Modern JavaScript: Coding for Today and Tomorrow
Jay Nans
No ratings yet
Handover of Power - Digital: Global Version - Volume 5/21
From Everand
Handover of Power - Digital: Global Version - Volume 5/21
Andreas Seidl
No ratings yet
Industrial Statistics with Minitab
From Everand
Industrial Statistics with Minitab
Pere Grima Cintas
No ratings yet
Using the TI-84 Plus
From Everand
Using the TI-84 Plus
Christopher Mitchell
No ratings yet
Professional Papervision3D
From Everand
Professional Papervision3D
Michael Lively
No ratings yet
Accelerated Computing With HIP: Second Edition
From Everand
Accelerated Computing With HIP: Second Edition
Yifan Sun
No ratings yet
SiP System-in-Package Design and Simulation: Mentor EE Flow Advanced Design Guide
From Everand
SiP System-in-Package Design and Simulation: Mentor EE Flow Advanced Design Guide
Suny Li (Li Yang)
No ratings yet
Advanced Multiplayer Game Development with Ureal Engine 5: A Comprehensive Guide to C++ Scripting
From Everand
Advanced Multiplayer Game Development with Ureal Engine 5: A Comprehensive Guide to C++ Scripting
Vladimir Kiselev
No ratings yet
GUI Magic: Mastering Real Projects in Python
From Everand
GUI Magic: Mastering Real Projects in Python
John Nunez
No ratings yet
Cybersecurity Blue Team Toolkit
From Everand
Cybersecurity Blue Team Toolkit
Nadean H. Tanner
2/5 (1)
OpenGL Deep Dive: Expert Techniques and Performance Optimization: OpenGL
From Everand
OpenGL Deep Dive: Expert Techniques and Performance Optimization: OpenGL
Kameron Hussain
No ratings yet
Evaluation of Some Android Emulators and Installation of Android OS on Virtualbox and VMware
From Everand
Evaluation of Some Android Emulators and Installation of Android OS on Virtualbox and VMware
Dr. Hidaia Mahmood Alassouli
No ratings yet
Securing ChatGPT: Best Practices for Protecting Sensitive Data in AI Language Models
From Everand
Securing ChatGPT: Best Practices for Protecting Sensitive Data in AI Language Models
Matthew C. Smith
No ratings yet
Clang Compiler Frontend: Get to grips with the internals of a C/C++ compiler frontend and create your own tools
From Everand
Clang Compiler Frontend: Get to grips with the internals of a C/C++ compiler frontend and create your own tools
Ivan Murashko
No ratings yet
Applied Incident Response
From Everand
Applied Incident Response
Steve Anson
No ratings yet
TensorFlow Developer Certificate Exam Practice Tests 2024 Made Easy
From Everand
TensorFlow Developer Certificate Exam Practice Tests 2024 Made Easy
Mr Troy
No ratings yet
1.1 (Introduction To Data Structures) New
No ratings yet
1.1 (Introduction To Data Structures) New
12 pages
Electronics Resource
No ratings yet
Electronics Resource
3 pages
Manual Eng
No ratings yet
Manual Eng
103 pages
Handout RPS - V1.0
No ratings yet
Handout RPS - V1.0
121 pages
Gpps Manual
No ratings yet
Gpps Manual
252 pages
LEC 1 Introduction
No ratings yet
LEC 1 Introduction
57 pages
Inspection and Test Plan For Electrical Lighting Systems Installation With Checklists - Inspection and Test Plan Templates
100% (2)
Inspection and Test Plan For Electrical Lighting Systems Installation With Checklists - Inspection and Test Plan Templates
5 pages
STL Festo
100% (2)
STL Festo
117 pages
CSC 204 - Study Session 1
No ratings yet
CSC 204 - Study Session 1
17 pages
Naveen Dsa PPT
No ratings yet
Naveen Dsa PPT
18 pages
C-TEC - XFP Programming Tools
100% (1)
C-TEC - XFP Programming Tools
48 pages
Getting Started in C and Assembly Code With The TMS320LF240x DSP
No ratings yet
Getting Started in C and Assembly Code With The TMS320LF240x DSP
42 pages
357 810 820 GA3 PLC Programming
No ratings yet
357 810 820 GA3 PLC Programming
152 pages
CSC 204 Session 1
No ratings yet
CSC 204 Session 1
16 pages
Fdatool Tutorial
No ratings yet
Fdatool Tutorial
18 pages
File Organization and Processing - Alan Tharp PDF
100% (2)
File Organization and Processing - Alan Tharp PDF
210 pages
Introduction To Computer
No ratings yet
Introduction To Computer
69 pages
Tutorial Comtrade 1
No ratings yet
Tutorial Comtrade 1
40 pages
PLC 2
No ratings yet
PLC 2
11 pages
ITP For Diesel Generator .
No ratings yet
ITP For Diesel Generator .
3 pages
Introduction To Computer Systems
No ratings yet
Introduction To Computer Systems
69 pages
Mathematical Diagram
No ratings yet
Mathematical Diagram
5 pages
Self Evaluation
No ratings yet
Self Evaluation
2 pages
Solutions Unit 2
No ratings yet
Solutions Unit 2
4 pages
African Philosophy of Reincarnation
No ratings yet
African Philosophy of Reincarnation
6 pages
The Past Continuous - Eduardo Garcia
No ratings yet
The Past Continuous - Eduardo Garcia
2 pages
B.ED Course 202 Notes
No ratings yet
B.ED Course 202 Notes
54 pages
Jake S Resume Anonymous
No ratings yet
Jake S Resume Anonymous
1 page
7399 25487 1 PB
No ratings yet
7399 25487 1 PB
12 pages
Least Common Multiple
No ratings yet
Least Common Multiple
6 pages
PostgreSQL Training 72622
No ratings yet
PostgreSQL Training 72622
3 pages
II Unit Test Sceme Chart Class Nursery To XII 16.08.23
No ratings yet
II Unit Test Sceme Chart Class Nursery To XII 16.08.23
1 page
Excel Assignment-1
No ratings yet
Excel Assignment-1
2 pages
Passive Voice Grammar Active Passive: by Our Information Officer Transitive: Verbs Which Currently Take Object
No ratings yet
Passive Voice Grammar Active Passive: by Our Information Officer Transitive: Verbs Which Currently Take Object
3 pages
The Ultimate Guide To Citing Anything in Chicago Style
100% (1)
The Ultimate Guide To Citing Anything in Chicago Style
14 pages
Embedded Systems: Quiz 2
No ratings yet
Embedded Systems: Quiz 2
19 pages
Class 2 Computer Ab
No ratings yet
Class 2 Computer Ab
2 pages
The First Part of Rhetoric Invention PDF
No ratings yet
The First Part of Rhetoric Invention PDF
14 pages
Failed To Connect - Org - Bluez.error - Failed - Raspberry Pi Forums PDF
No ratings yet
Failed To Connect - Org - Bluez.error - Failed - Raspberry Pi Forums PDF
13 pages
Let'S Have A Party!: Level
No ratings yet
Let'S Have A Party!: Level
7 pages
Agreement Bib
No ratings yet
Agreement Bib
99 pages
Memory Forensics and Volatility Framework
No ratings yet
Memory Forensics and Volatility Framework
4 pages
Studentregistration Project Proposal
No ratings yet
Studentregistration Project Proposal
7 pages
Assessment 2: Name: Course: Subject: Date: A.Y. 2021-2022
100% (1)
Assessment 2: Name: Course: Subject: Date: A.Y. 2021-2022
4 pages
Praveen Kumar - Talend Developer - Delhi
No ratings yet
Praveen Kumar - Talend Developer - Delhi
4 pages
Lecture No.04 Data Structures: Dr. Sohail Aslam
No ratings yet
Lecture No.04 Data Structures: Dr. Sohail Aslam
54 pages
Arm Notes
No ratings yet
Arm Notes
19 pages
Copia de 2015 NOV Senior 1 P2
No ratings yet
Copia de 2015 NOV Senior 1 P2
2 pages
Research An About Tourism
100% (1)
Research An About Tourism
4 pages

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.