Chapter Four: Contents - (Route Planner - 06 September 2002 - LA-UR-00-1767 - TRANSIMS 3.0)
Chapter Four: Contents - (Route Planner - 06 September 2002 - LA-UR-00-1767 - TRANSIMS 3.0)
Volume Three—Modules 06 September 2002 i Chapter Four: Contents (Route Planner – 06 September 2002 – LA-UR-00-1767 – TRANSIMS 3.0) 1. INTRODUCTION . . 1 1.1 OVERVIEW . 1 1.2 TRANSIMS NETWORK . 2 2. ROUTE PLANNER DESCRIPTION . . 5 2.1 OVERVIEW . 5 2.2 DISTINGUISHING FEATURES . 5 2.3 TERMINOLOGY . 6 2.4 TRAVEL MODES . 7 2.5 TRIP REQUESTS . 8 2.6 PARKING . 10 2.7 SHARED RIDES . 10 2.8 ANOMALOUS ACTIVITY FILE . 11 2.9 NETWORK LAYERS . 15 3. ALGORITHM . . 18 3.1 HIGH-LEVEL DESCRIPTION . 18 3.2 ROUTE PLANNER INTERNAL NETWORK . 18 3.3 TERMINOLOGY . 18 3.4 EXAMPLE TRANSFORMATION . 18 3.5 NETWORK ASSUMPTIONS MADE BY THE ROUTE PLANNER .
22 3.6 TRANSIT . 22 3.7 COST . 26 4. ROUTE PLANNER RUNTIME CONFIGURATION . . 31 4.1 LOGGING CONFIGURATION FILE KEYS . 31 4.2 OTHER CONFIGURATION FILE KEYS . 31 5. PLAN RETIME . . 33 6. ROUTE PLANNER UTILITY PROGRAMS . . 34 6.1 MAKEHOUSEHOLDFILE UTILITY . 34 6.2 10TO26 AND 26TO10 UTILITIES . 34 6.3 CATINDICES UTILITY . 34 6.4 PLANFILTER UTILITY . 35 6.5 DISTRIBUTEPLAN UTILITY . 37 6.6 CONGESTEDLINKS UTILITY . 39 6.7 REARRANGEPLANS UTILITY . 40 7. PLAN FILES . . 43 7.1 OVERVIEW . 43 7.2 FILE FORMAT . 43 7.3 PLAN LIBRARY FILES . 44 7.4 PLAN FILE CONFIGURATION FILE KEYS . 44 7.5 EXAMPLE . 44 Chapter Four—Route Planner Los Alamos National Laboratory
Volume Three—Modules 06 September 2002 ii APPENDIX A: PLAN DATA DEFINITIONS AND DATA . . 45 APPENDIX B: MODE-DEPENDENT DATA . . 47 APPENDIX C: ROUTE PLANNER CONFIGURATION FILE KEYS . . 49 APPENDIX D: PLAN FILE CONFIGURATION FILE KEYS . . 52 APPENDIX E: ANNOTATED EXAMPLE OF A PLAN . . 53 APPENDIX F: ERROR CODES . . 54 CHAPTER FOUR: INDEX . . 55 Chapter Four: Figures Fig. 1. Data flow diagram that shows how the TRANSIMS Route Planner generates travel plans for travelers . 2 Fig. 2. The major input to the Route Planner includes the following data: (1) TRANSIMS Network, (2) activities, (3) transit, and (4) vehicle information from the synthetic population data .
3 Fig. 3. A high-level depiction of the various layers used by the Route Planner. From individual traveler preferences and constraints contained in the synthetic population and activities data blocks, the Route Planner plans for trips that consist of multiple modal legs (e.g., walk-car-walk). Constructing multiple layers in which each layer can be encoded as a different unimodal network allows for the efficient calculation of trips constrained by modal sequences. Also shown are the process links connecting the unimodal networks . 15 Fig. 4. Conceptual diagram of the Route Planner network, in which parking accessories (P,Q) are in the street layer, activity locations (R,S) in the walk layer, and transit stops (C,D) in the transit layers .
16 Fig. 5. The TRANSIMS Network representation of two intersection nodes with a connecting bidirectional link . 19 Fig. 6. The corresponding nodes and edges of the Route Planner Internal Network representation . 20 Fig. 7. This TRANSIMS Network is similar to the one shown in Fig. 5, with the exception that this one has a unidirectional link in place of the bidirectional link . 21 Fig. 8. This figure shows that there are edges in one direction only on the street layer.. 21 Fig. 9. TRANSIMS Network representation of two bus routes . 23 Fig. 10. Route Planner Internal Network representation corresponding to Fig.
9 . 24 Fig. 11. TRANSIMS Network representation of a complex transit network with two bus routes and a light rail line . 25 Fig. 12. Route Planner Internal Network representation corresponding to Fig. 11 . 26 Chapter Four—Route Planner Los Alamos National Laboratory
Volume Three—Modules 06 September 2002 iii Chapter Four: Tables Table 1. Currently recognized travel mode letters . 7 Table 2. Description of time priorities . 9 Table 3. Types of anomalies . 11 Table 4. Anomalous activity file common fields . 11 Table 5. No Path Subtypes . 12 Table 6. No Path fields . 12 Table 7. Invalid Time fields . 13 Table 8. Invalid Shared Ride Time subtypes . 13 Table 9. Invalid Shared Ride Time fields . 14 Table 10. Connectivity fields . 14 Table 11. Location fields . 14 Table 12. Parking fields . 14 Table 13. Actual trip . 29 Table 14. Reported trip . 30 Table 15.
Configuration file keys if a partition exists . 38 Table 16. Configuration file keys to generate a partition . 38 Table 17. Plan library files . 44 Table 18. Mode-dependent data for a car driver . 47 Table 19. Mode-dependent data for a car passenger . 47 Table 20. Mode-dependent data for a transit driver . 47 Table 21. Mode-dependent data for a transit passenger . 47 Table 22. Mode-dependent data for a pedestrian . 48 Table 23. Mode-dependent data for a magic move . 48 Table 24. Route Planner error codes . 54 Chapter Four—Route Planner Los Alamos National Laboratory
Volume Three—Modules 06 September 2002 1 Chapter Four—Route Planner 1. INTRODUCTION 1.1 Overview As its name implies, the Route Planner module generates routes for travelers. Each traveler, including transit drivers, itinerant travelers, and truck drivers, receives an individual travel plan. Once the plans are generated for all travelers, they are simultaneously executed in the Traffic Microsimulator. Constraining the routes between different locations are 1) the transportation network, which represents the metropolitan region being studied, and 2) the preferences of individual travelers. Information about each traveler’s activities (contained in Chapter Three: (Activity Generator)) is used to create trip requests.
A trip request consists of three parts: • the origin and destination of the trip, • the ranges for the preferred starting and ending time and duration, and • the travel mode choice.
Given in the form of a string of characters, the travel mode choice defines the allowed modes of travel and their order. The Mode Preference File (configuration file key: MODE_MAP_FILE) defines the mapping between mode choice numbers (as used in the activity file) and mode choice strings (as used by the Route Planner). Additional information about the vehicles that a particular traveler may use is contained in the Vehicle File (configuration file key: VEHICLE_FILE). Fig. 1 shows the data flow the Route Planner uses to generate plans for individual travelers. Chapter Four—Route Planner Los Alamos National Laboratory
Volume Three—Modules 06 September 2002 2 Fig. 1. Data flow diagram that shows how the TRANSIMS Route Planner generates travel plans for travelers. 1.2 TRANSIMS Network The TRANSIMS Network provides information about the streets, intersections, signals, parking lots, activity locations, and transit stops in a road transportation network. This information is used to construct the Route Planner Internal Network. The internal network is time dependent—that is, travel on a link may incur different delays at different times of the day. The information about delays on links is derived from the Traffic Microsimulator output and provided in the Feedback File (configuration file key: ROUTER_LINK_DELAY_FILE), which specifies the mean delays on each link over 15- minute intervals.
If the delay for a particular interval is not given, the free speed delay is used. More information about link delays may be found in Section 3.7.1. The Route Planner’s core is Dijkstra’s shortest-path-finding algorithm, with extensions for time-dependent delays and paths constrained by travel mode. The internal network and trip requests are given to the path-finding algorithm, which creates routes and outputs them in the form of plans.
1.2.1 Route Planner Major Input/Output Fig. 2 shows the Route Planner’s major inputs and outputs. The major inputs to the Route Planner are • transit routes and schedules, • the activities list, • the TRANSIMS multimodal network, • the vehicle file, and • link travel times. Chapter Four—Route Planner Los Alamos National Laboratory
Volume Three—Modules 06 September 2002 3 The major outputs of the Route Planner are • the plan list, and • the anomalous activity list. Route Planner Transit Data y route paths in network y schedule of stops y driver plans y vehicle properties (e.g.
bus capacity) Network Data y nodes y links y lane connectivity y activity locations y parking places & transit stops y "process" links Vehicles Traveler Plans y vehicle start and finish parking locations y vehicle path through network y expected arrival times along path y travelers (driver and passengers) present in vehicle y traveler mode changes Activities Link Travel Times Fig. 2. The major input to the Route Planner includes the following data: (1) TRANSIMS Network, (2) activities, (3) transit, and (4) vehicle information from the synthetic population data.
1.2.2 Household File To plan just a portion of an activity set, a household file (configuration file key ROUTER_HOUSEHOLD_FILE) may be specified. This file contains a list of household IDs to be planned. In order to support interhousehold shared rides (shared rides where the driver and passengers come from more than one household), dependant households can be specified. If more than one household ID is listed on a single line of the household file, the households are considered to be dependant and will be routed at the same time. See Section 6.1 for information about creating a household file with dependant households.
Chapter Four—Route Planner Los Alamos National Laboratory
Volume Three—Modules 06 September 2002 4 1.2.3 Parallelization To increase execution speed, the Route Planner may be parallelized (run on several processes of the same machine) and distributed (run on several machines). These techniques may be combined, allowing the Route Planner to take full advantage of a cluster of multiprocessor machines. Threads enable the parallel execution of several copies of the path-finding algorithm on a shared memory machine. Each planning thread uses the same copy of the network to create plans and trip requests for different households.
The plans created by the different threads are written to the plan file (configuration key PLAN_FILE). The number of threads that is used is controlled by the configuration key ROUTER_NUMBER_THREADS. If this key has a value of 0, threading is disabled completely. A positive value indicates the number of route planning threads to use. In addition, one thread responsible for reading households from the activity file and one thread responsible for writing plans to the plan file are used. Therefore, if threading is enabled, there are a minimum of three threads (one input thread, one output thread, and one planning thread).
In general, the number of planning threads should be equal to the number of available processors. This will effectively overlap computation with I/O.
Households are assigned to threads using a round-robin approach; so, for the same activity list, each thread is always given the same households to plan. This is important for repeatability, so that the same random numbers are used in different runs of the Route Planner. When running on several computers, several instances of the Route Planner may run concurrently. In this case, the Route Planner is started on each machine with the command: Router where rank is an integer starting at 0, identifying the processor on which this copy of the Route Planner is executing.
The household file, completed household file, plan file, and anomalous activity file are unique for each process and are formed by appending .txx to the appropriate filename, where xx is the rank expressed as a two-digit base 26 number (i.e., the sequence is AA, AB, …, AZ, BA, BB .
Households are assigned to processes by creating the appropriate household file. The utility MakeHouseholds can be used to create appropriate household files. See Section 6.1 for more information. If the configuration file key ROUTER_COMPLETED_HOUSEHOLD_FILE is set, household IDs will be written to this file as they are completed. This allows restart capability, as any households whose IDs are in this file need not be replanned. Because each process has its own completed household file, individual processes may be restarted independently. Care must be taken to avoid writing over the partial plan and problem files.
Chapter Four—Route Planner Los Alamos National Laboratory
Volume Three—Modules 06 September 2002 5 2. ROUTE PLANNER DESCRIPTION 2.1 Overview The Route Planner computes the “shortest” path, subject to mode constraints, for each traveler in the system. Each link within the transportation network has a cost associated with it. Accordingly, the shortest path can be interpreted as least cost, for some generalized meaning of cost. Constraints are provided by criteria such as mode preferences for different legs of the trip. Costs for a link can be computed simply with input, such as an estimated time delay. There are also more sophisticated ways to calculate costs.
For example, they can be calculated based on several variables, including time delays and the actual monetary costs of a link. More abstract variables can be used, such as a penalty for traveling through construction areas, and traveler demographics, such as household income level. 2.2 Distinguishing Features The Route Planner has three distinguishing features. 2.2.1 Individual Plans Plans are computed for each individual traveler in the population, based on that individual’s activity demands and preferences. Such computations enable each traveler to have an individualized view of the transportation system.
Accordingly, costs associated with links in the network are computed separately for each traveler. 2.2.2 Per Link Time-Dependant Delay Link costs are computed in a time-dependent manner that can account for time delays resulting from actual travel conditions, such as peak-hour congestion. These delays are fed back from the Microsimulation into the Route Planner, enabling routes to be changed for individual travelers. Different delays for links containing High Occupancy Vehicle (HOV) only lanes are also accommodated.
2.2.3 Travel Mode Constraints The Route Planner abides by any mode preferences contained in the activity files. Thus, if the activity files specify that a traveler will walk, then take a car, and then walk again between two desired activities, the Route Planner will produce a plan (if feasible) that ensures these modes are used in this sequence. Chapter Four—Route Planner Los Alamos National Laboratory
Volume Three—Modules 06 September 2002 6 2.3 Terminology 2.3.1 Traveler Plan A traveler plan consists of a set of trips that carries the traveler through his or her desired activities.
A trip consists of a set of contiguous legs. Activities of a given duration at a specific location may be separate trips. A leg consists of contiguous nodes and links that are traversed with a single travel mode. For example, a trip may consist of three legs: • walking, • transit, and • walking. A traveler plan could consist of: • a home activity, • a trip from home to work • a work activity, • a trip from work to shopping, • a shopping activity, • a trip from shopping to home, and • a home activity.
2.3.2 Transit Vehicle From the point of view of the Route Planner, a transit vehicle is considered to be any vehicle that makes scheduled stops along a predetermined route. Buses, trains, and streetcars are all considered transit vehicles, whereas a taxi would not be considered a transit vehicle. 2.3.3 Trip Request A request for travel to be planned by the Route Planner, a trip request consists of a starting location, a destination location, a start time, end time, duration constraints, and a mode string.
2.3.4 Mode String A mode string contains a list of travel modes that must be used in the order given along the path from source to destination.
Chapter Four—Route Planner Los Alamos National Laboratory
Volume Three—Modules 06 September 2002 7 2.4 Travel Modes There are twelve individual modes available within TRANSIMS. The modes and their corresponding mode letter are show in Table 1. Bike mode is routed at a faster speed on the walk network. Transit mode allows travel on any type of mass transit system (bus, rail, streetcar, or trolley) and allows walking in between transit routes. This allows transfers between different types of transit that may not use the same transit stop. Magic mode is an unrouted mode. For magic moves, a walk plan is generated whose start and stop times are taken from the times given in the activities.
Its intended use is to enable the use of travel modes that are not supported by the Route Planner and/or the Traffic Microsimulator, such as school busses. The mode string wcwxw, where x is one of b, l, g, p, y, s, or t, is used for park-and-ride. Park-and-ride is not currently supported. Any mode string consisting of the mode letters in Table 1 can be planned. Some are meaningless because they will never produce paths (e.g., cb—because a traveler must walk from a parking location to a bus stop).
Table 1. Currently recognized travel mode letters. Mode Mode Letter Walk w Bike i Car c Bus b Light Rail l Regional Rail g Rapid Rail p Trolley y Street Car s Transit t Magic Move – School Bus K Magic Move -- Other k The mapping between the mode strings used by the Route Planner and the mode numbers used in the activity file is given by the mode map file (configuration file key MODE_MAP_FILE). Each line in this file contains a mode number and a corresponding mode string. An example mode file containing three mappings is shown below. 1 w 2 wcw 3 wtw Chapter Four—Route Planner Los Alamos National Laboratory
Volume Three—Modules 06 September 2002 8 2.5 Trip Requests 2.5.1 Generating Trip Requests from Activities The activity, vehicle, and mode files are used to generate trip requests, which are then planned. In the activity file (configuration file key: ACTIVITY_FILE), travelers’ mode preferences are given by integers. Their meaning is defined by the mode file (configuration file key: MODE_MAP_FILE), which gives the correspondence between these integers and mode strings used by the Route Planner. The Route Planner uses the household file (configuration file key: ROUTER_HOUSEHOLD_FILE) to determine the travelers for which plans should be generated.
If this value defines a file that can be opened, then only the travelers belonging to households whose IDs are listed in this file will be planned. Otherwise, the Route Planner plans all of the travelers in the activity file. All travelers in a single household are planned together because they may share transportation or activities. The Selector/Iteration Database uses the household file as part of the feedback mechanism that enables a portion of the population to be re-planned.
Plans are generated in response to trip requests for a traveler. Trip requests come from the activity file. For every traveler, each pair of consecutive activities at different locations generates a trip request. A trip request consists of a source activity location; a destination activity location; constraints on the start time, end time, and duration; and the travel modes that are allowed. A trip request is satisfied by a plan, in the form of a trip made up of unimodal legs. Travel plans are separated by activity plans.
The activities of each traveler are split into legs that define either activities (activity legs), or travel (transportation legs).
Activity legs begin and end at the same activity location. Transportation legs begin and end at different activity locations. The activity legs are not planned, and are written into the plan file using the times from the activity file. Travel plans are created for the transportation legs. If a transportation leg is multimodal, it is further split up into unimodal sections, which are planned as separate legs of a trip. If a planned trip uses a car, the vehicle file (1) is examined to find the location of the car, and (2) the trip is split. The first mode string ends with the last symbol before c, and the destination of the first part of the trip is the parking location where the car is located.
The second part of the trip starts there (with mode c) and ends at the original trip’s destination. The two parts are planned separately then written out consecutively in the plan file.
2.5.2 Time Priority Each activity has a time priority field that describes which of start time, end time, and duration is important for that activity. The Route Planner uses this information to fit transportation legs in between activity legs. Table 2 describes the various values of the time priority field. Chapter Four—Route Planner Los Alamos National Laboratory
Volume Three—Modules 06 September 2002 9 Table 2. Description of time priorities. Time Priority Important Time Start Stop Duration 1 X 2 X 3 X X 4 X 5 X X 6 X X 7 X X X The following describes how the Route Planner uses the time priority field to determine the start time, stop time, and duration of activity legs.
The start time of an activity is mainly determined by the end time of the preceding transportation leg (PTL). If there is no PTL (because this is the first activity for the traveler) or the PTL ends prior to the lower bound of the start time specified for this activity, the start time is taken from the distribution given in the activity file. If the activity time priority doesn’t specify start time (priorities 0,2,4,6), the start time of the activity is the maximum of the end time of the PTL and the lower bound of the start time of this activity.
If the activity time priority does not include start time (priorities 1,3,5,7) and the PTL end time is prior to the lower bound of the activity start time, then pick a start time from the distribution. If the PTL end time is greater than the activity start time upper bound, then the PTL start time is decreased, if possible, so that the PTL end time is equal to the activity start time upper bound. This is only done if the constraints on the previous activity are not violated. Otherwise, the start time is the arrival time of the PTL. Next, the duration and stop time of the activity must be determined.
Of these two, if only duration is specified by the time priority (priorities 4,5), a duration is picked from the distribution given in the activity file. The stop time is then the start time plus duration. For all other priorities, a stop time is picked from the distribution given in the activity file. The duration is the difference between the stop time and start time. If the resulting duration is 0 or less, then the duration is changed to 1, and the stop time is changed to start time+1.
Finally, the times listed as important by the time priority are checked against the ranges specified by the activity file. An entry in the anomalous activity file is created for any time indicated by the time priority that does not fall in the proper range; however, the traveler is still planned. Chapter Four—Route Planner Los Alamos National Laboratory