Incorporating Reliability Performance Measures into Operations and Planning Modeling Tools: Reference Material (2014)

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

124 CHAPTER 6 Trajectory Processor 6.1 Introduction To promote the use of end-to-end travel time reliability measures in the professional community for regionwide transportation operations planning, it is important and critically needed to develop a flexible visualization platform for analyzing microscopic and mesoscopic dynamic simulation results, particularly in tracking vehicular movement, path, and time-dependent trip- related statistics. As a generic visualization platform for travel time reliability, the Vehicle Trajectory Processor designed in this project aims to apply new methods of communication between transportation practitioners, decision makers, and the public. This software package aims to assist stakeholders from departments of transportation (DOTs) and metropolitan planning organizations (MPOs) with effectively applying data processing and visualization tools to (1) understand advanced but sophisticated model structures and reliability-related output and (2) use higher-fidelity transportation simulation and measurement results to estimate and calibrate underlying transportation system processes under different traffic conditions. 6.1.1 Purpose and Objectives The objective of the Vehicle Trajectory Processor is to provide a visualization platform for tracking and analyzing traffic assignment simulation results with a special focus on system-level travel time reliability. The Vehicle Trajectory Processor is designed to perform the following tasks:  Read vehicle trajectory files for each scenario, including an interface that directly imports simulation outputs from DYNASMART and other packages, such as Aimsun.  Read GPS vehicle trajectory data.  Publish scenario-specific travel time reliability measures and display on the network/Google Maps [e.g., most unreliable origin–destination (O-D), link, path].  Display the aggregate travel time distribution over multiple scenarios by considering the probability of each scenario.  Compare observed and simulated travel time reliability measures. 6.1.2 Concept of Operations To meet the design goals, the Vehicle Trajectory Processor consists of the following basic functioning modules.

125 Map Matching and Vehicle Data Preprocessor Internally, simulated vehicle trajectories [from dynamic traffic assignment (DTA) or microsimulation] may not contain longitude and latitude information. In addition, although the GPS trajectories data are recorded in longitude and latitude coordinate system, this information may not match to the real-world network. Thus, to correctly display the vehicle trajectories on the real-world network, this raw data must be preprocessed by the map-matching module to correct geographic location information. As the vehicle trajectory data can come from various sources, including geographically distributed (cloud-based) databases, a vehicle data preprocessor must be able to access the data, no matter locally or remotely, and convert various sources of data into a universal data representation for easier processing for the Vehicle Trajectory Processor. Vehicle Trajectory Processor The Vehicle Trajectory Processor Module is the core data fusion component of the software application developed in this research. The inputs to this module include a set of simulated vehicle trajectories, generated using different scenarios in traffic simulation software, and GPS vehicle trajectories (both data sources are already preprocessed and converted into a universal format by the vehicle data preprocessed module). Based on the predefined measure of effectiveness (MOE) settings, this module will generate individual scenario-specific O-D travel time statistics [scenario-specific average O-D travel time and standard deviation (SD)] and aggregated O-D travel time statistics (aggregated average O-D travel time and SD). It also produces both O-D–level and path-level travel time statistics. Besides these statistics, the Vehicle Trajectory Processor Module also prepares data for various internal visualization tools to present the results. Statistic Result Presenting and Analysis Module This module provides three styles of user interfaces (UIs) to present statistics results to better analyze either O-D–level or path-level travel time. a. Table-based statistic presentation UI Both O-D–level and path-level travel time statistics (average and SD of travel time) are presented in tables. Scenario-specific travel time statistics are listed side by side for straightforward comparisons so that the critical O-D pairs or most unreliable O-D pairs can be easily identified. b. Chart-based statistic presentation UI The O-D–level travel time distribution is visualized with different graphs: scenario- specific or aggregated probability density function graph, cumulative distribution function (CDF) graph, and so on. This UI can also display additional travel time reliability indices—for example, Planning Time Index (PTI) or buffer time. c. Google Earth–based path presentation UI

126 To view and compare paths, this UI is able to display any possible paths between any O- D pair on Google Earth. With this capability, it is much easier to identify whether a path is a normal path or a detour. The overall system architecture is illustrated in Figure 6.1.

127 Figure 6.1. System architecture. GPS Vehicle DataPS ehicle ata DYNASMART Vehicle DataY S T ehicle ata Aimsun Vehicle Datai sun ehicle ata Vehicle Data Map Matching Module Vehicle Data Pre-processor GPS Vehicle Data in Universal Format Cloud-based Data Storage and Pre-processing Vehicle Trajectory Processor Simulated Vehicle Data in Universal Format Scenario 1 Simulated Vehicle Data in Universal Format Scenario 2 Scenario-specific OD/path travel time statistics GPS-specific OD/path travel time statistics OD/Path Travel Time MOE Settings Google Earth-based Visualization Platform Table-based Analysis UI Chart-based Analysis UI Google Earth- Based Analysis UI Universal Vehicle Representation Generated Travel Time Statistics Data Analysis Tools Transportation Network

128 6.2 Software Description The major software components developed in this research can be described by the universal vehicle data representation used to describe the vehicle trajectory data and the data flow diagrams, which identify system components and interactions. 6.2.1 Universal Vehicle Data Representation The input data for the Vehicle Trajectory Processor are simulated vehicle trajectory files from traffic assignment and simulation software packages—for example, DYNASMART and Aimsun. In addition, GPS vehicle trajectory data are another important source of input data. The simulated vehicle trajectory files from these software packages and GPS vehicle trajectory data have unique formats to represent the movements of the vehicles in the network. In order for the Vehicle Trajectory Processor to load and analyze these various sources and formats of vehicle trajectory files, it is important to design a universal data structure internally to represent these various input data. After thoroughly investigating the formats of the vehicle files from the abovementioned software packages and GPS vehicle trajectory data, this universal vehicle representation (data structure) is designed to encompass necessary information to identify the vehicle movement and allow derivation of the travel time information between origin and destination zones. Table 6.1 lists the necessary information recorded by this universal vehicle data structure. Table 6.1. Universal Vehicle Representation Data Element Definition Vehicle ID Identify an individual vehicle Origin zone ID The starting zone ID of a vehicle Destination zone ID The ending zone ID of a vehicle Departure time The departure time from origin zone by this vehicle Total Travel Time The total travel time between origin and destination zones by this vehicle Node Array An array recording the nodes traveled by this vehicle from the origin zone to the destination zone Data Element Definition Vehicle ID Identify an individual vehicle Origin Zone ID The starting zone ID of a vehicle Destination Zone ID The ending

129 zone ID of a vehicle Departure Time The departure time from origin zone by this vehicle Total Travel Time The total travel time between origin and destination zones by this vehicle Node Array An array recording the nodes traveled by this vehicle from the origin zone to the destination zone 6.2.2 Data Flow The overall vehicle trajectory processing procedure can be divided into three subprocedures: preprocessing procedure, vehicle trajectory processing procedure, and result presentation procedures. Figure 6.2 illustrates the input and output data for procedure. During the preprocessing, the map-matching engine converts the vehicle movements in a transportation planning network into real-network representation. These converted vehicle trajectory data are then output in a universal format.

2014.10.24 L04 Reference Materials for Posting.doc 130 Figure 6.2. Data flowchart.

131 The universally formatted vehicle trajectory data are input for vehicle trajectory processing procedure, along with MOE settings. The standard output from this procedure are OD-level or path-level, scenario-specific or aggregated travel time statistics (average and SD of travel time). Based on specified MOE settings, other MOEs can be generated as well. The result presentation procedure takes the statistics generated in vehicle trajectory processing procedure and prepares data for display in various UIs. Based on the UI control selected by the user, the corresponding UI is activated to present the statistic results. 6.3 Integration with Selected Models (DYNASMART and Aimsun) 6.3.1 Procedure 1. Import trajectory for multiple scenarios a. DTA simulation results (e.g., DYNASMART) b. GPS vehicle location records (e.g., from TomTom) c. Simulated vehicle records (e.g., from VisSim, Aimsun) 2. Read user-defined MOE (critical O-D, paths) 3. Extract trajectory set for selected spatial element (O-D, path) 4. Calculate travel time PDF/CDF and Planning/Buffer Time Index, for individual scenarios and in combination, based on prespecified MOE settings 5. Present calculated statistics and MOEs in a straightforward presentation UI to facilitate comparisons of observed and simulated travel time reliability measures. The calculated O-D–based path statistics may be displayed as path travel time PDF/CDF. If multiple scenarios are loaded for analysis, the combined PDF and CDF from these scenarios can also be generated and displayed. Figure 6.3 shows an example O-D statistics UI. Additional MOEs, such as planning time and schedule delay, if prespecified, can be also displayed in the UI, as shown in Figure 6.4.

132 Figure 6.3. Example O-D statistics user interface. Figure 6.4. Additional MOEs displayed in the Vehicle Trajectory Processor. To view the path on the Google Earth interface, a user can simply select a path (a row) in the path statistics table as shown in Figure 6.5. The user can also press and hold the Control key to select multiple rows in the path statistics table to view multiple paths in the Google Earth display. The “Type” column indicates the source of the path: “V-file” indicates this path is extracted from a DYNASMART vehicle file, and “GPS” indicates that this path is from a GPS trajectory file.

133 Figure 6.5. Paths between an O-D pair. Exporting function is provided to export all of the content in the O-D statistics table to the project folder for further analysis. 6.3.2 Processing and Analyzing GPS Data The GPS traces from TomTom Inc. were used to compare with the routes produced by the Google routing engine (i.e., Google Earth) to evaluate the applicability of using GPS data for traffic simulation calibration and assessment. The first objective is to examine and validate the data quality of GPS records and provide insights on using those data for travel time reliability studies. The second goal is to select some representative O-D pairs for further comparisons with simulated vehicle trajectories from DTA simulators (e.g., DYNASMART). The GPS data provided by TomTom cover approximately 10 days, with data from May 3, 2010 (Monday), used in the following analysis. The routes that share the same origin and destination are analyzed. The zone identification numbers in the GPS data follow the zonal definition from the best practice model (BPM) for the New York region. O-D pairs: Origin ID: 637, Destination ID: 529 For example, the vehicles (Internal Vehicle_ID: 1051, 1774, 2956, 3049, 3287, 3533; Origin ID: 637, Destination ID: 529) share the same origin and destination as shown in Figure 6.6. Table 6.2 shows some of the comparisons of travel time between TomTom and Google Earth for O-D pairs with large volumes.

134 Figure 6.6. Comparison of path from TomTom GPS traces and Google Earth. Table 6.2. Vehicle Trajectory Path Analysis—Comparison Between GPS and Google Routing Paths Internal Vehicle ID Departure Time (5/3/2010) Trajectory Length from TomTom (mile) Routing Length from Google Earth (m) Travel Time from TomTom (min) Travel Speed from TomTom (mile/h) Average Link Speed (mile/h) Travel Time from Google Earth (min) Route Comparison 1051 11:54 am 6.77 3.8 24.17 16.81 9.43 5 Detour 1774 6:55 am 5.53 3.8 25.91 12.81 8.80 5 Same Path 2956 8:06 am 5.39 3.8 21.73 14.88 10.49 5 Same Path 3049 8:31 am 6.78 3.8 21.23 19.14 10.74 5 Detour 3287 8:58 am 5.71 3.8 23.51 14.57 9.70 5 Same Path 3533 6:37 am 5.53 3.8 25.34 13.09 9.00 5 Same Path The travel time changes of the six vehicles in Table 6.2 are plotted in Figure 6.7.

135 Figure 6.7. Corresponding travel time from TomTom GPS traces. By investigating the detailed underlying path traces, the possible reasons for detour may be investigated. Possible reasons may be to avoid traffic congestion or perform other activities in a single trip (visit intermediate destinations). In the example shown in Figure 6.8, the possible reason for detour is to perform other activities in a single trip—for example, drop off/pick up children—and the possible intermediate destination may be Thomas Jefferson High School. Figure 6.8. Another comparison of path from TomTom GPS traces and Google Earth. (Left image from © 2012 Google Earth)

136 The following example, with data shown in Figure 6.9, compares O-D pairs with many records. The travel time from TomTom is 25.34 min while the travel time from Google Earth is 5 min. The travel speed from TomTom is 13.09 mph. Possible reasons for a longer travel time from TomTom compared with the same path by Google Earth may be due to the fact that congestion was experienced. Figure 6.9. GPS traces of TomTom and corresponding historical traffic condition maps from Google Maps. From these comparisons between TomTom and Google Earth, the following conclusions can be obtained: 1. In general, the travel time of GPS traces of TomTom is longer than that of Google Earth. The route provided by Google Earth is the free flow, which does not take congestions into consideration. And the GPS traces do not always comply with the shortest path due to some personal driver behaviors. So the travel time of GPS traces of TomTom is longer than that of Google Earth. 2. Even the GPS traces of one vehicle have the same path with the Google Earth (Internal Vehicle_ID: 3533); the travel time of TomTom is longer than that of Google Earth too. The possible reason is the congestion in the real world. 3. From the GPS trajectory of the vehicles, some vehicles detour a lot. Maybe the vehicles tried to do something first. For example, a student may drive to pick up friends first before going to the university. In the team’s comparison, the vehicle (Internal Vehicle_ID: 358) is typical. It can be inferred that this vehicle detours to the airport to do something. It is possible that some vehicles (Internal Vehicle_ID: 1002) got lost trying to find a parking lot.

137 6.3.3 Processing Vehicle Trajectory Files from VisSim and Aimsun Through Map Matching Vehicle Trajectory File in VISSIM and Aimsun Usually the vehicle trajectory generated by traffic assignment and simulation software packages includes the vehicle movement information. However, this information often represents in node IDs/link IDs used by the underlying transportation planning network. To display this information to the real-world geographic information system (GIS) network, it is necessary to map the node IDs/link IDs to the longitude and latitude coordinate system. Therefore, map matching is required before the reconstructed trajectories can be correctly displayed on the map. VisSim and Aimsun can be programmed to record individual vehicle parameters for each simulation step. Recording vehicle parameters on a second-by-second basis can be most beneficial for creating vehicle trajectory files. The vehicle records output in VisSim are configured through Evaluation=>Files…=>Vehicle record. The Configuration window allows for definition of any combination of the vehicle parameters. The vehicle trajectory file that can be used for map matching can be obtained through a combination of the following parameters:  Simulation time [or Simulation Time of Day (TOD)];  Vehicle number;  Link number;  World coordinate X; and  World coordinate Y. If the VisSim simulation resolution is set to 10 (which is updating simulation parameters every 0.1 s, most common for microsimulation models), the Resolution of the Vehicle Record Filter should be set at 10 Time step(s). This provides vehicle record outputs for every second. The output is by default given in .fzp file, which is basically a text file. However, since vehicle records for each vehicle for large networks and longtime evaluation periods can be quite large, it is recommended to configure the database vehicle record file for easier manipulation (in the Vehicle Record–configuration window).