Close
About
FAQ
Home
Collections
Login
USC Login
Register
0
Selected
Invert selection
Deselect all
Deselect all
Click here to refresh results
Click here to refresh results
USC
/
Digital Library
/
University of Southern California Dissertations and Theses
/
Scalable evacuation routing in dynamic environments
(USC Thesis Other)
Scalable evacuation routing in dynamic environments
PDF
Download
Share
Open document
Flip pages
Contact Us
Contact Us
Copy asset link
Request this asset
Transcript (if available)
Content
Copyright 2015 Kaveh Shahabi
SCALABLE EV ACUATION ROUTING IN DYNAMIC
ENVIRONMENTS
by
Kaveh Shahabi
A Dissertation Presented to the
FACULTY OF THE USC VITERBI SCHOOL OF ENGINEERING
UNIVERSITY OF SOUTHER CALIFORNIA
In Partial Fulfillment of the
Requirements for the Degree
DOCTOR OF PHILOSOPHY
(COMPUTER SCIENCE)
December 2015
ii
EPIGRAPH
“Regulate your mind. Do not worry excessively about the future. If you have done
everything that has to be done, the future will take care of itself.”
Master Choa Kok Sui
Author, 1952-2007
iii
DEDICATION
This dissertation is dedicated to my parents, Simin and Sohrab, my wife, Yassan, and my
brother Babak. Without them this work would have not been achieved.
iv
ACKNOWLEDGMENTS
First and foremost I would like to thank Dr. John P. Wilson my adviser and chair of my
dissertation committee for his continuous guidance, support, encouragement, and sense of
humor throughout the 7 years I worked under his supervision. Without him I would have
not been able to succeed. I started working in GIS Research Lab under his guidance when
I was only a new master student. One of his strengths as an adviser is that he aligns his
success with the success of his students. He lets you do what you want and then works with
you until you are both happy with the results.
I would like to thank Drs. James E. Moore (Industrial Engineering), Aiichiro
Nakano (Computer Science), Craig A. Knoblock (Information Sciences Institute), and
Gaurav S. Sukhatme (Computer Science) for serving on my committee and offering timely
advice. Also thanks to Dr. Myles G. Cockburn (Preventive Medicine) who has gone above
and beyond in helping me as a research assistant.
In addition, thanks to Wood Rodgers and Esri Network Analyst engineers for their
feedback and technical support. Special thanks are owed to the anonymous reviewers for
their helpful suggestions, Esri Application Prototype Lab for their financial and technical
support, and to the North American Association of Central Cancer Registries for providing
the NAVTEQ road network data. Financial support in the form of research and teaching
assistantship were provided by Spatial Sciences Institute and Department of Computer
Science at the University of Southern California.
It goes without saying that I owe my life and my success to my parents. I consider
myself extremely lucky to grow up in a warm and loving home by two teachers. I would
v
like to thank them for their unconditional love, support, and the encouragement to purse a
PhD. Also thanks to my uncle, Dr. Cyrus Shahabi, for encouraging me to pursue higher
education at USC.
I could have not survived the graduate school without the help of my lab mates and
friends at USC: Ali Khodaei, Daniel W. Goldberg, Evan Lue, Yao-Yi Chiang, Su Jin Lee,
Parisa Ghaemi, and Salman Khaleghi. Thanks for helping me get through this with many
cups of coffee.
vi
TABLE OF CONTENTS
Page
Epigraph .............................................................................................................................. ii
Dedication .......................................................................................................................... iii
Acknowledgments.............................................................................................................. iv
List of Tables ..................................................................................................................... ix
List of Figures ..................................................................................................................... x
Abstract ............................................................................................................................. xii
Chapter 1: Introduction ....................................................................................................... 1
1.1 Overview ............................................................................................................. 1
1.2 Motivation ........................................................................................................... 2
1.3 Problem Definition.............................................................................................. 4
1.4 Thesis Statement ................................................................................................. 8
1.5 Contribution ........................................................................................................ 8
1.6 Outline of Dissertation ........................................................................................ 9
Chapter 2: Related Work .................................................................................................. 10
2.1 Evacuation Taxonomy ...................................................................................... 10
2.2 State-of-the-art Evacuation Routing ................................................................. 13
2.2.1 Descriptive Methods ..................................................................................15
2.2.2 Prescriptive Methods .................................................................................15
Chapter 3: Shortest Path Routing ...................................................................................... 22
3.1 Introduction ....................................................................................................... 22
3.1.1 Problem Definition.....................................................................................23
3.1.2 Motivation ..................................................................................................24
3.1.3 Contribution ...............................................................................................24
vii
3.2 Related Work .................................................................................................... 24
3.2.1 Landmark Search .......................................................................................25
3.2.2 Incremental Heuristic .................................................................................25
3.2.3 Road Knowledge ........................................................................................26
3.2.4 Distance Oracle ..........................................................................................27
3.2.5 Real-Time Traffic ......................................................................................27
3.3 Approach ........................................................................................................... 28
3.3.1 Graph Data Structure .................................................................................28
3.3.2 Search Algorithm .......................................................................................30
3.3.3 Nearest Node Search ..................................................................................32
3.3.4 Integration ..................................................................................................33
3.4 Results ............................................................................................................... 34
3.5 Conclusions ....................................................................................................... 37
Chapter 4: Static Evacuation Routing ............................................................................... 38
4.1 Background ....................................................................................................... 39
4.1.1 Naïve Approach .........................................................................................39
4.1.2 Traffic Model .............................................................................................41
4.1.3 Flocking Simulation ...................................................................................44
4.2 Approach ........................................................................................................... 47
4.2.1 CASPER ....................................................................................................47
4.2.2 CARMA .....................................................................................................49
4.2.3 Complexity Analysis ..................................................................................53
4.3 Results ............................................................................................................... 53
4.3.1 University Campus Evacuation..................................................................54
4.3.2 Urban-Scale Evacuation.............................................................................56
4.3.3 Performance ...............................................................................................59
4.3.4 Interval Time ..............................................................................................62
4.4 Conclusions ....................................................................................................... 64
viii
Chapter 5: Dynamic Evacuation Routing ......................................................................... 66
5.1 Introduction ....................................................................................................... 67
5.2 Related Work .................................................................................................... 69
5.3 Approach ........................................................................................................... 70
5.3.1 Problem Statement .....................................................................................71
5.3.2 Static Solution ............................................................................................74
5.3.3 Dynamic Shortest Path Tree ......................................................................77
5.3.4 Iterative Routing ........................................................................................81
5.3.5 Dynamic CASPER .....................................................................................86
5.3.6 Complexity Analysis ..................................................................................89
5.4 Results ............................................................................................................... 90
5.4.1 SoCal Fire Setup ........................................................................................90
5.4.2 DSPT Implementation ...............................................................................93
5.4.3 Selfless Routing .........................................................................................95
5.4.4 Iterative Design ..........................................................................................96
5.4.5 Dynamic Environment ...............................................................................97
5.5 Conclusions ..................................................................................................... 100
Chapter 6: Conclusions ................................................................................................... 101
6.1 Summary ......................................................................................................... 101
6.2 Future Work .................................................................................................... 102
References ....................................................................................................................... 104
ix
LIST OF TABLES
Page
Table 1.1: Summary of symbols 7
Table 4.1: Performance and memory consumption under different scenarios 62
Table 5.1: Summary of symbols 74
Table 5.2: All wildfire evacuation scenarios along with the selected population,
shelters, and dynamic changes 93
Table 5.3: Running time and evacuation improvement for different SPT
implementations 94
Table 5.4: Running time and evacuation improvement for two different routing
objective functions 95
Table 5.5: Summary of running time and evacuation improvement for all five
different static CASPER implementations 97
Table 5.6: Running time and evacuation improvement for all four different
DCASPER implementations 98
x
LIST OF FIGURES
Page
Figure 1.1: Southern California population map with elevation 3
Figure 1.2: Two graphs representing shortest and balanced paths 4
Figure 1.3: A graph representing a routing problem 7
Figure 2.1: Evacuation problem taxonomy. The bigger evacuation problem is
composed of smaller sub-problems. Addressing each question requires
attending to other related questions. 10
Figure 2.2: Classes of evacuation routing solutions 14
Figure 3.1: Graph data structure 30
Figure 3.2: How A* (b) and landmark search (c) can improve the search
compared to Dijkstra (a) 31
Figure 3.3: A nearest node sample search. The red dot is the input query and the
brown line is the distance added to the search result 33
Figure 3.4: Processing times for short queries as a function of distance traveled 35
Figure 3.5: Processing time for longer queries as a function of distance traveled 35
Figure 3.6: Correctness of our results (blue line) compared to the results obtained
with Google Maps and MapQuest (pink line) 36
Figure 3.7: Differential error of our results compared with the Google Maps and
MapQuest results. Positive error means we found a shorter path 36
Figure 4.1: A graph with three source points and their evacuation paths 41
Figure 4.2: Plot of selected traffic models 43
Figure 4.3: The curve fitting process for a road segment with one lane of travel 46
Figure 4.4: USC campus with one of the evacuation scenarios 55
Figure 4.5: Traffic model comparison with simulation on USC campus 55
Figure 4.6: Map of Southern California highways 57
xi
Figure 4.7: Urban population evacuated at three different stages by hour. Each bar
shows the percentage of population rescued in the time shown. 59
Figure 4.8: A sample of evacuation routes for scenario S3-CASPER-Power. The
map shows Santa Monica city in California. 60
Figure 4.9: Evacuation times as a function of source interval 64
Figure 5.1: Map of historical wildfires in southern California with major roads 68
Figure 5.2: Static CASPER architecture. This diagram demonstrates the major
steps of the CASPER routing process. 75
Figure 5.3: Dynamic CASPER architecture. This diagram demonstrates how a
modular design improved the original CASPER algorithm in order to solve
the dynamic evacuation routing problem. 87
Figure 5.4: Map of southern California with realistic wildfire evacuation zones 92
xii
ABSTRACT
In the face of a natural or man-made disaster, evacuation planning refers to the process of
reallocating the endangered population to a set of safe places, often in a hurry. Such a task
needs proper preparation, execution, and most definitely a post-disaster response. We have
contributed a new taxonomy of the evacuation planning problem and categorized available
solutions. Evacuation routing is part of the bigger problem that finds the best routes to
relocate the endangered population to safety. Given circumstances, even the tiniest
improvement in evacuation routing during execution can save many lives. Therefore,
different research communities are looking at this particular problem from their own
viewpoints hoping to design a better practical solution.
We propose a new method to perform evacuation routing efficiently under capacity
constraints. Traditionally, simulation software or shortest path routing combined with
zonal scheduling have been used to solve routing problems. Our method utilizes a state-of-
the-art algorithm to connect each source node to its nearest destination. It also intelligently
takes into account transportation network capacity and traffic flow to minimize congestion
and system-wide transportation times. We have compared our method with previous
routing algorithms and a common simulation method in a static environment. We show
that our algorithm generates reliable and realistic routes and decreases transportation time
by at least an order of magnitude, without any loss of performance.
We also define the dynamic evacuation routing problem and propose a solution.
The dynamic solution is capable of updating routes if the network topology is changed
during the evacuation process. Effectively, it can solve the evacuation problem for a
xiii
moving disaster. We argue that an ideal evacuation routing algorithm should be able to
generate realistic and efficient routes in a dynamic environment because changes to the
road network are likely to happen after natural disasters. For example if a main road is
blocked during a flood, the evacuation routing algorithm updates the plan based on this
change in the road network and pushes the changed routes to the corresponding evacuees.
In this dissertation we discuss evacuation routing and how it is connected to
different aspects of the evacuation planning problem. Major works in this field have been
studied and a better algorithm has been developed. The new algorithm’s performance and
running time is iteratively improved and reported along with a comparison with previous
works. The algorithm is extended to also solve the problem in a dynamic environment.
Together these new developments pave the path for future researchers to study the
evacuation problem and to integrate it into urban transportation services. Hopefully one
day we can save more lives than before when future disasters occur.
1
CHAPTER 1: INTRODUCTION
1.1 Overview
Multi-source, constrained routing is important to urban transportation decision systems,
because the transportation challenges and possible solutions may vary from one day to the
next. The best we can do is to route one person at a time providing individuals with
historical traffic data so that they can calculate the fastest path to their destination.
However, there are certain scenarios where we know the source and destination and more
efficient routing is demanded. Take, for example, a sporting event. We know that a certain
number of people will be driving toward the stadium at a given time from multiple
directions. The same applies in cases of freeway construction since those driving on the
freeway would need a detour around the construction. Similarly, for some urban
evacuations, we know everyone is going to drive from their residences to the nearest
shelter. In each of these scenarios, the outcome will be chaotic if we do not consider
network bottlenecks in route calculations.
Despite the importance of the aforementioned urban transportation challenges, the
solutions proposed thus far are either inefficient or inappropriate. In this dissertation, we
present a new, intelligent algorithm for capacity-aware routing. The new approach
generates routes for every traveler whilst minimizing traffic congestion. The produced
routes have total travel times that are at least an order of magnitude better than any previous
work. The traffic model is no longer hard-coded into the algorithm but an input to the
system and as a result, the predicted final travel times are more realistic. The algorithm
2
also scales to large areas with limited memory, so that a user can perform routing on a
larger network with potentially larger throughput.
1.2 Motivation
On 11
th
March, 2011, the Tohoku earthquake and tsunami occurred off the coast of Japan.
Shortly afterwards, the Pacific Tsunami Warning Center in Hawaii issued a tsunami
warning for the entire Pacific Ocean. The Alaska and West Coast centers also issued
tsunami warnings for coastal areas of Alaska, California, and Oregon. Approximately
11,000 people were evacuated from coastal areas in the Kuril Islands (Russia). The related
tsunami reached the California shoreline in less than a day and given different
circumstances, the tsunami may have required evacuation of residential areas.
However, urban transportation networks are not designed to handle sudden
increases in traffic flows. Given an imminent tsunami threat, many people may want to
travel from their residences to one or more designated safe areas. For example, there are
1.2 million people living less than 20 m above mean sea level in Los Angeles and Ventura
counties (Figure 1.1). Without an evacuation plan, many evacuees will pick the same paths
and will most probably bring traffic flows to a standstill. The CASPER (Capacity-Aware
Shortest Path Evacuation Routing) system can help to avoid such an outcome. The
algorithm at the core of this system combines the road capacity with its length to predict
speeds under different traffic conditions. One can think of the road capacity as the number
of lanes. CASPER takes a traffic model with two parameters – the road segment capacity
and traffic flow – as input. The function is going to return a new speed estimate for the
road segment, which then affects the path finding process. The algorithm keeps these new
3
speed estimates up-to-date and iteratively generates routes specific to each evacuee to
minimize global evacuation time.
Figure 1.1: Southern California population map with elevation
CASPER also differentiates between population size and density or flow to
generate evacuation routes. Traditionally the number of people at one location would be
treated as the source flow. While this is a good approximation, it does not need to be
embedded in the routing algorithm. For example, take Hurricane Sandy and the evacuation
of New York City. Since this is a densely populated area, the transportation network does
not have the capacity for everyone to evacuate simultaneously and as a consequence, each
zone was scheduled to evacuate during an allocated time (Saul 2012). In other words, by
reducing the source population, the density was lowered to relieve the network bottleneck.
Another method is to have all zones evacuate at the same time but enforce a time delay
between each vehicle in each zone. Due to this metered but continuous traffic flow, the
overall source flow to the network is lowered without reducing the source population. This
same idea is implemented every day on freeway ramps (Papageorgiou and Kotsialos 2002).
4
We argue that through careful implementation of these traffic modeling and
metered source flow concepts, CASPER can route everyone to safety whilst minimizing
global evacuation time and eliminating the need to schedule evacuation times. Figure 1.2
visualizes how these two concepts can improve evacuation routing. The graphs present two
sources which need to travel to a single destination (left to right). Distance between dots
represents density. The left-hand graph has two non-metered and overlapping paths
whereas the right-hand graph has metered and non-overlapping paths to reduce congestion.
Figure 1.2: Two graphs representing shortest and balanced paths
1.3 Problem Definition
This section formally defines the static evacuation routing problem. For now we ignore
any changes in the environment. We model the problem as a graph path finding problem.
The common approach to model a transportation network as a digraph is to have one graph
vertex for every road intersection and a graph edge for every road segment. A better
approach is to have one vertex for every road segment and an edge for every possible
unrestricted turn between two road segments (Boroujerdi and Uhlmann 1998). This would
enable us to model turn restrictions without changing the path-finding algorithm. For the
purpose of this dissertation, it does not matter how the graph is built. We assume the graph
is accessible in constant time. In addition, without loss of generality, we assume there is
5
only one destination node in the graph. The case with multiple destination nodes can be
reduced to the single-destination case by introducing an artificial super node and
connecting it to all actual destination nodes with zero-cost edges. This reduction does not
preserve planarity.
The problem has four inputs: the graph, the traffic model, the source flows, and the
destination. The output is a set of paths for each source point. The directed graph G(E,V)
represents the transportation network with |E| edges and |V| vertices (E ⊂ V
2
). Each edge e
has non-negative impedance (imp) and capacity (cap). For example, the impedance could
be the length of the road segment and the capacity could be the number of lanes. The set S
contains all the vertices for the source population (i.e. the evacuees). The vertex 𝑡 ∈ 𝑉 is
the destination for all of the source population (i.e. the safe area(s)). Each source point s
has a positive non-zero weight w(s) (Eq. 1.1). For example a source point could be a
neighborhood, a residential building, or a Census block on the map. The weight is the
population at that point.
Eq. 1.1
∀𝑒 ∈ 𝐸 𝑖𝑚𝑝 (𝑒 ) ≥ 0, 𝑐𝑎𝑝 (𝑒 ) ≥ 0
∀𝑠 ∈ 𝑆 , 𝑆 ⊂ 𝑉 𝑤 (𝑠 ) > 0
As was discussed earlier, each source point s is metered and hence will generate a
different density on each edge. For example, let us assume cars are leaving a neighborhood
at 30 sec intervals. So we have int(s) = 30. Eq. 1.2 computes the density from a source
point on an edge. For example, let us assume edge e is 10 min in length and source s has
100 cars: imp(e) = 10 minutes, w(s) = 100. Without any metering (zero interval), the
density on edge e equals the population: den(s,e) = 100. However, with 30 sec metering,
6
the density reduces to the number of cars that can actually fit on that edge: den(s,e) = 600
/ 30 = 20.
Eq. 1.2
𝑑𝑒𝑛 (𝑠 , 𝑒 )= 𝑚𝑖𝑛 (
𝑖𝑚𝑝 (𝑒 )
𝑖𝑛𝑡 (𝑠 )
, 𝑤 (𝑠 ))
We assume there would be only one path P s for each source point s. We make this
assumption not to simplify the problem but because it is unrealistic. If the population at a
source point was separable, it would have meant people living in the same neighborhood
would take different routes to safety. This makes evacuation routing more difficult to
control. If evacuees at a source point are indeed separable, we can simply split the source
point into two. A path P s is an ordered set of edges that will guide all the population at s to
safety (t). Therefore, the total density on edge e is the sum of all densities from all paths
that pass through e (Eq. 1.3).
Eq. 1.3
∀𝑠 ∈ 𝑆 , 𝑃 𝑠 ∈ 𝓟 , 𝑃 𝑠 ⊂ 𝐸 , 𝑑𝑒𝑛 (𝑒 ) = ∑ 𝑑𝑒𝑛 (𝑠 , 𝑒 )
𝑠 , 𝑒 ∈ 𝑃 𝑠
We define the traffic model as a function with two parameters 𝒯 (d,c) (Eq. 1.4). This
function predicts the edge congestion based on edge capacity and total density. Finally, the
cost of traversing an edge can be calculated (Eq. 1.5). From there, the cost of traversing a
path follows. The first term in the path cost formula (Eq. 1.6) calculates the delay imposed
by the source metering and the second term sums the cost of the path itself. The objective
is to minimize the cost of the costliest path (Eq. 1.7). Table 1.1 summarizes all of the other
symbols that we use in this dissertation.
Eq. 1.4 ∀𝑑 , 𝑐 ∈ ℝ
+
𝒯 (𝑑 , 𝑐 ) ∈ (0,1], 𝒯 (0, 𝑐 ) = 1,
𝜕 𝜕𝑑
𝒯 (𝑑 , 𝑐 ) ≤ 0,
𝜕 𝜕 𝑐 𝒯 (𝑑 , 𝑐 ) ≥ 0
7
Eq. 1.5
𝑐𝑜𝑠𝑡 𝒯 (𝑒 ) =
𝑖𝑚𝑝 (𝑒 )
𝒯 (𝑑𝑒𝑛 (𝑒 ), 𝑐𝑎𝑝 (𝑒 ))
Eq. 1.6
𝑐𝑜𝑠𝑡 𝒯 (𝑃 𝑠 ) = 𝑖𝑛𝑡 (𝑠 ) × 𝑤 (𝑠 ) + ∑ 𝑐𝑜𝑠𝑡 𝒯 (𝑒 )
𝑒 ∈ 𝑃 𝑠
Eq. 1.7
𝐸𝑣𝑐𝑇𝑖𝑚𝑒 = 𝑚𝑎𝑥 { 𝑐𝑜𝑠𝑡 𝒯 (𝑃 𝑠 ) | 𝑃 𝑠 ∈ 𝓟 }, Objective: minimize EvcTime
Table 1.1: Summary of symbols
Symbol Description
Vi ⊂ V Visited vertices set
Di ⊂ V Dirty vertices set
g(v) ∊ ℝ
+
Cost from source to vertex v
h(v) ∊ ℝ
+
h value of vertex v. h value is a lower bound of the cost to destination.
S’ The set of unprocessed source points
s_min The unprocessed source point with the lowest weight (population)
Consider the graph from Figure 1.3. It has one destination node and three source
nodes. Edges are labeled by their impedance. If two paths share an edge, they are going to
affect each other’s traversal cost. In other words, the evacuation time will increase because
of the congestion on the shared edge. The problem is to find paths for each source point
whilst minimizing congestion.
Figure 1.3: A graph representing a routing problem
8
1.4 Thesis Statement
I propose to address the lack of a scalable evacuation system that can generate evacuation
routes for the endangered population in any emergency scenario, maintains the traffic
congestion at a minimum, and dynamically adjusts to changes in the road network.
1.5 Contribution
In this dissertation we examine solutions to the urban routing problem. Below we
summarize the contributions of the static and dynamic evacuation routing solution:
We generalize the evacuation routing solution to work with any traffic model
so long as it satisfies the said conditions (Eq. 1.4).
We utilize a simulation to measure how realistic the predicted travel times are.
We develop a heuristic to improve performance of the graph path finding
algorithm without pre-computing the network. Therefore, our solution
generates realistic routes for large areas in reasonable time.
We develop an iterative approach to improve the quality of evacuation routes.
We formulate the dynamic evacuation problem and develop two different
approaches to detect road changes and quickly update the affected evacuation
routes in a timely manner.
The final goal of this dissertation is to enable urban-scale dynamic evacuation routing. The
system should scale to large urban areas with high resolution population data. It also has
to be dynamic which means it should enable the emergency personnel to adjust the
evacuation routes for sudden changes in the road network. Some examples of road network
change are road blockage or destruction, new road discovery, contraflow lane reversal, and
9
speed limit change. A dynamic system should be able to create detours or suggest new
routes for the affected population using previously calculated routes.
1.6 Outline of Dissertation
The remainder of this dissertation is organized as follows. Chapter 2 provides a general
overview of the evacuation planning problem and its major concerns. It also reviews related
work on evacuation routing. Chapter 3 briefly covers the necessary background on shortest
path routing with one particular application. Chapter 4 investigates the solution to the static
evacuation routing problem. It addresses the problem stated in Section 1.3. It includes the
essential background followed by complexity analysis and the experimental results.
Chapter 5 is primarily focused on solving the dynamic evacuation routing problem. It
extends the currently defined evacuation routing problem and formulates it to include the
environmental changes. It provides two solutions for evacuation in a dynamic environment
and also describes a few other improvements. Chapter 6 concludes the dissertation and
provides some suggestions for future work for the interested researcher.
10
CHAPTER 2: RELATED WORK
2.1 Evacuation Taxonomy
We propose that the overall evacuation planning problem be divided into three steps:
preparation, evacuation execution, and post-disaster response. In this section we briefly
review these evacuation sub-problems. Each sub-problem incorporates several concerns.
We believe some of these concerns are connected with one another and cannot be answered
in isolation. A detailed problem taxonomy is presented in Figure 2.1. The colored boxes
visualize these dependencies. It is worth mentioning that a similar study has suggested a
different evacuation problem decomposition into four stages: mitigation, preparedness,
response, and recovery (Cova 1999).
Figure 2.1: Evacuation problem taxonomy. The bigger evacuation problem is composed of
smaller sub-problems. Addressing each question requires attending to other related questions.
11
Preparation refers to the time before the incident actually happens. Since the
nature of the disaster is not known at this stage, solutions to this sub-problem are less about
the execution details and more focused on the surrounding geography. For example,
Church and Cova presented a model to detect overpopulated neighborhoods that might face
traffic congestion during an evacuation (Church and Cova 2000). Also Cova et al.
presented a fire spreading model in order to discuss the community evacuation triggers
(Cova et al. 2005). Given the estimated evacuation time, wind, and the fuel type, they
calculated a border around a residential area such that if the fire passed the border, the area
needs to be evacuated. Evacuation execution refers to what needs to be done from the
moment we learned about the disaster up until the time at which all of the potentially
affected population is secured in a safe area. At this stage the location and time of the
disaster is the key information. Without them, there is no noticeable distinction between an
evacuation plan and daily traffic modeling. Post-disaster response is the stage where
emergency personnel care for the affected population, maintain shelters, and assess the
damage. For example, Lue et al. studied disaster damage assessment using geo-tagged
videos taken from affected areas (Lue, Wilson, and Curtis 2014). They showed that the
damage assessment can be conducted both by expert assessors or inexperienced citizens to
get preliminary results.
As mentioned, the evacuation execution stage starts once we learn about the nature
of the disaster. Disasters can be static or dynamic. Dynamic disasters are those with
changing behavior, location, or severity. Disasters like tsunamis or terrorist attacks are
considered static while hurricanes, wildfires, and floods are dynamic. Evidently, planning
12
for a dynamic disaster would add to the complexity and has to be considered in a realistic
evacuation solution.
Once we learn about the disaster and identify the affected areas, it is possible to
locate the endangered population. The evacuees may include residents who leave
voluntarily and/or some who are forcefully evacuated. The remainder are going to shelter
in place. For example, during Hurricane Irene, August 2011, “[New York] city officials
issued what they called an unprecedented order for the evacuation of about 370,000
residents of low-lying areas, warning that Hurricane Irene was such a threat that people
living there simply had to get out” (Barron 2011). The evacuees’ distribution can come
from a variety of sources. In the United States, high resolution population data is available
through the U.S. Census Bureau (Census Bureau 2010). However, this reports only
residential population and would not reflect population distribution during the day.
Moreover, it will not give us information about tourists. Kobayashi et al. presented a
dynamic population model to improve and visualize diurnal population density based on
public transport data (Kobayashi, Medina, and Cova 2011). Also with the increasing
availability of GPS-enabled smart phones and smart cars, it is now possible to locate
evacuees more efficiently.
The evacuation routing problem is about directing the evacuees toward safe
destinations such as hotels and shelters. The objective is usually to minimize exposure,
evacuation time, average travel time, or traffic congestion. A good routing solution should
consider the transportation network characteristics, available transportation vehicles, and
the capacity of one or more potential destinations. All these dependencies on former sub-
13
problems puts the routing problem at the center of the evacuation problem. Therefore it is
important for routing solutions to closely work with other pieces of the puzzle. For
example, the Capacity Constrained Route Planner (CCRP) algorithm is a realistic
evacuation routing solution that considers road capacity and population density (Lu,
George, and Shekhar 2005; Shekhar et al. 2012). It also performs routing and scheduling
simultaneously in order to improve the evacuation time. In another work by Pourrahmani
et al., evacuees are transported to long-term shelters in multiple stages using public
transportation (Pourrahmani et al. 2015). At each time interval an OD matrix is generated
from all interesting points. Then a simulated annealing (SA) heuristic is used to solve the
vehicle routing problem (VRP) at each stage. Having a routing solution in hand, the next
question is the enforceability and traffic management during evacuation. To the best of
our knowledge, the enforceability of evacuation routes has not been discussed in the
literature. However, traffic modeling and congestion estimation have been studied (Smith
1991; Smith and Cruz 2005; Greenberg 1959; Malone, Miller, and Neill 2001).
2.2 State-of-the-art Evacuation Routing
To the best of our knowledge, research on urban evacuation problems is about three
decades old. Some of the earliest studies sought to estimate the network clearance times
for people living close to nuclear power plants (Sheffi, Mahmassani, and Powell 1982).
The MASSVAC software was later proposed and used for simulating urban disaster
evacuations (Hobeika and Jamei 1985). The problem was simply to predict traffic
conditions during evacuations given a certain population density and network topology in
14
these early works. Today, we are interested in a broader range of research topics, including
evacuation routing optimality, applicability, and scalability.
The existing evacuation routing methods can be divided into descriptive and
prescriptive methods (Figure 2.2). Of course not all research works would fit into this
schema. For example, Cova (Cova 1999) showed how GIS can be utilized to help gather
data from different sources, visualize emergency situations, and execute response plans
without taking any specific descriptive or prescriptive approach.
Figure 2.2: Classes of evacuation routing solutions
Descriptive methods are solutions that visually simulate a given emergency
situation. The goal is to mimic reality as closely as possible. Flow-based simulation, agent-
based modeling, cellular automata modeling, and activity-based modeling are some of the
methods which would fall into this category (Santos and Aguirre 2004). In contrast,
prescriptive methods determine the optimal evacuation routing strategies to achieve some
15
evacuation goal without necessarily performing a fine-scale simulation (Chiu et al. 2007).
CASPER is an example of a prescriptive solution.
2.2.1 Descriptive Methods
The primary goal of descriptive methods is to visualize what could happen as realistically
as possible. These visualizations along with the accompanying statistics provide valuable
insights. For example, Cova and Johnson (Cova and Johnson 2002) utilized the Paramics™
software package, an advanced off-the-shelf urban simulation software, to perform micro-
simulation of evacuation during wildfire in Salt Lake City, Utah. They showed how a sharp
increase in the rate of vehicles leaving residential areas can cause serious traffic congestion
and thereby lower evacuation times. Similarly, Jha et al. (Jha, Moore, and Pashaie 2004)
presented a new microscopic simulation model for their geographical area of interest in
order to visualize traffic conditions and, to some extent, minimize evacuation times. Chen
et al. (Chen, Meaker, and Zhan 2006) presented an agent-based model in which the end-
user can introduce road blockages in order to study their effect on city evacuation times.
While these simulation case studies can benefit the local community, their results are not
immediately applicable to other cities because their hypotheses are tied to local geography.
Further, many of these solutions are not scalable to city-sized problems because of their
computational complexity. All of the aforementioned descriptive solutions are only locally
applicable.
2.2.2 Prescriptive Methods
Prescriptive solutions focus on providing an evacuation plan as opposed to visualizing a
plan. These methods typically utilize mathematical techniques to collect data and suggest
16
routes and/or schedules. The objective is to minimize evacuation time, lower traffic
congestion, and/or lower exposure to danger. Naturally, these solutions are less dependent
on the geography and usually are more scalable. In order to further study previous
evacuation routing methods, we have categorized them into two groups: optimal and
heuristic methods.
Optimal Methods
Optimal solutions are polynomial-time algorithms that come with a mathematical proof of
optimality and completeness. Hoppe and Tardos, for example, reviewed several evacuation
routing problems and provided optimal solutions (Hoppe and Tardos 1994). Most were
network flow problems. Some of the algorithms presented in Hamacher and Tjandra are in
fact optimal as well (Hamacher and Tjandra 2002). The main characteristic of these
algorithms is that they are mostly based on the max-flow/min-cut theorem. Therefore they
have the Ford–Fulkerson algorithm (Ford and Fulkerson 1962) embedded in their design.
Among various challenges, these flow-based algorithms usually suffer from scalability as
well as applicability issues, as noted below:
Flow is a continuous phenomenon whereas evacuees are a set of finite, slow-
moving, and discreet objects. In other words, an evacuee occupies a finite space
at a given time while a flow occupies the entire route at any given time. This
issue will get magnified when the evacuation time is substantially larger than
the traversal time along a single edge.
Evacuees can be scheduled but a flow cannot be stopped, delayed, or scheduled.
17
It is difficult to incorporate transportation network turn restrictions into flow-
based graph algorithms.
Another group of optimal solutions rely on linear programming (LP) which provides a
general purpose mathematical method for optimization under linear constraints. Several
LP-based optimal evacuation solutions with different objectives and implementations have
been proposed (Chiu 2004; Jarvis and Ratliff 1982). These solutions are only feasible for
small-scale scenarios like building evacuations. On the other hand, the work by Stepanov
& Smith (Stepanov and Smith 2009) is an LP-based urban evacuation routing algorithm
with non-linear traffic consideration. They have designed a three-step process. First, they
generate k
th
shortest paths from every evacuee point to every safe area. Then, they evaluate
the quality of every path using a selected traffic model. Finally, they formulate the
evacuation problem as an integer linear program (ILP). The ILP formulation will consider
the non-linear effect of every evacuee’s path on others and then computes optimum
evacuation routes. The same group previously studied both linear and non-linear analytical
traffic models (Smith 1991; Smith and Cruz 2005) and has used them in their urban
evacuation algorithm. Due to the computational complexity of the algorithm, the
experiments were performed on a graph with 11 nodes. Generally speaking, LP-based
evacuation algorithms have massive computational costs which make them inapplicable to
real-world urban transportation problems.
Evolutionary computing is a general-purpose optimization model inspired by
nature and it can solve complex engineering problems. Multi-agent approaches are a
general way to model these systems. Optimizing a multi-agent system is difficult due to
18
the nonlinear behavior of the input parameters and the environment. Humann et al. showed
how genetic algorithm (GA) can be used to optimize a self-organizing system (Humann,
Khani, and Jin 2014). They proposed a two-field based model to characterize agents’
behavior. The optimized state of the system emerges as the result of agents’ interaction
with these fields. GA is an effective algorithm for optimization and can also be used for
evacuation planning. However it is difficult to scale it to large geographical areas.
Saadatseresht et al. (Saadatseresht, Mansourian, and Taleai 2009) proposed the
only evacuation LP formulation that was solved with a sub-optimal solver. The authors
employed a Pareto front-based, multi-objective evolutionary AI (Artificial Intelligence)
algorithm to generate sub-optimal routes and therefore offer better scalability comparing
to other LP-based evacuation routing algorithms. The graph size in their experiment is an
order of magnitude larger than similar works. However, there is neither an optimality nor
approximation guarantee and at best, the solution can only be applied to an urban area of a
few square kilometers. Similarly, Fang et al. (Fang et al. 2011; Q. Li et al. 2010) presented
another GA solution and provided experimental results for the Wuhan Sports Center
stadium.
Heuristic Methods
Perhaps, not surprisingly, a variety of heuristic methods have been proposed. The method
presented in Uno and Kashiyama (Uno and Kashiyama 2008) utilized a simple shortest
path algorithm with a constant edge cost to assign evacuation routes to evacuees. This is
perhaps the most basic route assignment one can implement besides a random walk. They
simulated an urban evacuation scenario for experimental and visualization purposes in a
19
3D environment. The intended contribution of the article is to visualize and measure
casualties in a river flood scenario. However, to the best of our knowledge, this is the only
article that combines descriptive and prescriptive approaches. In section 4.1.3 we discuss
how we mixed the two approaches to evaluate CASPER routes.
Lim et al. recently introduced a new algorithm based on the idea of time-aggregated
graphs (TAGs) (Lim et al. 2009). Whilst their experiments are focused on hurricane
evacuation, the implementation is more general. Their algorithm builds a special multi-
layer graph from the transportation network and then suggests routes and delay schedules
for evacuees while constraining road segments to their capacities. The path finding process
is based on the Dijkstra algorithm (Dijkstra 1959). They compared their results to an
optimal LP-based solution on nine small graphs (less than 100 nodes) and showed that their
greedy approach is at least two orders of magnitude faster and still capable of evacuating
all the endangered population.
The Capacity Constrained Route Planner (CCRP) algorithm (Lu, George, and
Shekhar 2005) is perhaps the most realistic prescriptive solution to urban evacuation
routing. The initial implementation is a greedy approach which intelligently assigns routes
to each evacuee while constraining road segments and intersections to their capacities.
Later, they introduced two heuristics to improve the performance and scalability of their
algorithm (Kim, George, and Shekhar 2007). They provided comparisons with LP-based
solutions and presented experimental results with real urban data. A recent study suggested
a small change to the CCRP sorting to improve optimality (Zeng and Wang 2009). Overall,
20
this is a great scalable near-optimal prescriptive package that is addressing the bigger urban
evacuation problem. The following pseudo-code summarizes the original CCRP algorithm.
Algorithm 2.1. CCRP (w/o scheduling)
𝓟 ← 𝜙
∀s ∈ S, w(s)>0 do {
1. route P s ← ShortestPath(G, s, t)
2. if P s = 𝜙 then continue to next s
3. cap(P s) ← min { cap(e) | e ∈ P s }
4. route_pop ← min { cap(P s), w(s) }
5. ∀ e ∈ P s do {
5.1. cap(e) ← cap(e) - route_pop
5.2. if cap(e) ≤0 then E ← E - {e}
}
6. 𝓟 ← 𝓟 ∪ {P s}
}
return all routes 𝓟
The CCRP algorithm loops over all evacuee source points. For each source point,
it finds the shortest path to the safe point t (line 1). Theoretically, any path finding
algorithm will work for the ShortestPath function, although the Dijkstra algorithm was
implemented here. The CCRP algorithm then determines how much of the population at
point s can flow through this path (lines 3, 4). It is guaranteed that route_pop is always
greater than zero if a path exists from s to t on graph G. At line 5, the edge capacities are
reduced by route_pop and this step ensures that the paths are not going to overload the
edges beyond their capacities. CCRP also adjusts the vertex capacity based on route_pop
but since we do not consider vertex capacity in this dissertation, algorithm 2.1 does not list
this step. We have decided not to assume cost and capacity for vertices because they do not
21
have a real-world meaning. Any cost or delay in a transportation network can be modeled
as the graph edge cost and capacity.
The same research team later introduced two new heuristics to improve CCRP
performance and scheduling (Kim, George, and Shekhar 2007). The first is the Intelligent
Load Reduction (ILR) heuristic. In this process, the algorithm gets an early warning of
graph saturation which eventually helps CCRP to perform better and also generate a shorter
evacuation plan. Graph saturation occurs when there are no more edges from any source to
the destination which means the remainder of the evacuees will have to wait until the
network opens up. ILR estimates this wait time and schedules the remainder of the source
population to start evacuating once the first round of evacuees reaches their destination(s).
Since our evacuation routing problem is more generalized, this phenomenon may or may
not happen depending on the traffic modeling and initial delay functions (𝒯 , int). The
second Incremental Data Structure (IDS) heuristic improves the path finding process within
CCRP. Instead of re-creating the Dijkstra tree from scratch for every source point, the
individual Dijkstra runs re-use the same heap data structure and only extend it for the next
source point to the destination. This improves performance without affecting CCRP
completeness.
We have briefly explained past work in the field of evacuation routing. As
discussed earlier, the introduced general evacuation routing problem cannot be solved
directly by any of the previous algorithms, including CCRP. Before we present our
solution, we need to cover some background about general shortest path calculation on a
transportation network.
22
CHAPTER 3: SHORTEST PATH ROUTING
3.1 Introduction
Thus far we have introduced the urban evacuation routing problem and presented the state-
of-the-art prescriptive methods accordingly. This chapter briefly explains general routing
in transportation networks with one source point and one destination point. We propose a
robust implementation of the shortest path search on road network data. We design a
compressed multi-layer graph and then perform fast in-memory shortest path search on the
entire U.S. and Canadian road networks. Our system loads the graph at the beginning and
then it can answer any one-to-one shortest (distance, time, or both) path query without any
pre-computation. It also takes into account driving maneuver restrictions and supports
loading graphs from different years. Experimental results of performance and accuracy are
provided.
Geographic information system applications and location-based services have been
gaining importance in recent years and different use-cases are constantly emerging. The
vehicle routing problem, which is basically a shortest path search on a road network, is one
of the enduring challenges. Calculating travel cost along roads helps with the accurate
estimation of distances in real-world scenarios. This will directly affect any GIS-related
application that deals with navigation on roads.
Calculating the shortest path is a well-known problem in computer science and has
been extensively studied. Theoretically, shortest paths might be considered a solved
problem. However, further work is still needed in order to improve its performance,
robustness, and scalability. In this chapter we propose a robust open source implementation
23
of the shortest path search on road network data as a research tool for health scientists. By
utilizing a compressed multi-layer graph data structure, we can support fast in-memory A*
(Hart, Nilsson, and Raphael 1968) search on the entire U.S. and Canadian road network.
Our design also takes into account turn restrictions and supports graphs from different
years.
In the remainder of this chapter, the problem is precisely defined and the key
motivations and contributions are summarized. Then related works on shortest path are
covered. We describe our approach in detail and present results testing and validating our
approach.
3.1.1 Problem Definition
The main challenge is to calculate shortest and fastest paths (without traffic congestion
considerations) on road networks at the scale of a continent in an open source framework.
The system should work independently of any external resource. The process not only
needs to be computationally fast, but it has to be robust, easy to use, and also as accurate
as possible. The design specifications included the capability of handling 100,000 queries
a day.
For measuring performance, some researchers in theoretical fields usually refer to
the time and space complexity of the algorithms as the primary measure which usually
translated to the number of visited nodes or the magnitude of the visited and swiped area.
Since we are implementing well-known algorithms in our system, we simply measured our
performance based on the average query processing time from beginning to end. This
makes more sense because we are building an end-to-end system to process shortest path
24
queries in batch mode for the end user. Therefore, average process time per query matters
more than the theoretical complexity of the worst case scenario.
3.1.2 Motivation
Imagine a breast cancer patient’s regular visit to a nearby cancer registry in a given year.
How much would the traveled distance and/or time affect the quality of treatment and how
can it be improved in the future? This is the main motivation of the design of our system.
Since there are many gigabytes of recorded data, the said system would need to be highly
scalable. In addition, accuracy and early error detection of the calculated results were other
key motivations for this project. Since the completion of our project, the system has been
used in the said cancer research study (Boscoe et al. 2011) as well as in other ongoing
health science studies.
3.1.3 Contribution
The main contribution of this chapter can be summarized as reviewing well-known recent
shortest path algorithms and choosing and adapting one in order to satisfy the main
requirement. We decided to implement the A* search empowered by a compressed
memory-resident graph to achieve the best performance.
3.2 Related Work
Following the in-depth evaluation of traditional shortest path algorithms by Zhan and Noon
in 1998 (Zhan and Noon 1998), researchers started looking at the problem more seriously
and applied different informed heuristics, typical road network knowledge, and pre-
computation to improve the available shortest path searching algorithms. The most recent
and successful proposals and experiments are presented.
25
3.2.1 Landmark Search
Based on the correctness proof given for A* in the Artificial Intelligence (AI) literature, a
larger heuristic value will result to less node extraction and hence better performance so
long as the heuristic does not over-estimate the actual cost. Since we are dealing with
topological graphs, using the triangle of inequality, Goldberg and Harrelson (Goldberg and
Harrelson 2005) proved that with a given set of landmarks one can find a better heuristic
than Euclidean distance. They also presented a list of algorithms to locate landmark nodes.
As part of their pre-computation, they had to calculate the distances to each
landmark from each neighborhood node. The pre-computed data needs to be sufficiently
populated such that for every node in every search, there exists a landmark offering a better
(i.e. larger) heuristic compared to the node’s default cost value from Dijkstra (Dijkstra
1959). This disk-based algorithm is indeed fast and it was easy to implement but has a large
space complexity.
3.2.2 Incremental Heuristic
This idea which was almost applicable to our case, suggested that calculated shortest paths
from previous searches, if cached and indexed correctly, can be used as a heuristic for
future search queries with similar source and/or destination nodes. Koenig et al. (Koenig
et al. 2004; Sun et al. 2012) went beyond similar search protocols and introduced moving
target shortest path problems which in theory are just a series of planning problems with
similar start or end points. They mainly focused on the generality and theoretical aspects
of their approach, but they do report limited, small-scale experimental results.
26
3.2.3 Road Knowledge
This group of papers takes advantage of the fact that people usually do not optimally
calculate shortest paths while driving. They instead divide the problem into smaller steps
in order to get to the destination. The insights gathered from this approach can lead to
several improvements:
While processing shortest paths, the solution is likely to take highway edges
and confidently ignore local roads since highways are built to improve
efficiency (Ertl 1998).
Liu (Liu 1997) discussed a similar idea. A multi-level road network was
introduced with freeways on top and local roads at the bottom. Again the search
is divided into searching and connecting different levels of road network from
source to destination.
Instead of putting road segments into different levels based on road type (i.e.
freeway or local), Uras et al. (Uras, Koenig, and Hernández 2013) designed an
algorithm to identify hierarchies for every graph vertex and then generated a
sub-goal graph. They showed how the generated sub-goal graph can improve
the search performance.
A more recent approach suggested mixing road knowledge with pre-
computation (Lauther 2006). Mimicking the way we follow road signs while
driving, a computer search algorithm can also pre-compute artificial road signs
on road segments in order to speed up the search.
27
3.2.4 Distance Oracle
Samet and his colleagues recently introduced an even faster algorithm for solving the
shortest path problem (Samet, Sankaranarayanan, and Alborzi 2008). Their fundamental
approach has proven time complexity of O(logn) and consists basically of a series of table
lookups on pre-computed quadtrees for each node. In their recent paper, they also reduced
the pre-computation space complexity to O(n) by introducing a series of transit nodes
between connected sub-graphs (Sankaranarayanan and Samet 2009). They argued that
certain transit nodes, which connect many neighbor nodes to each other, can be utilized to
avoid redundant caching of pre-computed data as well as redundant node extraction while
searching.
3.2.5 Real-Time Traffic
So far we have discussed improvements to the running time either by means of pre-
computation or considering the road network hierarchy. Because traffic congestion is of an
interest in this dissertation, discussing previous work in shortest path calculation with
traffic consideration is needed. In the literature, this is sometimes referred to as time-
depended shortest path. A recent book chapter by Demiryurek et al. presented a
bidirectional time-dependent fastest path algorithm (B-TDFP) based on A* search
(Demiryurek et al. 2011). At the pre-computation phase they first partition the road network
into non-overlapping regions. Then they pre-calculate distances of all vertices to border
vertices and vice versa. This distance information will later be used as an admissible
heuristic for the time-dependent A* search. In their experiments they used real traffic data
28
as oppose to empirical traffic models and demonstrated significant improvement over
previous works.
3.3 Approach
In the course of designing and implementing our solution, we divided this project into four
different and loosely-dependent components: (1) graph data structure; (2) search algorithm;
(3) nearest node search; and (4) integration. In the following four subsections, a brief
description along with the challenges and key decisions we made for each component are
presented.
3.3.1 Graph Data Structure
A shortest path search on a road network always starts with road network data. We had the
opportunity to use NAVTEQ street network data (NAVTEQ’s NAVSTREETS Street Data
Reference Manual v2.5 2007) for our research. NAVTEQ comes as a series of tables
describing street attributes, turn restrictions, geometries, etc. Taken as a whole, there was
16 GB of street data spanning the entire US and Canadian road networks. After basic
cleanup, we came up with a 12 GB graph that was ready for the searching algorithm.
Further compressions reduced it to about 5.5 GB excluding the memory required by the
search algorithm.
As for loading the graph, we could either: (1) use spatial paging techniques to load
parts of graph into memory on query time (Shekhar and Liu 1997; Hutchinson,
Maheshwari, and Zeh 2003); or (2) fit the graph entirely in memory and build an all-in-
memory search tool. Paging is a good idea because it is far more memory efficient than the
alternative solution but it also has certain performance drawbacks as it can cause many I/O
29
costs at query processing time. Although an external data structure is a more concrete and
general solution to the graph size problem, the in-memory graph would still outperform
such a solution.
In order to compress the graph into memory, one first needs to understand what is
the minimum data required for a simple searching algorithm to execute. Most searching
algorithms mainly deal with nodes. By definition, a node is where a traveler has more than
one available direction to choose from. This leads us to the fact that nodes are road
intersections and not all possible points along the roads need to be considered. In addition,
any node with only one outgoing edge can be merged with its only neighbor. The curvature
(shape) of edges is also considered irrelevant data during the search. It is only useful if we
want to visualize the results. In a sense, the only important attributes of graph edges are
their weights, which in our case can be compacted in one unsigned integer (4 bytes)
representing the street length and its speed limit. Altogether our graph would be just a big
set (hashtable) of nodes. Each node holds its own coordinates and a list of neighbors
pointing to other nodes. Later we also attached another structure containing turn restrictions
to the aforementioned adjacency list (Figure 3.1).
The final data structure described in Figure 3.1 utilized about 5.5 GB of memory
and was generated from raw data in around five minutes on system startup. In order to
support many searches at a time, we decided to separate search-related attributes (search
algorithm flags and marks) on a different layer hooked to the main static layer. At the end
of each search, its dynamic layer was garbage-collected asynchronously. This layered
30
design gave us the opportunity to try different search algorithms because it abstracted the
road network data.
Figure 3.1: Graph data structure
3.3.2 Search Algorithm
Assuming we have a graph, the problem of finding a path between two nodes while
minimizing the travel cost (either time or distance) is known as the shortest path problem.
In computer science, there are several good greedy algorithms capable of solving this
problem. They mainly differ in ease of implementation, applicability, and of course
performance. Zhan et al. evaluated 15 shortest path algorithms with a variety of real road
networks (Zhan and Noon 1998). We started our own work by implementing Dijkstra
(Dijkstra 1959) for the following reasons:
It is fundamental to many other algorithms.
It can be optimized for one-to-one search and can be used for one-to-many
searches.
It offered better performance when using road network graphs.
Obviously utilizing A* (Hart, Nilsson, and Raphael 1968) makes much more sense in the
case of a road network because it focuses the search toward the destination, resulting to
31
less visited nodes (Figure 3.2). Even though A* has the same time and space complexity
as Dijkstra, in practice it improved the search by at least an order of magnitude.
Figure 3.2: How A* (b) and landmark search (c) can improve the search compared to Dijkstra
(a)
Improving the search beyond A* is only possible through one of the following three
ways: (1) Bi-directional search; (2) Approximation; and (3) Pre-computation. Bi-
directional search (Sint and de Champeaux 1977) offers small improvement but demands
a larger graph in terms of size because it needs the edges to be bi-directional.
Approximation algorithms (Ikeda et al. 1994; Thorup 2004) are not very useful because
our main goal was to design a health science research tool and not a suboptimal human
readable tool. However, utilizing pre-computed distances seemed to offer a good solution.
Numerous papers have been published in recent years about shortest path searches with
pre-computation (Goldberg and Harrelson 2005; Koenig et al. 2004; Ertl 1998; Lauther
2006) and some have lower time complexity compared to that of A* (Samet,
Sankaranarayanan, and Alborzi 2008; Sankaranarayanan and Samet 2009; Bast et al.
2007).
32
We first utilized an incremental A* search on our graph and later we moved to the
Landmark search since it is more concrete. Although it has O(n
2
) space complexity, the
ability to vary the number of landmark nodes made this algorithm initially applicable to
our problem. Figure 3.2 shows how the algorithm utilizes a landmark to improve the search.
Based on landmark location, extra nodes will be pruned (outside blue line) which in return
improves running time. This is where we encountered our first memory problem. In
general, pre-computed data needs to be either read from disk while searching, cached to
memory during the search, or present in memory at all times. The latter is not feasible since
there is just too much data to be loaded into memory considering the 20 million street
intersections in the road network. Also reading the pre-computed data while searching
imposed I/O costs which at the end resulted to poor performance compared to A*. Given
all of these challenges, we reverted to simple in-memory A* implementation.
3.3.3 Nearest Node Search
In the real-world, shortest path queries often assume continuous space which means the
input query can be any point on the map. In contrast our graph consists of discrete nodes.
The input coordinates are most likely not intersections or road segments; hence, they are
not directly on the graph and cannot be used as source nodes for the search algorithm.
The problem is to find nearby intersections as source node candidates. This process
is called nearest node search (kNN). The work by Jensen et al. is one of few studies in this
regard (Jensen et al. 2003). They have also studied nearest neighbor queries of moving
objects on road networks in detail. However, we took a much simpler approach in this work
since we were dealing with a static graph. First, we list nearby road segments (edges) sorted
33
by their Euclidean (walking) distance to the input coordinate. We then use the geometry of
the road to candidate nearby intersections sorted by the walking distance (Figure 3.3). With
a little modification, A* can be optimized to accept multiple source and destination nodes
in the correct order.
Figure 3.3: A nearest node sample search. The red dot is the input query and the brown line is
the distance added to the search result
We generate the list of nearby nodes (first part) by calling the SQL Server 2008
spatial distance query (Kallay 2008). The second part was implemented separately. Despite
the scale of our database, the SQL Server spatial index (Szalay et al. 2005) is tuned such
that, on average, it answers kNN queries in 0.1 sec.
3.3.4 Integration
Going back to the main motivation of this project, we wanted to design a shortest path tool
for health science researchers in order to process driving times and distances in batch mode.
The intent was not to build an online or real-time shortest path system. Queries need to be
processed in batches. The core shortest path engine works with any given source and
34
destination. A multi-thread batch processor works on top of this engine and acts as the Web
user interface. The I/O costs of the batch processor do not affect the performance since it
is handled on a different machine.
3.4 Results
We tested each component of our system periodically for performance. The results shown
here are from the final version of the system which was coded entirely in C# 2.0. We used
the following three state-of-the-art servers for these tests:
Main Server: 2 x Quad core 64-bit 2.66 GHz CPU, 8 GB RAM.
Database server: SQL Server 2008, 4 GB RAM.
Web Interface: Due Core 3.2 GHz, 2 GB RAM.
For our tests, we ran a batch of 4,000 travel records of patients to hospitals. The times were
recorded from the beginning of each record, to querying the main server, all the way to
saving the results back to the disk. Each query included two nearest node searches for
source and destination coordinates and two shortest path searches for time and distance.
The first two plots (Figures 3.4 and 3.5) show the average query time as a function of the
distance traveled.
The second graph (Figure 3.5) shows a sudden jump in performance for distances
traveled > 2,500 miles. At this point the main server is running out of physical memory (8
GB) and the OS starts paging which significantly affects the running time. Other than that,
the processing time is always linear to traveled distance.
35
Figure 3.4: Processing times for short queries as a function of distance traveled
Figure 3.5: Processing time for longer queries as a function of distance traveled
We also performed an experimental correctness test on our own integrated system.
For this purpose, we ran Google Maps and MapQuest driving distance Web services on
our test data and compared the results to those generated with our own system (Figures 3.6
and 3.7). In most cases our system returned slightly shorter paths.
The main reason for these small differences is that commercial driving direction
calculators are not guaranteed to generate the shortest paths. In some cases, more human
friendly paths are preferred to shortest paths. The other reason is due to slight differences
0
0.5
1
1.5
2
2.5
0 45 90 135 180
Time (sec)
Traveled Distance (miles)
Process Time (Short Queries)
Process Time (sec)
n x Log(n)
0
175
350
525
700
0 500 1000 1500 2000 2500 3000
Time (sec)
Traveled Distance (miles)
Process Time (Long Queries)
TotalTime
n x Log (n)
36
in road network data. Different methods in rounding real numbers can sometimes cause
small errors as well.
Figure 3.6: Correctness of our results (blue line) compared to the results obtained with Google
Maps and MapQuest (pink line)
Figure 3.7: Differential error of our results compared with the Google Maps and MapQuest
results. Positive error means we found a shorter path
0
3
6
9
12
15
25 75 125 175 225
Travel Distance
ID
Accuracy
Travel Distance
Google/MapQuest Results
-0.2
-0.15
-0.1
-0.05
0
0.05
0.1
0.15
0.2
0 30 60 90 120 150 180 210 240 270
Delta Distance
ID
Delta Accuracy
Delta Distance / Distance
37
3.5 Conclusions
We implemented a general use shortest path system on the US and Canadian road networks
using the NAVTEQ road network data. We have presented accuracy and performance
results to support the claimed efficiency, and we have argued that, in our case, pre-
computation would not noticeably improve the performance. Thanks to the open source
modular programming, with some modifications, our approach can be utilized to calculate
shortest paths with different cost functions or different road navigation restrictions (e.g.
emergency car routing). On the other hand, it is not directly applicable to several other
important routing problems such as public transportation routing or evacuation routing.
38
CHAPTER 4: STATIC EVACUATION ROUTING
1
So far we have reviewed major related work in evacuation planning and road network
routing. We have also briefly studied one shortest path algorithm and presented
experimental results. This chapter builds on the A* search algorithm to perform large scale
evacuation routing. We only focus on static evacuation routing which means the road
network will not change during evacuation.
Algorithm 4.1 outlines an evacuation routing system that addresses all the
requirements for evacuation routing stated in Chapter 1. The system inputs the
transportation network in the form of a directed graph G. Set S identifies the source
population with their intervals int(s). Function 𝒯 is the chosen traffic model. The
GetEvcRoutes function gets the inputs and generates one path for each source point. The
paths all end at vertex t. EvcTime is the predicted global transportation time based on the
generated routes. In other words, based on the length of these paths (𝓟 ) and the traffic
predictions, it takes EvcTime time for everyone to get to the destination. SimTime is the
simulated global transportation time. This step is only for evaluation purposes and is not
part of the CASPER system (line 4). The Simulate function takes as the input only the
graph, source points, and the generated paths. It ignores the traffic model. Instead of
predicting the time, it actually simulates every person (car) moving from s to t on the graph.
1
A modified version of this chapter was published in Computers, Environment and Urban Systems:
Shahabi K and Wilson J P (2014) “CASPER: Intelligent capacity-aware evacuation routing”. Computers,
Environment and Urban Systems 46: 12-14.
39
It also takes into account the interactions between evacuees (cars). SimTime is the recorded
time for the last person reaching his or her destination. The closer the two times, the more
accurate is the traffic model.
Algorithm 4.1. Evacuation Framework
1. input: G(V, E), S, t, and 𝒯 (d, c)
2. 𝓟 ← GetEvcRoutes(G, S, t, 𝒯 )
3. EvcTime ← max { cost
𝒯 (P s) | P s ∈ 𝓟 }
4. SimTime ← Simulate(G, S, 𝓟 )
5. return 𝓟 , EvcTime, and SimTime
This framework allows us to measure the accuracy of every traffic model and pick
the best model for our routing. Of course we cannot simulate every situation and that is
why predicting traffic is so important. Throughout the remainder of this chapter, the details
of our path finding algorithm are explained.
4.1 Background
4.1.1 Naïve Approach
As discussed earlier, the GetEvcRoutes function generates routes from the source points to
the destination (Algorithm 4.1, line 2). A primitive greedy approach is to completely ignore
𝒯 and return shortest paths for each source point. Algorithm 4.2 outlines this approach.
This evacuation algorithm is complete which means it will find a path for every source
point to the destination if such a path exists. It is also optimal under a constant traffic model
assumption: 𝒯 (d, c) = 1. Obviously this assumption is unrealistic. Therefore, it is important
to study the effect of different traffic models on solution optimality (or quality).
40
Algorithm 4.2. Shortest Path
𝓟 ← 𝜙
∀s ∈ S, w(s)>0 do {
1. route P s ← Dijkstra(G, s, t)
2. if P s ≠ 𝜙 then 𝓟 ← 𝓟 ∪ {P s}
}
return 𝓟
The optimal implementation of the GetEvcRoutes function guarantees that EvcTime
would be as small as possible. Certainly this is not feasible with an unknown traffic model.
While achieving the optimal solution is hard, we can improve the quality of the solution
by decreasing the EvcTime as much as possible. There are two main challenges to improve
the quality of the solution: (1) which path to assign to evacuees; and (2) in which order the
evacuees should be processed. In order to make Algorithm 4.2 implementation aware of
the traffic conditions, the internals of the path finding need to be altered. This awareness
can be achieved by introducing the cost function presented in Eq. 1.5. However, this new
cost function brings new complications because we need to maintain all the assigned paths
in an accessible data structure. Every new path assigned to a source point affects the
traversal cost of other evacuees. Due to this combinatorial effect, the order in which to
process source points also becomes a challenge.
Figure 4.1 demonstrates one possible solution and the discussed challenges. The
graph consists of 11 edges (solid lines) and 10 vertices. Each edge is labeled with its
impedance (imp). Let us assume all edges have the same capacity: cap(e) = 1. There are
three source points each with one evacuee: w(s) = 1. P 1 and P 2 are displayed as dotted lines
and P 3 as a dashed line. These are not shortest paths. The solution has been optimized to
41
avoid congestion. Under most realistic traffic models this would be a good solution (if not
the optimal solution). Now let us assume S 3 takes a different path. It will certainly overlap
with either P 1 or P 2. Due to this overlap, the cost of some edges will increase according to
the traffic model (𝒯 ) and this may or may not change the EvcTime.
Figure 4.1: A graph with three source points and their evacuation paths
4.1.2 Traffic Model
We have thus far discussed how we use traffic models without describing the models
themselves. There are many approaches and models to choose from. Greenberg (Greenberg
1959), for example, proposed one of the first traffic prediction models and provided two
experiments to validate his model. Smith (Smith 1991) later described several analytical
linear and non-linear traffic models. His models can predict effective car speed under
traffic congestion based on street segment speed limit, length, number of lanes, and number
of cars. More recently, Bellomo et al. (Bellomo, Delitala, and Coscia 2002) reviewed
several mathematical models based on fluid dynamics and offered the following synthesis:
“The objective of mathematical [traffic] research consists first in deriving suitable
models to describe the evolution in time and space of the flow conditions: car density
and velocity. Then in solving mathematical problems generated by the application of
models to real traffic flow conditions. The output may hopefully be useful for engineers
involved in traffic flow control and optimization.” (p. 1801)
42
In addition to these theoretical models, we can also analyze historical traffic data
and extract empirical models. Such a model requires high resolution spatiotemporal traffic
data and an advanced curve fitting (or surface fitting) tool. For the purpose of our research,
we used several analytical and empirical models to evaluate our algorithm. They all fulfill
the requirements captured in Eq. 1.4 and can be formulated as follows:
Eq. 4.1
𝐹𝑙𝑎𝑡 : 𝒯 (𝑑 , 𝑐 ) = 1
Eq. 4.2 𝑆𝑡𝑒𝑝 : 𝒯 (𝑑 , 𝑐 ) = 1 − 𝜃 (
𝑑 − 𝛼𝑐 )
= {
1, 𝑑 < 𝛼𝑐 0, 𝑑 > 𝛼𝑐
Eq. 4.3 𝐿𝑖𝑛𝑒𝑎𝑟 : 𝒯 (𝑑 , 𝑐 ) = 1 −
𝑑 𝛽𝑐
Eq. 4.4 𝑃𝑜𝑤𝑒𝑟 : 𝒯 (𝑑 , 𝑐 ) = 1 − 𝛾 √𝑑 × 𝑒 −𝜀𝑐
Eq. 4.5 𝐸𝑥𝑝𝑜𝑛𝑒𝑛𝑡𝑖𝑎𝑙 : 𝒯 (𝑑 , 𝑐 ) = 𝑒 𝑥 𝑝 [− (
𝑑 − 1
𝛽 (𝑐 )
)
𝛾 (𝑐 )
] , 𝛾 (𝑐 ) =
𝑙𝑛 (
𝑙𝑛 𝑉 𝑎 𝑉 ⁄
𝑙𝑛 𝑉 𝑏 𝑉 ⁄
)
𝑙𝑛 (
𝑎 . 𝑐 − 1
𝑏 . 𝑐 − 1
)
, 𝛽 (𝑐 )
=
𝑎 . 𝑐 − 1
[𝑙𝑛 (
𝑉 𝑉 𝑎 )]
1
𝛾 (𝑐 )
⁄
=
𝑏 . 𝑐 − 1
[𝑙𝑛 (
𝑉 𝑉 𝑏 )]
1
𝛾 (𝑐 )
⁄
where a,b,ρ, λ, η, and ε are constants, and θ is the step function not to be confused
with the step traffic model. The Flat model (Eq. 4.1) was introduced earlier as a constant
function. We have formulated the Step traffic (Eq. 4.2) model based on the CCRP
algorithm, which stops using an edge once it runs out of capacity. The Linear (Eq. 4.3)
model is an analytical traffic model. Under the linear traffic model assumption, the
evacuation routing problem can be reduced to the max-flow, min-cost problem and as a
result can be solved in polynomial time. Of course, we have to assume that the evacuee’s
movements can be modeled as flows. The Power model (Eq. 4.4) has a flexible formulation
43
and is the result of empirical curve fitting. It improves the traffic congestion predictions
and the evacuation time estimates. The Linear and Exponential models (Eqs. 4.3 and 4.5)
are analytical models discussed in Smith (Smith 1991).
The aforementioned traffic models are presented in Figure 4.2 with c = 1 (i.e. a road
segment with one driving lane). The x axis represents the vehicle density on the road
segment and the y axis represents the speed ratio. From Eq. 1.5 we can understand that a
ratio of 1 means there is no congestion and all vehicles can travel as fast as the speed limit
permits. A speed ratio of 0.5 means vehicles can travel on the road segment at half the
speed limit on average. All of the aforementioned traffic models are normalized and scaled
to hit the 0.5 ratio at d = 500.
Figure 4.2: Plot of selected traffic models
Within the context of evacuation routing, traffic uncertainty and background traffic
can play a role. Traffic uncertainty occurs when the network travel time is not precisely
predictable, typically because part of the network is not well-studied. High congestion itself
0.00
0.20
0.40
0.60
0.80
1.00
0 200 400 600 800 1000
Speed Ratio ( 𝒯 )
Density
Linear
Step
Flat
Power
Exponential
44
can also introduce additional uncertainty. Background traffic is the flow of traffic before
the evacuation starts. Empirical traffic models usually assume an empty road network as
the initial condition. This can be accounted for with a non-zero initial condition. CASPER
does not account for traffic uncertainty or background traffic directly. However, it can
optimize routes with any given traffic model including models that incorporate background
traffic or traffic uncertainty.
4.1.3 Flocking Simulation
The previous section summarized the utilized traffic models. This section covers the
simulation component. We use simulation to measure evacuation route quality and also to
fine-tune the Power traffic model. The simulation component is a flocking model
(Reynolds 1987) on top of the ArcGIS software (Esri 2015). Such simulations are also
known as agent-based models. The flocking model was originally designed to simulate a
flock of birds flying across the sky. Later additions enabled it to simulate agents following
paths and avoiding obstacles. Our simulation takes as an input the transportation network
(G), the initial locations of all the cars (S), and the evacuation routes (𝓟 ). At every source
point s, we have w(s) cars that will take route P s to safety. The simulation assumes one
agent for every car and then moves them one by one in small time intervals (e.g. 1 sec)
along the path to safety. The total transportation time can be measured as the time taken by
the last car to reach safety. During the process, the following rules are enforced:
Cars cannot be closer than some predefined threshold to each other.
Cars’ speeds are based on the free space in front of them and the speed limit.
The acceleration is limited.
45
In case of an accident (collision), both cars’ movements will be undone and
they have to wait until the next time interval.
Cars have to stay within the available road segment lanes.
We built this simulation for two reasons: (1) to evaluate our congestion prediction; and (2)
to fine-tune the Power traffic model. As mentioned earlier, the simulation module ignores
the traffic model. As a microscopic descriptive method, it simulates what is going to
happen at the single car level. All of the interactions between each pair of cars are taken
into account, making it the perfect tool to measure the accuracy of the discussed traffic
congestion prediction models. Algorithm 4.1 outlined how we perform this comparison.
After the GetEvcRoutes returns the EvcTime, the Simulate module is called and returns
SimTime. If the two returned times are close, it means the congestion prediction model (𝒯 )
was accurate. Unfortunately these types of simulations have high computational
complexity and therefore are not scalable.
In addition to the final transportation time, our simulation also generates
intermediate data that is valuable for fine-tuning the traffic model. If one takes a snapshot
while the simulation is running, the outcome is a point cloud representing moving cars.
Each point has two important vectors: position and velocity. The aggregation of these
vectors over each road segment is the averaged density and travel speed. This dataset is
similar to realistic historical traffic data. We have used our simulation-generated traffic
dataset to create the Power traffic model. We picked the San Francisco Golden Gate Bridge
with about 600 surrounding road segments. All roads have been manually set to have a
single lane in each direction. One source point was placed on the west side and one safe
46
zone was placed to the east of the bridge. We then ran a simulation and collected the
average travel time. The simulation has been repeated with source point populations
ranging from 1 to 1,000. We then repeated the same set of simulations with road lanes
ranging from 1 to 150. The result is a 3D point cloud. We used MATLAB curve fitting tool
to fit a model to this point cloud and named it the Power model.
Figure 4.3 shows one instance of the simulation. The black dots are the averaged
travel times from the simulation and the blue line is the Power model fitted to the dots. We
argue that the process of fitting a traffic model can be accomplished with historical traffic
data without loss of generality and/or accuracy. The Exponential model is also presented
as a green line for comparison. It follows the simulation nicely, however, it predicts less
congestion on wider road segments (not shown in figure).
Figure 4.3: The curve fitting process for a road segment with one lane of travel
0.30
0.40
0.50
0.60
0.70
0.80
0.90
1.00
0 200 400 600 800 1000
Speed Ratio ( 𝒯 )
Density
Power
Simulation
Exponential
47
4.2 Approach
4.2.1 CASPER
Section 4.1.1 outlined the evacuation system and Algorithm 4.2 presented one possible
solution. In order to improve the naïve approach, we need to incorporate the introduced
traffic models in our path finding algorithm. Algorithm 4.3 lists the pseudo code for the
CASPER path finding algorithm with the said modification.
Algorithm 4.3. CASPER Path
∀s ∈ S, w(s)>0 do {
1. P s ← 𝜙 , Vi ← 𝜙 (visited vertices set)
2. heap ← MakeHeap (s, 0)
3. while heap ≠ 𝜙 do {
3.1. v ← ExtractMin (heap)
3.2. g(v) is cost from s to v
3.3. Vi ← Vi ∪ {v}
3.4. if v = t then break the while loop
3.5. ∀u ∈ V - Vi, e=(v, u) ∈ E do {
3.5.1. k ← g(v) + cost
𝒯 (e, s) (see Eq. 4.6)
3.5.2. HeapInsert(heap, u, k)
}
}
4. generate P s and reserve it for s
5. if P s ≠ 𝜙 then 𝓟 ← 𝓟 ∪ {P s}
}
re-calculate cost of all paths: cost
𝒯 (P s) (Eq. 1.6)
return 𝓟
At line 2 of Algorithm 4.3 we initiate a heap for the search. We implemented a
Fibonacci heap to get the best run-time; however, a binary heap would do just fine. The
search starts by inserting the source point into the heap. Line 3 is the Dijkstra loop which
48
terminates either when a path is found or all vertices are visited. Line 3.4 summarizes the
termination condition. At line 3.5 the next vertex is picked and the heap is updated. The
entire path finding process is the same as the original Dijkstra except for lines 3.5.1 and 4.
In order to be able to incorporate traffic delays, we calculate the heap key based on our
own cost formula instead of the usual key value. The cost formula is a helper function
based on Eq. 1.5:
Eq. 4.6
𝑐𝑜𝑠𝑡 𝒯 (𝑒 , 𝑠 ) =
𝑖𝑚𝑝 (𝑒 )
𝒯 (𝑑𝑒𝑛 (𝑠 , 𝑒 ) + 𝑑𝑒𝑛 (𝑒 ), 𝑐𝑎𝑝 (𝑒 ))
This calculation at line 3.5.1 considers all of the previously reserved paths as well
as the density from the new population (i.e. den(s,e)). The calculation requires that the
table of reserved paths be recorded (as at line 4). Lastly, we recalculate the cost of all paths.
We need to do this because we do not have the complete record of reserved paths during
the path finding pass and therefore the costs are just a lower bound. Once all the paths are
reserved, the cost needs to be recalculated to find the most accurate global transportation
time (EvcTime).
The CASPER algorithm is complete which means it will find a solution if one
exists. Since we do not know the behavior of the traffic model in advance, judging
optimality is difficult. The effect of each path on previous reservations and future yet-to-
be-processed source points is unpredictable which makes CASPER a sub-optimal
algorithm. It finds the shortest path for each source point, it achieves high accuracy on
traffic delay predictions, but it does not guarantee the shortest total evacuation time
(smallest EvcTime).
49
4.2.2 CARMA
Our initial experiments showed that the final evacuation times are satisfactory but there is
still room to improve CASPER run-time. In this section we introduce a new extension to
the path finding module: the Capacity-Aware Reverse Map Analyzer (CARMA).
CARMA’s primary task is to traverse the graph backwards and generate data to enhance
CASPER run-time. This new extension has two separate features; it sorts source points
according to their predicted evacuation time and it generates heuristic values which
improve CASPER performance. The first feature was inspired by a similar work on CCRP
(Zeng and Wang 2009). It suggests, within the context of CCRP, the total evacuation time
can be improved if source points are sorted according to their initial distance to a
destination such that the first source point to be processed would have the longest shortest-
path to safety.
CARMA’s second feature was inspired by the A* algorithm (Hart, Nilsson, and
Raphael 1972). A* (A-star) is a faster version of Dijkstra. Hart and colleagues proved that
if you adapt the vertex key to be the estimated distance to the destination in addition to
distance from source, then the number of visited vertices would be minimized and the
algorithm terminates faster. We call the estimated distance-to-destination h. In order to
preserve the optimality and completeness of A*, these h values should have two properties:
(1) they should not overestimate the real values; and (2) they must be consistent. The h
values that CARMA generates are indeed a lower bound assumption but do not honor the
consistency assumption mainly because our graph is not planar. As a result, CASPER path
finding remains admissible, but loses its optimality.
50
Algorithm 4.4 revisits the CASPER pseudo code with the new extension embedded.
The new CASPER incorporates the generated heuristic values as part of the heap key
(line 4.4.1). This modification improves path finding run-time as well as the overall
evacuation routing run-time. The novelty behind CARMA’s design is that it is not a one-
time-use function. It can be called multiple times as needed. In order to determine the best
times to re-run CARMA, we introduce the dirty vertex (Di) concept. Initially all vertices
are assumed dirty. After every CARMA run, all vertices are set as clean (line 1.2).
Whenever we reserve a path for a source point, the path vertices are marked as dirty (line 7).
We then calculate the average number of dirty visited vertices divided by the total visited
vertices (line 6, 1). A visited vertex is a vertex that has been visited during path finding
(line 4.2). Once the ratio becomes large enough, we run CARMA again (line 1.1).
Algorithm 4.4. CASPER Path Revisited
vi ← 0, di ← 1
Di ← V (initially all vertices are dirty)
∀s ∈ S, w(s)>0 do {
1. if di > vi * Ratio then {
1.1. CarmaLoop (G, S, t, 𝒯 )
1.2. Di ← 𝜙 , vi ← 0, di ← 0
}
2. P s ← 𝜙 , Vi ← 𝜙
3. heap ← MakeHeap (s, 0)
4. while heap ≠ 𝜙 do {
4.1. v ← ExtractMin (heap)
4.2. Vi ← Vi ∪ {v}
4.3. if v = t then break the while loop
4.4. ∀u ∈ V - Vi, e=(v, u) ∈ E do {
4.4.1. k ← g(v) + cost
𝒯 (e, s) + h(u)
4.4.2. HeapInsert(heap, u, k)
51
}
}
5. generate P s and reserve it for s
6. vi ← vi + |Vi|, di ← di + |Di ∩ Vi|
7. Di ← Di ∪ P s
8. if P s ≠ 𝜙 then 𝓟 ← 𝓟 ∪ {P s}
}
Re-calculate cost of all paths: cost
𝒯 (P s)
return 𝓟
We hypothesize that vertex dirtiness signals that the associated h value may be
outdated. To explain vertex dirtiness, we need to revisit the A* hypothesis. The Dijkstra
algorithm finds the path by recursively visiting and marking graph vertices. The
computation time is strongly tied to the number of visited vertices. At a minimum, the
algorithm has to visit all the vertices that are part of the path but the number is almost
always greater. The h value helps the algorithm reduce the number of vertices visited. The
closer the h value is to the actual distance, the fewer vertices visited. In our evacuation
routing framework, we change the cost of edges after each path reservation which in turn
renders some of the h values outdated. The edge dirtiness system retains the count and
initiates a CARMA loop if the ratio exceeds a user-defined threshold (Ratio).
Algorithm 4.5 outlines the CARMA extension. The goal is to update the h values.
The best possible accuracy can be achieved if you traverse the graph backwards, from
destination to all the source points and then replace the h value with the g (cost) value. At
line 1 the remaining source points are collected and then the one source point with the
smallest w(s) (population) is chosen (line 3). This assures the lower-bound assumption for
the h values. The non-increasing property of the traffic model (Eq. 1.4) and the choice of
52
s_min, guarantees that the h values will always be less than the actual distance for any
remaining source point. As we traverse the graph backwards, g(v) is now the distance from
destination point (t) to the extracted vertex v (line 5.3), and this is needed to update the h
value for the vertex v. The traversal is terminated once all remaining source points are
discovered (lines 5.5 and 5.6). Lastly, the source points are reordered so that the source
point with the largest h value (longest estimated path) gets processed first by CASPER.
Our experiments showed that in most of the cases this reverse ordering leads to a noticeable
improvement in the final evacuation time. Source points are rearranged only at the first
CARMA run.
Algorithm 4.5. CARMA Loop
1. S’ ← { s | s ∈ S, s is not yet processed }
2. Dst ← 𝜙 , Vi’ ← 𝜙
3. s_min ← argmin { w(s) | s ∈ S’ }
4. heap ← MakeHeap (t, 0)
5. while heap ≠ 𝜙 do {
5.1. v ← ExtractMin (heap)
5.2. Vi’ ← Vi’ ∪ {v}
5.3. g(v) is cost from t to v
5.4. h(v) ← g(v)
5.5. Dst ← Dst ∪ ( {v} ∩ S’ )
5.6. if Dst = S’ then break the while loop
5.7. ∀u ∈ V - Vi’, e=(u, v) ∈ E do {
5.7.1. k ← g(v) + cost
𝒯 (e, s_min)
5.7.2. HeapInsert(heap, u, k)
}
}
6. sort S in reverse order according to h
min
(s)
53
4.2.3 Complexity Analysis
CASPER’s computational complexity is fundamentally that of Dijkstra. As discussed
earlier, the inner loop of CASPER is a path finding process. None of the modifications to
the original Dijkstra algorithm affect the complexity. Therefore, CASPER’s complexity is
O(|S|) × O(Dijkstra). Since we do not split population at each source point, the complexity
only depends on the number of source points and not on the total population. We
implemented the path finding (Dijkstra) process with a Fibonacci heap; hence, the final
complexity of CASPER would be O(|S|×(|E|+|V|log(|V|))). This includes all the heap sorts
and path generation/reservations. The extra CARMA loops do not add to the complexity.
Every CARMA loop is fundamentally a Dijkstra search plus sorting S. The complexity of
sorting the source points is insignificant because |S| < |V|. At most we have one CARMA
loop per each source point. Therefore, the computational complexity remains the same:
𝑐𝑜𝑚𝑝𝑙𝑒𝑥𝑖𝑡𝑦 : 𝑂 (|𝑆 | × (|𝐸 | + |𝑉 | 𝑙𝑜𝑔 (|𝑉 |)))
4.3 Results
In this section we present the CASPER experimental results and comparison with previous
methods. The evacuation framework is implemented with C++ as a single-threaded 32-bit
plug-in for ArcGIS Desktop 10.1 (Esri 2015). Our evacuation tool is publicly available as
a free download (Shahabi 2015a). Everything from loading data, storage, accessing the
transportation network, and visualization is abstracted by ArcGIS. The implementation
supports simple turn restrictions, multiple destination points, different impedance metrics
(time, length, etc.), and adjustable traffic models. All the experiments were performed on
a dedicated 64-bit Microsoft Windows 7 workstation with Intel Core 2 Duo CPU (3 GHz)
54
and 8 GB of memory. The reported CPU time and memory usages are that of the evacuation
tool itself and not the entire software package. Times to load inputs, visualize, and store
the results are excluded.
4.3.1 University Campus Evacuation
The initial experiment was conducted on a small graph. We generated a transportation
network representing all the walking and driving routes on the University of Southern
California (USC) University Park campus (Figure 4.4). The graph has about 1,000
directional edges. One hundred evacuation scenarios were generated to represent different
emergency situations. For each scenario, approximately 3,000 students were placed
randomly at different campus buildings. This is the maximum number of source points we
could simulate at this scale. The goal was to move all these students off the campus. For
every scenario we ran a simulation and then compared the final simulation time with the
predicted evacuation time. Students had no initial delay (int(s) = 0) and had to stick to their
assigned CASPER routes.
Figure 4.5 presents the comparison. Each line is a moving average trend line. The
Power model is consistently predicting the total evacuation model close to the simulation
time and it never underestimates the evacuation time. The Exponential model predicts some
congestion but not as high as the simulation. This is because the Exponential model
calculates less congestion on roads with large width (number of lanes) compared to the
Power model. The Flat model is indifferent to the congestion; therefore, it returns the same
number for every scenario. The Step model acts like a Flat model whenever the graph is
55
not saturated. For scenarios with a saturated graph, the Step model is incapable of
calculating a reasonable output; therefore, it returns a very large estimate.
Figure 4.4: USC campus with one of the evacuation scenarios
Figure 4.5: Traffic model comparison with simulation on USC campus
4.50
5.00
5.50
6.00
6.50
7.00
2950 3150 3350 3550
Evacuation Time (minutes)
Student Population
Step
Power
Simulation
Exponential
Linear
Flat
56
It is important to study evacuation algorithms that work with multiple traffic
models. The optimality of the evacuation routing algorithm does not matter without some
assurances on predicted evacuation time. In other words, it is not enough for the routing
algorithm to return a plan with small evacuation time. It should also assure us that the
prediction is realistic and the evacuation time is feasible.
4.3.2 Urban-Scale Evacuation
At the urban scale, we are comparing each of the route calculation methods with different
traffic models to investigate the length of evacuation times. The 10 southern-most counties
of California starting with San Luis Obispo County in the north and concluding with San
Diego and Imperial counties in the south were used. The resulting graph, which included
both highways and local roads, has about 1,850,000 directional edges and 750,000 vertices
(Figure 4.6; local roads not shown). Assuming a pending tsunami event, we can calculate
the threatened residential areas based on the predicted magnitude of the tsunami waves.
The population counts were taken from 2010 Census Block Groups. We have created three
evacuation phases in which the goal was to evacuate people living at lower to higher
elevations. All of the people living in Los Angeles and Ventura counties at elevations < 5
m above mean sea level were evacuated to higher lands (> 50 m above mean sea level)
during the first stage. This was about 17,500 cars at 132 source points. Stage 2 is the same
except it evacuated people living at elevations below 10 m to locations that exceed 100 m
which is about 51,000 cars at 353 source points, and Stage 3 evacuates residents below 20
m to locations that are > 100 m, which is equivalent to about 130,000 cars at 859 source
57
points. The residential communities in these areas are dense such that graph saturation is
unavoidable.
Figure 4.6: Map of Southern California highways
In our experiments we assumed no metering of evacuees: int(s) = 0. We also
selected Ratio to be 0.1. From experience, we realized a ratio lower than 0.1 affects the
performance negatively. However, higher ratios would generally perform well. With a ratio
of 1, there would only be one CARMA loop at the beginning and no extra loops in the
middle. In order to have a fair comparison, we have implemented CCRP and shortest path
(SP) alongside CASPER. We have implemented CCRP with several small modifications:
We have not implemented the ILS heuristic. ILS improves scheduling which
does not apply to our problem.
IDS is not implemented either. Instead we use CARMA’s heuristic for all
routing methods.
58
The order in which source points are processed greatly affects the global
evacuation time. Hence, source points are sorted according to distance-to-safety
estimates beforehand for all algorithms.
Depending on the traffic model and the initial delay functions, the graph/edge
saturation may never happen. Hence, we do not remove edges as they run out
of capacity. We simply set edge costs to a large number.
Figure 4.7 presents the result of the urban-scale evacuation experiment. It shows the
percentage of the population that was rescued per unit time. The x-axis represents
evacuation scenarios. They are named as [Stage]-[Routing Algorithm]-[Traffic Model].
For example, S2-CASPER-Power refers to routes that have been calculated with the
CASPER algorithm and measured with the Power traffic model at the second stage (10-
100 m). The y-axis is the percentage of rescued population. For example, S1-CCRP-Step
shows 11% of evacuees are rescued within the first hour, 37% within the first 100 hours,
and 79% within the first 1,000 hours. Some of the bars do not reach the 100% which means
their total evacuation time is beyond 1,000 hours.
In the previous section we discussed the importance of traffic modeling to
optimization. In this section the optimality is discussed. We focus on Stage 2 (S2) but the
analogy stands for the first and third stages as well. As mentioned earlier, CCRP recognizes
the Step function as the traffic model so here we compare S2-CCRP-Step with S2-
CASPER-Step. The Step function can cause early graph saturation and therefore neither of
the algorithms is able to predict a complete evacuation under 1,000 hours. However,
CASPER is predicting 77% in the first hour whereas CCRP predicts less than 40% after
59
1,000 hours. As a reminder, the original CCRP provides an evacuation schedule to avoid
graph saturation. While CCRP does not recognize the Power and Exponential models, we
can re-calculate the cost of CCRP-generated paths with the other models. S2-CCRP-Power
is the prediction based on CCRP paths but re-measured with the Power model. As you can
see, CASPER managed to evacuate the entire population in two hours and CCRP reports
that 50% were rescued in the first 10 hours. In conclusion, CASPER is at least an order of
magnitude better than CCRP in evacuation time using the same traffic model.
Figure 4.7: Urban population evacuated at three different stages by hour. Each bar shows
the percentage of population rescued in the time shown.
Finally, Figure 4.8 shows some of the evacuation routes that were generated for the
Santa Monica area in Los Angeles County. This map shows the S3-CASPER-Power
experiment. As seen on the map, most of the local roads as well as the highways are being
utilized to evacuate the residential areas.
4.3.3 Performance
In order to better understand the performance and memory consumption, we created three
new stages: S4, S5, and S6. They have the same graph size as the previous stages but the
0%
20%
40%
60%
80%
100%
Rescued at each hour
1st Hour 2nd Hour 3rd Hour 10th Hour 100th Hour 1000th Hour
60
population is no longer limited to two counties. The endangered population is selected
based on elevation from all six coastal counties. Stage 4 (S4) moves residents below 10 m
to higher areas (≥ 100 m). This is about 108,000 cars at 750 source points. Stage 5 is the
same except it evacuates people living at elevations < 20 m to areas ≥ 100 m which is about
270,000 cars at 1,754 source points, and Stage 6 moves residents from < 30 m to areas ≥
100 m which is about 423,000 cars at 2,747 source points.
Figure 4.8: A sample of evacuation routes for scenario S3-CASPER-Power. The map shows
Santa Monica city in California.
As mentioned earlier, we measure the system memory and CPU time of the route
processing itself excluding the I/O time. All the evaluated route optimizations are greedy
algorithms. They work on source points one at a time in a linear fashion. The disadvantage
is that the combinatorial effect of route assignments can never be taken into account. The
advantage is that time and space complexities are low. Despite the 4 GB memory limitation
and the complexity of the ArcGIS software ecosystem, we never encountered any memory
61
problems. Table 4.1 presents memory usage in Megabytes for all the scenarios. The
memory usage is gradually increasing with the size of evacuation area from about 600 MB
(S1) to 1 GB (S6). The experiments with extra CARMA loops use slightly more memory
to process and store the additional h values.
Table 4.1 follows the same naming conventions as before (first column). The
EvcTime column presents the evacuation times in hours. These are the same evacuation
times presented in Figure 4.7. The newly defined stages are relatively large in scale;
therefore, only the CASPER algorithm under the Power and Exponential models has been
tested. For obvious reasons, only the CASPER algorithm can benefit from multiple
CARMA loops. The remainder of the algorithms has been set up with only one CARMA
loop at the beginning. In order to evaluate the effectiveness of multiple CARMA loops,
each CASPER scenario has been repeated twice; once with the Ratio of 0.1 and again with
the Ratio of 1.
The early stages (S1 and S2) are relatively small in size and have low density
population; therefore, the congestion level is low. The algorithm intelligently decided that
no extra CARMA loops are required which means the percentage of dirty edges (outdated
h values) never exceeded 10%. At the other stages, the extra CARMA loops are improving
both the evacuation and computation times. For example, the S5-CASPER-Power scenario
with seven CARMA loops is computing a 3.7-hour evacuation plan about 40% faster than
the one without the extra CARMA loops.
62
Table 4.1: Performance and memory consumption under different scenarios
Scenario
CASPER baseline (Ratio = 1) CASPER+CARMA (Ratio = 0.1)
CPU
(min)
EvcTime
(hour)
Mem
(MB)
CPU
(min)
CARMA
Loop
EvcTime
(hour)
Mem
(MB)
S1-CASPER-Exp 0.7 0.7 619 0.7 1 0.7 663
S1-CASPER-Power 0.7 0.8 630 0.7 1 0.8 679
S1-CASPER-Step 0.7 0.5 665 0.7 1 0.5 725
S1-CCRP-Power 1.0 74.1 674
S1-CCRP-Step 0.7 190,671.4 679
S1-SP-Exp 0.7 0.8 620
S1-SP-Power 0.7 1,483.5 617
S2-CASPER-Exp 2.2 1.0 818 2.2 1 1.0 844
S2-CASPER-Power 4.7 1.7 819 4.5 1 1.7 914
S2-CASPER-Step 2.0 138,669.9 908 2.1 1 138,669.9 875
S2-CCRP-Power 4.2 1,322.2 858
S2-CCRP-Step 1.9 192,135.2 876
S2-SP-Exp 0.9 1.3 795
S2-SP-Power 0.9 3,022.1 748
S3-CASPER-Exp 6.7 1.1 780 6.6 1 1.1 818
S3-CASPER-Power 16.9 3.3 794 13.3 5 3.3 943
S3-CASPER-Step 10.5 620,056.9 820 10.2 1 620,056.9 890
S3-CCRP-Power 13.4 2,366.5 849
S3-CCRP-Step 9.2 715,386.5 711
S3-SP-Exp 0.9 1.5 783
S3-SP-Power 0.9 3,022.1 918
S4-CASPER-Exp 4.8 1.0 870 5.6 1 1.0 848
S4-CASPER-Power 10.3 1.8 855 8.7 2 1.8 927
S5-CASPER-Exp 13.5 1.1 876 13.7 2 1.1 919
S5-CASPER-Power 34.9 3.8 890 21.0 7 3.7 1,000
S6-CASPER-Exp 21.3 1.2 841 17.8 4 1.2 1035
S6-CASPER-Power 64.8 200.2 864 39.4 11 151.3 940
4.3.4 Interval Time
As the last experiment, we present the effect of changing interval time on different
algorithms under the Power traffic model. Interval time is the time between two evacuees
63
(cars) leaving the same metered source point. Figure 4.9 presents a graph of the changing
evacuation time against different time intervals for selected scenarios. The y-axis
represents the evacuation time in hours and the x-axis represents the interval time in
minutes. For example, an interval of 0.001 means all source points are set to be metered at
a 0.001 minute interval: ∀ s ∊ S int(s) = 0.001 minutes. As the interval increases the flow
of each source point on an edge is decreased; hence, the probability of congestion is lower
and the problem is easier to solve. As shown in the graph, all of the evacuation times start
to decrease with increasing interval time independent of the algorithm. Both CASPER
scenarios reached their minimum evacuation time at around the one second interval while
CCRP and SP reached their minima at around five seconds. At the point where all the
scenarios meet (5 sec interval), there is no congestion. The flow is low enough that all
source points can take their shortest paths to safety with no predicted congestion.
Therefore, the evacuation time for all algorithms converges to the optimum. From that
point forward the evacuation time is going to increase gradually with increasing interval
times because the large metered interval times are going to delay the last person traveling
toward safety. We continued the experiment up to the five minute interval and observed
the same behavior.
As shown in Figure 4.9, the rate of decline in evacuation time differs from one
algorithm to another. CASPER is aware of the congestion and can avoid it as much as
possible; therefore, it is less sensitive to the interval time. CCRP and SP, on the other hand,
are not aware of the congestion and are more sensitive to the metered interval time. Both
64
CASPER scenarios (S3 and S6) reach their minima faster and achieve a lower evacuation
time compared to the other algorithms.
Figure 4.9: Evacuation times as a function of source interval
4.4 Conclusions
Let us go back to our original example with the Pacific Ocean tsunami moving towards the
west coast of the US. Millions of people live within minutes in terms of driving distance
from the California coast. This is a densely populated area with mainly local roads and a
few major highways. Evacuating this many people to inland destinations would not be
possible without prior preparation. We showed that CASPER, without any pre-
computation, generates realistic routes in reasonable time. We have also showed that traffic
modeling plays an important role during evacuation. Therefore the combination of traffic
modeling, road network attributes, and intelligent capacity-aware routing would be the
appropriate solution for evacuation planning.
0.5
5
50
500
5000
0.000 0.001 0.010 0.100 1.000
Evacuation Time (hour)
source point interval (minutes)
S3-CASPER-Power
S3-SP-Power
S3-CCRP-Power
S6-CASPER-Power
65
As we were developing the CASPER tool, we came across areas for which this
solution will not work. They are listed here to help motivate and guide the work described
in the next chapter. One of the challenges in evacuation planning is to deal with the
dynamics of the road network at the time of the disaster. For example, what would happen
if a bridge goes down during the evacuation? Certainly running the CASPER tool again is
not an option because not all the population is affected. The other open problem is to
improve the evacuation time. At the moment we are only sorting the evacuees once at the
beginning. Given different distributions of source points on the graph, this is not always
ideal because evacuees may overpopulate network bottlenecks and increase evacuation
time. Certainly a more intelligent ordering of source points and path cost calculation is
required to help alleviate these challenges. We therefore take up these challenges in
Chapter 5.
66
CHAPTER 5: DYNAMIC EVACUATION ROUTING
2
In emergency management, special tools are needed so that we can take the appropriate
action at different stages of the evacuation. Recent wildfires in California showed how
quickly a natural disaster can affect a large geographical area. Natural disasters can create
unpredicted traffic congestion or can temporarily block urban or rural roads. Evacuating a
large area in an emergency situation is not possible without prior knowledge of the road
network and the ability to generate an efficient evacuation plan. An ideal evacuation
routing algorithm should be able to generate realistic and efficient routes for each evacuee
from its source to the closest shelter. It should also be able to quickly update routes if the
road network is changing during the evacuation. For example if a main road is blocked
during a flood, the evacuation routing algorithm should update the plan based on this
change in the road network. In this chapter we discuss evacuation routing in a dynamic
environment. Major works in this field have been studied and the static algorithm from
previous chapter has been improved and extended. The result is a new algorithm that is
both faster and can generate better evacuation routes. Additionally it can quickly adjust the
routes if a change in the road network is detected. The new algorithm’s performance and
running time is reported.
2
A modified version of this chapter has been submitted to the International Journal of Geographical
Information Science.
67
5.1 Introduction
The ability to plan a large scale evacuation during a natural or man-made disaster is a
serious and an important research question. However the question is not entirely answered.
Currently we have the required computational power and good quality geospatial data to
produce the evacuation routes for a large geographical area (e.g. California). There also
exists substantial work in the literature about traffic congestion. Also, the advent of mobile
platforms and smart cars has made it possible to reach out to individuals in seconds with
life-saving news as might happen during a disaster. The missing element is the ability to
generate efficient evacuation routes. Such a system should be able to monitor the
evacuation and update the routes in case some of the initial conditions have changed. In
this chapter, we propose a new evacuation routing algorithm that can quickly adjust the
routes if a change in the transportation network is detected.
Figure 5.1 shows a map of Southern California with major roads and historical
wildfire incidents. Imagine there is a wildfire in Southern California. The responsible
agency identified the endangered neighborhoods, located the appropriate shelters, and then
generated an evacuation route for each neighborhood. Let’s assume that each household
receives the route via a mobile app and the agency can anonymously track each car on its
evacuation route(s). Assuming none of the initial conditions change, everyone will get to a
shelter in a reasonable and predictable time. The problem of generating these evacuation
routes while minimizing the traffic congestion is what we call static evacuation routing. As
the evacuation is happening, a number of things can change in the environment: (1) there
could be background traffic that we have not initially considered, (2) car accidents can
68
temporarily affect the traffic flow, (3) changes to the road network such as a damaged
bridge, a partially blocked road, or a flooded underpass can affect the road network, and
(4) there could be more cars leaving one or more neighborhoods than we anticipated. All
of these unpredictable situations can affect the evacuees. We can update the evacuation
routes once we learn about the changes and then push updated routes back to the affected
motorists. The problem of generating and maintaining evacuation routes in a dynamic
environment is called dynamic evacuation routing.
Figure 5.1: Map of historical wildfires in southern California with major roads
In this chapter we propose a new solution to the dynamic evacuation routing
problem. We focus on solutions that can be scaled to large geographical areas at least the
size of a city. The remainder of this section provides an overview of the broader evacuation
planning process with an emphasis on evacuation routing challenges. We then lay out the
contribution and scope of our solution with respect to the evacuation planning problem.
69
Section 5.2 reviews related work on evacuation routing. Section 5.3 formally defines the
problem and explains the solution. Section 5.4 presents the experimental results.
5.2 Related Work
Dynamic evacuation routing, as it is currently defined, is a fairly new problem. The
majority of the work addressing the urban evacuation routing problem has been published
from 2005. There is substantial work on agent-based modeling, building evacuation, and
linear programing (LP) that is not applicable to urban evacuation routing. The evacuation
simulations (either commercial or research) only visualize what will happen during an
emergency. Empirical works based on linear programing are usually not scalable to a
realistic scenario. Pel et al. provided a thorough review of traffic simulation models for
evacuation (Pel, Bliemer, and Hoogendoorn 2011). They have specifically looked at the
underlying formulation and the psycho-behavioral assumptions of both commercial and
theoretical traffic simulations. They categorized the models based on three choices:
evacuation participation and departure time, destination choice, and route choice.
Bayram et al. recently published an evacuation planning solution that formulates
the problem as a linear program that can be solved on a small graph. They have used the
US Bureau of Public Roads traffic model (BPR) to estimate traffic times (Federal Highway
Administration 2014). They argued that evacuees may not willingly take a longer path to
safety when there is a nearby shelter. However, they may take a slightly longer path. They
formulated this assumption into their model and reported their experimental results. Nassir
et al. also recently published work that combines traffic signal optimization with
evacuation routing (Nassir et al. 2014). They initially decoupled two problems without
70
losing optimality and then they formulated the routing problem as LP and solved it. Both
of these fairly recent LP-based evacuation routing solutions can be used on graph sizes of
up to 1,000 nodes.
As pointed out in Chapter 2, CCRP is the first algorithm that went beyond an LP or
a plain shortest path solution. In essence, CCRP routes all evacuees to safety one at a time
while constraining the road network (graph) to its road and intersection capacities. It also
detects the network bottleneck (cut). It can schedule evacuees in order to avoid graph
saturation. The authors have continuously been improving the algorithm to achieve a better
running time. In their recent work they have developed a dartboard network cut-based
approach to further improve the running time (Yang, Gunturi, and Shekhar 2012). The
main concern with CCRP is that it does not consider traffic congestion realistically.
Therefore, its final evacuation routes are not optimized based on the true road network
congestion. CCRP is also not suitable for evacuation in dynamic environments as it would
need to be executed from scratch every time.
5.3 Approach
In this section, we present in detail our solution for the dynamic evacuation routing
problem. We first formally define the problem. Next, we briefly explain how CASPER can
be used to solve the static problem. We then introduce two extensions to CASPER that
would make it both faster and modular. With the help of these two extensions a new
algorithm is designed called DCASPER. The followings are the fundamental assumptions
we have made in DCASPER design:
DCASPER needs to have all the CASPER features.
71
We assume everyone starts the evacuation at the same time. In another words,
we do not schedule the evacuation for some evacuees. We do, however, allow
delays between cars coming from the same evacuation point. This technique is
called metering and will dictate the car density on roads.
We assume that we have access to a traffic model in the form of a mathematical
function that can predict the congestion on a street segment given total car
density. Different traffic models can be used in conjunction with DCASPER.
We assume all the cars at one evacuee point are inseparable and need to travel
the same path. They generally remain close to each other throughout the
evacuation.
The changes to the road network are not initially known; hence, the algorithm
can only adjust once it learns about them. The only thing that cannot change
during the evacuation are the hotel and/or shelter locations.
5.3.1 Problem Statement
In this section we model the dynamic evacuation routing problem similar to how we
defined the static version in Chapter 1. We model the problem as a path finding problem
on a directed graph G(E,V). For the purpose of this chapter, it does not matter how the graph
is built. We assume the graph elements are accessible in constant time. In addition, without
loss of generality, we assume there is only one destination node (hotel and/or shelter) in
the graph.
The dynamic problem has five inputs: the graph, the traffic model, the source
points, the destination point, and the table of temporal road network changes. The output
72
is a set of paths for each source point. The directed graph G(E,V) represents the
transportation network with |E| edges and |V| vertices (E ⊂ V
2
). Each edge e has non-
negative initial impedance (imp) and capacity (cap). Since the road network can change
during the evacuation, neither of these values are constant. For example, the impedance
could be initially the length of the road segment and the capacity could be the number of
lanes. Let’s say 20 minutes after the evacuation starts, this edge e is no longer accessible
due to fire hazard. We model this road inaccessibility as a decrease in number of lanes
(capacity), which means the capacity of edge e becomes zero after minute 20. Generally
speaking, we are allowing each graph edge to change its values at some time after the start
of the evacuation. In other words, at each time interval, a subset of edges can change their
impedance and capacity values to a larger or smaller value.
Eq. 5.1
𝐺𝐶 = { 𝑔𝑐 = (𝑡𝑖𝑚𝑒 , 𝑒 , 𝑖𝑚𝑝 , 𝑐𝑎𝑝 )|𝑡𝑖𝑚𝑒 ≥ 0, 𝑒 ∈ 𝐸 } : set of all graph changes
𝑖𝑚𝑝 𝑔𝑐
(𝑒 ), 𝑐𝑎𝑝 𝑔𝑐
(𝑒 ) : impedance and capacity of edge e after graph change gc
∀𝑒 ∈ 𝐸 , 𝑔𝑐 ∈ 𝐺𝐶 𝑖𝑚𝑝 𝑔𝑐
(𝑒 ) ≥ 0, 𝑐𝑎𝑝 𝑔𝑐
(𝑒 ) ≥ 0
The set S contains all the vertices for the source population (i.e. the evacuees). The
vertex 𝑡 ∈ 𝑉 is the destination for all of the source population. Each source point s has a
positive non-zero weight w(s) (Eq. 5.2). For example a source point could be a
neighborhood, a residential building, or a census block or block group on the map. The
weight is the population at that point.
Eq. 5.2
∀𝑠 ∈ 𝑆 , 𝑆 ⊂ 𝑉 𝑤 (𝑠 ) > 0
Each source point s is metered and hence will generate a different density on each
edge. For example, with 30 sec metering, the density reduces to the number of cars that
73
can actually fit on that edge (Eq. 5.3): den(s,e) = 600 / 30 = 20. This density can change
from one time interval to the next as the edge impedance changes.
Eq. 5.3
𝑑𝑒𝑛 𝑔𝑐
(𝑠 , 𝑒 )= 𝑚𝑖𝑛 (
𝑖𝑚𝑝 𝑔𝑐
(𝑒 )
𝑖 𝑛𝑡 (𝑠 )
, 𝑤 (𝑠 ))
We assume there would be only one path P s for each source point s. A path P s is an
ordered set of edges that will guide all the population at s to safety (t). Therefore, the total
density on edge e is the sum of all densities from all paths that pass through e (Eq. 5.4).
Eq. 5.4
∀𝑠 ∈ 𝑆 , 𝑃 𝑠 ∈ 𝓟 , 𝑃 𝑠 ⊂ 𝐸 , 𝑑𝑒𝑛 𝑔𝑐
(𝑒 ) = ∑ 𝑑𝑒𝑛 𝑔𝑐
(𝑠 , 𝑒 )
𝑠 , 𝑒 ∈ 𝑃 𝑠
In Section 1.3, we defined the traffic model as a function with two parameters
𝒯 (d,c). This function predicts the edge congestion based on edge capacity (c) and total
density (d). Finally, the cost of traversing an edge can be calculated (Eq. 5.5). From there,
the cost of traversing a path follows. The first term in the path cost formula (Eq. 5.6)
calculates the delay imposed by the source metering and the second term sums the cost of
the path itself. Note that the cost of an edge changes from one time interval to the next but
each evacuee can be present on an edge at only one particular time interval. Therefore, the
cost of path no longer depends on the time interval (gc). The summation in Eq. 5.6 needs
to know at what time interval each evacuee arrives at each edge to be able to sum up the
correct edge costs. We call this the arrival time of source s to edge e over path P s:
arrival(s,e,P s) ∊ GC. The objective is to minimize the cost of the costliest path (Eq. 5.7).
Eq. 5.5
𝑐𝑜𝑠𝑡 𝒯 , 𝑔𝑐
(𝑒 ) =
𝑖𝑚𝑝 𝑔𝑐
(𝑒 )
𝒯 (𝑑𝑒𝑛 𝑔𝑐
(𝑒 ), 𝑐𝑎𝑝 𝑔𝑐
(𝑒 ))
74
Eq. 5.6
𝑐𝑜𝑠𝑡 𝒯 (𝑃 𝑠 ) = 𝑖𝑛𝑡 (𝑠 ) × 𝑤 (𝑠 )
+ ∑ 𝑐𝑜𝑠𝑡 𝒯 , 𝑔𝑐
(𝑒 )
𝑒 ∈ 𝑃 𝑠 , 𝑔𝑐 = 𝑎𝑟𝑟𝑖𝑣𝑎𝑙 (𝑠 , 𝑒 , 𝑃 𝑠 )
Eq. 5.7
𝐸𝑣𝑐𝑇𝑖𝑚𝑒 = 𝑚𝑎𝑥 { 𝑐𝑜𝑠𝑡 𝒯 (𝑃 𝑠 ) | 𝑃 𝑠 ∈ 𝓟 }, Objective: minimize EvcTime
If two paths share an edge, they are going to affect each other’s traversal cost. In
other words, the evacuation time will increase because of the congestion on the shared
edges. The problem is to find paths for each source point whilst minimizing congestion.
Table 5.1 summarizes all of the other symbols that we use in this chapter.
Table 5.1: Summary of symbols
Symbol Description
V
i
⊂ V Visited vertices set
DV ⊂ V Dirty vertices set
DE ⊂ E Edges with changed costs
g(v) ∊ ℝ+ Cost from source to vertex v
h(v) ∊ ℝ+ h value of vertex v. h value is a lower bound of the cost to destination.
SPT Shortest path tree; also an algorithm that finds such a tree
S’ The set of unprocessed source points
5.3.2 Static Solution
Before we explain our solution to the dynamic evacuation problem, let’s review the static
solution. The interested reader is encouraged to study the previous chapter as it covers more
details about the algorithm. The static problem is very similar to the dynamic problem that
we have formulated. The only difference is that the road network does not change during
evacuation (GC=∅). Figure 5.2 illustrates the CASPER architecture and provides a high-
level description of the process.
75
Figure 5.2: Static CASPER architecture. This diagram demonstrates the major steps of the
CASPER routing process.
Initially, all inputs are loaded: evacuees, shelters, and the traffic model. Then a
separate module called the Capacity-Aware Reverse Map Analyzer (CARMA) is utilized
to build a graph from the GIS data. CARMA is also responsible for building a set of
heuristics on the graph that improves the overall running time. To generate the evacuation
routes, a routing algorithm similar to A* (Hart, Nilsson, and Raphael 1968) is implemented.
CASPER finds the shortest route for each evacuee while considering the predicted traffic
times and car density. Once the route is found, CASPER reserves the route for the
corresponding evacuee and then moves on to the next evacuee. Every time a route is
reserved, the predicted traffic times are changed and consequently the graph heuristics are
invalidated. Because the routing process heavily relies on these heuristics, CASPER gets
slower and slower as it reserves more routes. Therefore it is necessary to refresh these
heuristics. CARMA has a mechanism to detect when a good time to rebuild the heuristics
occurs. After rebuilding the heuristics, CASPER resumes to process more evacuees. This
back-and-forth process between CASPER and CARMA continues until all evacuees are
76
processed. Algorithm 5.1 outlines the CASPER evacuation routing system that solves the
static evacuation problem.
Algorithm 5.1. Static Evacuation Routing
Input: G, S, t, 𝒯
𝓟 ← 𝜙
∀s ∈ S, w(s)>0 do {
3. route P s ← FindEvacuationRoute
𝒯 (G, s, t)
4. 𝓟 ← 𝓟 ∪ {P s}
5. Reserve P s for s. ∀e ∈ P s : den(e) is increased by den(s,e)
6. Update edges cost: ∀e ∈ P s recalculate cost
𝒯 (e)
7. Collect invalidated heuristic values
8. If invalidated heuristic values > 20% {
8.1. CARMA
𝒯 (G, S, t)
9. }
}
Output: 𝓟
CARMA internally builds a shortest path tree (SPT) to perform the required task.
An SPT is a tree rooted at a vertex t. For every vertex s, the path from s to t on the tree is
exactly the shortest path on the graph G. In other words, an SPT is the union of all the
shortest paths that end at the vertex t. CARMA builds the SPT with a single Dijkstra over
the reversed G with t as the starting vertex. Then CARMA updates the heuristic value, h(v)
for all of the vertices, based on their shortest path distances from t (shelter). The
distance(SPT, s, t) function mentioned in Algorithm 5.2 (line 2) is the path cost of s to t on
the tree SPT. CARMA uses the same traffic model and the most up-to-date car densities to
calculate the distances. Lastly it sorts all evacuees based on their estimated shortest path
distance from the shelter in reverse order. This way, the furthest evacuee will be processed
77
next by CASPER. Algorithm 5.2 outlines how CARMA builds the said tree, refreshes the
heuristic values, and sorts evacuees.
Algorithm 5.2. CARMA (short version)
Input: G, S, t, 𝒯
1. Build the shortest path tree: SPT ← BuildSPT
𝒯 (G, t)
2. ∀v ∈ V: h(v) ← distance
𝒯 (SPT, v, t)
3. Sort S (evacuees) descending based on distance to shelter: distance
𝒯 (SPT, s, t), s ∈ S
Output: heuristics
There are two advantages in running CARMA multiple times during the evacuation
routing process: (1) it rebuilds the graph heuristics which improves the overall running
time; and (2) it re-orders evacuees based on their distance to shelters. Conceptually
speaking, rebuilding the heuristic values is like pre-paying for the routing costs in one
batch. That’s why running CARMA statistically helps with the overall running time.
Sorting evacuees often helps with overall evacuation time. One of the key challenges with
evacuation routing is the combinatorial effect of these routes on each other. Every time a
route is reserved it affects the travel time of other routes because it changes the car density
on the graph. This combinatorial effect makes it very difficult to solve the problem
optimally.
5.3.3 Dynamic Shortest Path Tree
As discussed earlier, CARMA is responsible for building and maintaining a shortest path
tree (SPT). It uses the SPT to generate a heuristic value for each vertex (v). CASPER uses
these heuristic values, h(v), to find evacuation routes faster. Every time CASPER reserves
a route for an evacuee, it changes the traffic times on the graph and hence some of the
78
heuristic values become outdated. After a few route reservations, it becomes necessary to
regenerate these outdated heuristic values otherwise CASPER gets very slow. The standard
way to regenerate these values is to build the SPT from scratch and then use it to refresh
all heuristics. That is how we originally implemented CARMA. In this section we discuss
an alternative method to refresh the outdated heuristics.
The majority of the computational work in CARMA is building the SPT. This step
is relatively time consuming. It is also repetitive as not all parts of the graph are always
affected. Usually about 20% of the edges are affected after a few route reservations.
Therefore, the new SPT is going to look mostly like the old one. This problem is called the
dynamic shortest path tree (DSPT) in the computer science literature. It is the problem of
quickly updating an SPT after an edge cost in the corresponding graph is changed. For
example, let’s say we have a graph G and its SPT is built. Each edge in the graph has a cost.
Now let’s say edge e, which is part of the SPT, has a new cost. Because of this new cost,
some of the paths in the SPT are no longer the shortest path so the tree needs to be updated.
Depending on whether the cost of e is increased or decreased we need to use a different
approach. The algorithms that update the tree in the case of an increased cost are called
semi-dynamic and algorithms that can update the tree whether the cost is increased or
decreased are called fully-dynamic.
Ramalingam et al. proposed a fully dynamic SPT incremental algorithm that can
handle edge weight updates (Ramalingam and Reps 1996). For each graph vertex they
maintain a list of distances-to-source based on all outgoing edges. After every edge weight
update, the distances are updated incrementally until the SP tree is re-constructed. Frigioni
79
et al. presented fully dynamic and semi-dynamic SPT algorithms along with their
theoretical proofs (Frigioni, Marchetti-Spaccamela, and Nanni 2000; Frigioni, Marchetti-
Spaccamela, and Nanni 1998; Frigioni et al. 1998). Their recent work, FMN, shows that
SP trees can be maintained in O(logn) time for a group of special graphs and in O(√m logn)
time for general graphs. The reported complexities are per output update. They have also
showed that if insertions or deletions of edges are allowed, then similar amortized bounds
hold. In reported experimental results, it has been shown that while FMN has a lower time
complexity, it is outperformed in most cases by Ramalingam’s algorithm. Chan and Yang
recently presented an in-depth review of fully dynamic and semi-dynamic SPT algorithms
and compared their running times (Chan and Yang 2009). They have also improved and
corrected a known dynamic algorithm, BallString (Narváez, Siu, and Tzeng 2001), and
showed that the corrected version (MBallString) outperforms other DSPT algorithms.
We have decided to use the MBallString algorithm with some minor modifications
so that it fits better with our GIS setup. CARMA initially gets all the changed edges (DE)
with their new cost. Then using the old tree, it finds all the locally affected vertices of these
edges. The locally affected vertices (DV) are vertices for which the shortest paths have
likely changed. In other words, the path from a locally affected vertex to the tree root
contains at least one dirty edge. Let’s call the locally affected vertices dirty and other
vertices clean. All dirty vertices are removed from the tree. Next we look for dirty vertices
that have at least one clean adjacent vertex. They are called boundary vertices (BV). We
enqueue all boundary vertices to a priority queue. Note that leaf vertices are clean otherwise
they must have been removed from the tree. The remainder is very similar to the original
80
SPT algorithm. We dequeue a vertex, process its adjacent vertices, and continue until the
missing parts of the SPT are rediscovered. We generally do not need to enqueue clean
vertices unless we find a lower cost for them than the one in the original SPT. Algorithm
5.3 outlines our fully-dynamic DSPT implementation.
Algorithm 5.3. Fully-dynamic DSPT
Input: G, SPT, 𝒯
1. DE ← ExtractDirtyEdges(G), DE ⊂ E
2. DV ← FindLocallyAffected(SPT, DE), DV ⊂ V
3. SPT’ ← Clone(SPT)
4. SPT’ ← RemoveVertices(SPT’, DV)
5. BV ← FindBoundaryVertices(DV, SPT’), BV ⊂ DV
6. PQ: Newly created priority queue
For each boundary vertex, we find the shortest distance to root from adjacent clean
vertex. This shortest distance is used as the vertex priority.
7. ∀v ∈ BV: Enqueue(PQ, v, distance
𝒯 (SPT, v, t))
8. While PQ ≠ 𝜙 {
8.1. (v, dist) ← Dequeue(PQ)
8.2. SPT’ ← SPT’ + {v}
8.3. ∀u ∈ Adjacent(reverse of G, v), e = (u, v) ∈ E {
8.3.1. newdist ← dist + cost
𝒯 ,gc
(e)
First we check if a fully-dynamic tree reconstruction is needed. If a
better cost for an existing vertex is found then we have to enqueue it.
8.3.2. If u ∈ SPT’ AND newdist < distance
𝒯 (SPT, u, t) then
8.3.2.1. SPT’ ← SPT’ - {u}
8.3.2.2. Enqueue(PQ, u, newdist)
8.3.3. If u ∉ SPT’ then EnqueueOrUpdate(PQ, u, newdist)
8.4. }
9. }
Output: SPT’
CARMA has been programmed to choose the best DSPT method. If there is at least
one edge where the cost is decreased, then the fully-dynamic DSPT algorithm is utilized;
otherwise, the semi-dynamic version is used. The two DSPT algorithms only differ in
vertex rediscovery ( Algorithm 5.3, line 8.3.2). If an edge cost is decreased then the
81
algorithm allows for clean vertices to be visited and enqueued only if the new cost is lower.
In our experiments with different DSPT algorithms, this hybrid implementation generally
has a better running time than that of the static SPT (building the tree from scratch). For
DSPT to be slower than static SPT, there should be at least as many dirty vertices as clean
ones. This case is generally avoided with a good dirty edge ratio.
5.3.4 Iterative Routing
In the previous section, we have shown how a dynamic shortest path tree algorithm can
improve CASPER running time. In this section, we focus on improving final evacuation
time. As discussed earlier, the evacuation routing problem is fundamentally a difficult
problem because of the combinatorial effect of evacuation routes on one another. As
CASPER processes each evacuee in a linear (greedy) manner, there are only a few things
it can do to improve the final evacuation time. It can: (1) use traffic modeling to predict
congestion and avoid over-saturation; (2) re-order evacuees and process the ones further
away from shelter first, and (3) tweak the routing objective function to account for the
global evacuation cost. We have tried the first two methods with the original CASPER
implementation and reported their results in Chapter 4. They are part of the design and
work just fine with the dynamic evacuation problem. The third method (tweaked objective
function) and other non-greedy methods are investigated in this section.
In a traditional shortest path algorithm, one looks among all possible paths to find
the shortest one. To evaluate each path, you have an objective function that calculates the
path cost. The algorithm looks for the path with the minimum cost. Normally in GIS, the
shortest path is the path with the smallest traversal time. Therefore, the objective function
82
calculates the street segment length divided by average speed. We hypothesized that if we
also include the extra cost each path adds to the final evacuation time, we may be able to
reduce the final evacuation time. Every time CASPER finds a route for an evacuee, it
creates additional traffic on the road network and adds more time to overlapping routes. So
the new objective function would calculate the route traversal time plus the extra time it
added to its overlapping routes. After a few simulations, we realized that this new objective
function was not only slowing down CASPER, but that it was also not making any
significant improvement to the final evacuation time.
While it is possible to improve CASPER’s evacuation time with linear or dynamic
programing, such designs will not be scalable and hence not useful for a realistic scenario.
At the same time, the current greedy approach is not providing us with any other option to
marginally improve the final evacuation time. Therefore, we decided to study iterative
algorithms. Minton et al. proposed a heuristic solution to the satisfaction problem that is
faster than a simple backtracking algorithm (Minton et al. 1992). It starts with a random
assignment for all variables in the satisfaction problem. Then a repair method is iteratively
applied until an acceptable solution is found. The repair method follows a heuristic: at each
repair step it minimizes the conflict among individual variables. For example, if one
variable in the satisfaction problem is conflicting with many other variables, the repair
method first re-assigns a different value to that variable. They showed that this conflict-
minimizing heuristic is significantly better than previous works including backtracking.
The evacuation routing problem is not a satisfaction problem and the idea of a conflict is
not clear but these are not fundamental differences.
83
In another work Li et al. proposed a novel building evacuation algorithm based on
game theory and Monte Carlo optimization (W. Li et al. 2015). They modeled the building
evacuation as an n-person non-cooperative game. First the distance to each exit is
calculated for all rooms. Then the payoff costs for individuals are calculated based on
corridor congestion. Next, they iteratively assign evacuees to exit routes until the system
reaches the Nash equilibrium. This algorithm requires many calculations on multiple paths
and hence it is not immediately scalable to our urban evacuation problem. We hypothesized
that the idea of competing evacuees in a building evacuation is similar to conflicting
variables in a satisfaction problem and can be utilized for an urban evacuation problem.
Before we lay out the iterative design, we need a few more definitions. First, we
need a definition for two conflicting or competing paths. Two paths that share many edges
indicates that they are competing over the same region of the graph. This kind of
competition adds to the complexity of the evacuation problem. Therefore, the conflict of
two paths is defined according to how much they overlap with each other. The overlap is
calculated based on the cost of shared edges between the two paths (Eq. 5.8). Our
experiments showed that a 40% overlap is a good indication that two paths are conflicting.
We also learned from the experiments that certain paths do not have the potential to be
improved. We identify these paths by comparing the final path cost, the cost immediately
after reservation, and the cost predicted by the SPT. The SPT contains all costs to the
destination so it can predict the cost of a path even before it is found. It will be a lower
bound for the path cost. We also calculate the cost immediately after the path is reserved.
This is also always going to be lower than the final path cost. If any of these differences
84
for a path is at least 15% of the final evacuation time then this path has a disadvantage and
can likely be improved. Eqs. 5.8 and 5.9 show how we calculate the disadvantage and
conflict ratios.
Eq. 5.8
𝐶𝑜𝑛𝑓𝑙𝑖𝑐𝑡 𝒯 (𝑃 1
, 𝑃 2
)
=
∑ (𝑐𝑜 𝑠 𝑡 𝒯 , 𝑔𝑐
(𝑒 ))
𝑒 ∈𝑃 1
∩𝑃 2
∑ (𝑐𝑜𝑠𝑡 𝒯 , 𝑔𝑐
(𝑒 ))
𝑒 ∈𝑃 1
⁄ , 𝑔𝑐 : 𝑐𝑡𝑒
Eq. 5.9
𝐷𝑖𝑠𝑎𝑑𝑣𝑎𝑛𝑡𝑎𝑔𝑒 𝒯 (𝐸𝑣𝑐𝑇𝑖𝑚𝑒 , 𝑃 𝑠 ) =
𝑚𝑎𝑥 (𝑅𝑒𝑠𝑒𝑟𝑣𝑒𝐶𝑜𝑠𝑡 𝒯 (𝑃 𝑠 ) − 𝐷𝑖𝑠𝑡𝑎𝑛𝑐𝑒 𝒯 (𝑆𝑃𝑇 , 𝑠 , 𝑡 ), 𝐶𝑜𝑠𝑡 𝒯 (𝑃 𝑠 ) − 𝑅𝑒𝑠𝑒𝑟𝑣𝑒𝐶𝑜𝑠𝑡 𝒯 (𝑃 𝑠 )
)
𝐸𝑣𝑐𝑇𝑖𝑚𝑒
Algorithm 5.4 outlines the iterative approach for solving the evacuation routing
problem. Initially all global variables and constants are set. For the first round, the greedy
CASPER algorithm finds evacuation routes for all evacuees. We then look for paths with
a disadvantage and select the corresponding evacuees. We also select their conflicting
evacuees. Lastly, the selected evacuees (S’) are sorted according to their path cost (distance
to hotel and/or shelter) such that those with the longest path get processed first. On the next
iteration, greedy CASPER finds paths for the selected evacuees and merges new results
with the non-selected paths. The iteration continues until the evacuation time can no longer
be decreased.
Algorithm 5.4. Iterative CASPER
Input: G, S, t, 𝒯
1. S’ ← Clone(S)
2. 𝓟 ← 𝜙
3. Global variables: EvcTime ← ∞, MaxSize ← |S|
4. Constants: ItrRatio ← 0.6, DisadvantageRatio ← 0.15, ConflictRatio ← 0.4
After initializing some variables, we start the iteration loop. At each step we call the
greedy CASPER with the selected evacuees.
85
5. While S’ ≠ 𝜙 {
5.1. New𝓟 ← GreedyCASPER
𝒯 (G, S’, t)
5.2. PrevEvcTime ← EvcTime
5.3. EvcTime ← max { cost
𝒯 (P
s
) | P
s
∈ 𝓟 ⋃ New𝓟 }
5.4. If EvcTime ≤ PrevEvcTime then 𝓟 ← 𝓟 ⋃ New𝓟 ELSE terminate iteration
5.5. MaxSize ← MaxSize * ItrRatio
5.6. S’ ← 𝜙
At this step we select the evacuees that can potentially be improved
5.7. ∀s ∈ S, ∃P
s
∈ 𝓟 {
5.7.1. If Disadvantage
𝒯 (EvcTime, P
s
) ≥ DisadvantageRatio AND |S’| ≤ MaxSize {
If the difference between predicted cost, reserved cost, and final cost for a
path is larger than 15% of EvcTime then it’s selected for iteration. Paths
that overlap with it by more than 40% are selected too.
5.7.1.1. S’ ← S’ ⋃ {s} ⋃ { s 2 ≠ s | Conflict
𝒯 (P
s
, P
s
2
) ≥ ConflictRatio }
5.7.2. }
5.8. }
5.9. Sort S’ by cost
𝒯 (P
s
2
)
The evacuee with the longest path will be processed first in the next iteration
6. }
Output: 𝓟
It is worth mentioning that this iterative design wraps around the greedy CASPER.
Therefore, all previous enhancements are included (line 5.1). The new paths at each step
are added to the previous paths with a union (line 5.4). The union guarantees that we keep
at most one path for each evacuee. The iteration is terminated before merging new paths
only if EvcTime is more than before. At line 5.5 an upper bound is set for the number of
selected evacuees. This bound is exponentially decreased at every step by a factor less than
1. This guarantees that the algorithm terminates in at most O(|S|) operations, the same as
the static CASPER.
86
5.3.5 Dynamic CASPER
In the previous sections, two extensions to the CASPER algorithm have been introduced.
One made CASPER faster and the other helped it find lower evacuation times. More
importantly they both made CASPER flexible to a changing environment. The new DSPT
implementation enables CARMA to quickly update its internal data structure after any kind
of road network change. We only talked about changes in traffic flow but it could also be
a change in the number of lanes and/or the average traversal speed. The iterative design
made the entire system a modular algorithm. You can feed in a set of evacuation routes and
have the iterative CASPER improve the routes. The same iterative algorithm can also be
used to improve routes after a change in the road network. Once a change in the network
is detected, the affected paths are identified and the corresponding evacuees are marked as
disadvantaged. Then all inputs are fed back into iterative CASPER for processing. New
paths will be found based on updated heuristics and the entire system is optimized again.
DCASPER is essentially a proper integration of these enhancements in a dynamic
environment.
Figure 5.3 demonstrates how DCASPER solves the dynamic evacuation routing
problem with a modular design. We assume that the changes to the road network are not
initially known. Therefore, the beginning steps of DCASPER are similar to CASPER with
a static problem. DCASPER solves the problem like any static evacuation routing problem
and outputs the routes. Next, we read in the first set of network changes. For example, one
network change could be that 20 minutes after the evacuation is started, a portion of a
freeway is modified to allow a higher speed limit but some of its ramps are now closed. To
87
model this we recalculate the cost of edges associated with the freeway. We also set the
edge cost of closed ramps to infinity. The new information is first passed to CARMA to
update the graph. Since some edge costs are being decreased, a fully-dynamic DSPT is
required to update the heuristics. Next we move all evacuees on their paths for 20 minutes.
This step is optional. It is only there to simulate a realistic scenario. Lastly, we invalidate
all paths that cross the closed ramps. The remaining paths are fed back to CASPER to be
reprocessed.
Figure 5.3: Dynamic CASPER architecture. This diagram demonstrates how a modular design
improved the original CASPER algorithm in order to solve the dynamic evacuation routing
problem.
As DCASPER is processing each change, it also needs to track evacuee locations
and their partial paths. It needs to know if an evacuee has already reached a shelter, is
trapped in a disconnected sub-graph, or still needs to be routed at the next step. At the end
it is required to reassemble partial paths to build the final routes. Lastly, it is necessary to
88
calculate the final evacuation times based on correct edge costs and traffic densities at the
appropriate interval. To be able to compare DCASPER with a baseline we have created
four different variations of the algorithm:
DisableDCASPER : This version assumes that there are no network
changes. It is exactly like the original CASPER (the static algorithm). The
results will give us an understanding of how much the network dynamism is
affecting the evacuation time and the algorithm running time.
SimpleDCASPER : Similar to DisableDCASPER but it assumes all
network changes occur at the beginning and will continue to exist forever. By
doing so, we are effectively giving SimpleDCASPER some additional
knowledge about the future of the road network. Since this information is
known at the beginning, SimpleDCASPER can avoid all of them at once. There
is no need to iterate over all network intervals. The results from this version will
help us understand the best possible scenario achievable with static CASPER.
FullDCASPER : This version respects all network changes and their
start times. At each interval, it runs a complete CASPER from scratch. After
each network change it moves all evacuees, deletes all paths and heuristics,
updates the graph, and then runs itself again. Since this version does not rely on
any of the enhancements, it serves as our naïve approach.
SmartDCASPER : This is the new version we have discussed in this
section. It can quickly update its internal data structure and then only
reprocesses the affected paths.
89
DCASPER is a complete sub-optimal algorithm. It can find a path for each evacuee while
satisfying all network changes if such a path exists. However, it is not guaranteed that the
final evacuation plan would have the lowest possible evacuation time.
5.3.6 Complexity Analysis
We already know that the static CASPER has a running time similar to the Dijkstra
algorithm: O(|S| × (|E| + |V|log(|V|))). Adding DSPT to CARMA does not change its
computational complexity. In the worst case scenario, the entire tree still needs to be
traversed which is the same as running a single Dijkstra. Even though the iterative design
can slow down CASPER, it does not change its computational complexity either. Since the
ItrRatio is less than 1, at each iteration, not all evacuees are processed. More specifically,
at each iteration we have:
Eq. 5.10
# 𝑜𝑓 𝑝𝑟𝑜𝑐𝑒𝑠𝑠𝑒𝑑 𝑒𝑣𝑎𝑐𝑢𝑒𝑒𝑠 𝑎𝑡 𝑖𝑡𝑒𝑟𝑎𝑡𝑖𝑜𝑛 𝑖 = |𝑆 | × 𝐼𝑡𝑟𝑅𝑎𝑡𝑖𝑜 𝑖 , 𝐼𝑡𝑟𝑅𝑎𝑡𝑖𝑜 < 1
Eq. 5.11
𝑇𝑜𝑡𝑎𝑙 𝑝𝑜𝑠𝑠𝑖𝑏𝑙𝑒 𝑖𝑡𝑒𝑟𝑎𝑟𝑖𝑜𝑛𝑠 : |𝑆 | × 𝐼𝑡𝑟𝑅𝑎𝑡𝑖𝑜 𝑖 𝑚𝑎𝑥 ≤ 1 ⇒
𝑖 𝑚𝑎𝑥
≥
𝑙𝑜𝑔 (
1
|𝑆 |
)
𝑙𝑜𝑔 (𝐼𝑡𝑟𝑅𝑎𝑡𝑖𝑜 )
= 𝑙𝑜𝑔 𝐼𝑡𝑟𝑅𝑎𝑡𝑖𝑜 (
1
|𝑆 |
)
Eq. 5.12
𝑇𝑜𝑡𝑎𝑙 𝑝𝑟𝑜𝑐𝑒𝑠𝑠𝑒𝑑 𝑝𝑎𝑡 ℎ𝑠 = ∑ |𝑆 | × 𝐼𝑡𝑟𝑅𝑎𝑡𝑖𝑜 𝑖 = |𝑆 | ×
𝐼𝑡𝑟𝑅𝑎𝑡𝑖𝑜 𝑖 𝑚𝑎𝑥 −
1
𝐼𝑡𝑟𝑅𝑎𝑡𝑖𝑜 1 −
1
𝐼𝑡𝑟𝑅𝑎𝑡𝑖𝑜 𝑖 𝑚𝑎𝑥 𝑖 =0
= |𝑆 | ×
1
|𝑆 |
−
1
𝐼𝑡𝑟𝑅𝑎𝑡𝑖𝑜 1 −
1
𝐼𝑡𝑟𝑅𝑎𝑡𝑖 𝑜 =
|𝑆 | − 𝐼𝑡𝑟𝑅𝑎𝑡𝑖𝑜 1 − 𝐼𝑡𝑟𝑅𝑎𝑡𝑖𝑜 = 𝑂 (|𝑆 |)
The total number of processed paths is linear to the total number of evacuees
(Eq. 5.12). Hence, the iterative CASPER has the same complexity as the static CASPER.
90
To solve the dynamic evacuation problem, DCASPER needs to adjust routes every time
there is a new change. We have a total of |GC| changes in the road network. Therefore we
can express DCASPER complexity as:
Eq. 5.13
𝐷𝐶𝐴𝑆𝑃𝐸𝑅 𝑐𝑜𝑚𝑝𝑙𝑒𝑥𝑖𝑡𝑦 = 𝑂 (|𝐺𝐶 | × |𝑆 | × (|𝐸 | + |𝑉 |𝑙𝑜𝑔 (|𝑉 |)))
5.4 Results
In this section, we present our experimental results and a comparison with static CASPER.
The evacuation program is implemented with C++ as a single-threaded plug-in for ArcGIS
Desktop® (Shahabi 2015a). The source code is also publicly available (Shahabi 2015b).
Everything from loading data, storage, accessing the transportation network, and
visualization is abstracted by the ArcGIS API®. The implementation supports simple turn
restrictions, multiple destination points, different impedance metrics (time, length, etc.),
multiple traffic models, timed dynamic network changes, and shelter capacity. All the
experiments were performed on a dedicated 64-bit Microsoft Windows® 8 workstation
with Intel Xeon® CPU (3.2 GHz) and 16 GB of memory. The reported CPU times and
memory usages are that of the evacuation tool itself and not the entire software package.
Times to load inputs, visualize, and store the results are excluded.
5.4.1 SoCal Fire Setup
In order to test different aspects of the algorithm, we have created a series of realistic
evacuation scenarios. The 10 southern-most counties of California starting with San Luis
Obispo County in the north and concluding with San Diego and Imperial counties in the
south were used. The resulting graph, which included both highways and local roads, has
about 1,850,000 directional edges and 750,000 vertices. We used the wildfire records from
91
2008 and 2009 to create eight different hypothetical wildfire polygons as the evacuation
zones. Then with some buffer, we created another set of hypothetical polygons around the
wildfire polygons to serve as the safe zone. Each wildfire polygon has at least one
corresponding safe zone polygon. For each wildfire polygon we have also created another
hypothetical polygon to represent the dynamic changes to the road network. All roads
inside a dynamic change polygon are set to get fully or partially blocked 10-30 minutes
after the evacuation starts. Figure 5.4 visualizes all three types of zones for each county.
To get the shelters, we randomly selected some of the road intersections inside the
safe zones. The evacuees are all the people who live inside a wildfire polygon. We used
the 2010 Census Block Group dataset to get the locations and population counts for the
evacuees. Commonly, wildfires happen in rural areas where population density is low. This
would not allow us to test the DCASPER scalability and performance. Therefore, we have
extended wildfire polygons and also added three additional hypothetical wildfire polygons
in highly populated areas: Los Angeles downtown, Santa Ana, and San Diego downtown.
Finally we have merged smaller areas to get even bigger evacuation scenarios. In total we
generated 13 evacuation scenarios that cover a vast geographical area, different population
densities, road network structures, and dynamism. Table 5.2 lists these 13 scenarios along
with their important attributes. Each scenario has a short name, at least one wildfire, safe
zone, and dynamic change polygon. For each of these polygons, the total area and other
information is listed as well.
92
Figure 5.4: Map of southern California with realistic wildfire evacuation zones
Table 5.2 is split into two parts: urban and rural scenarios. Each part is sorted
according to wildfire size. For each scenario, the evacuating neighborhoods is what the
routing algorithm receives as S. The ‘vehicle count’ gives us an idea of how much traffic
this scenario would generate. For the rural areas we set the dynamic polygons to
permanently block the intersecting roads. As an example, for the Santa Barbara wildfire
scenario (SB) a dynamic polygon is blocking 19 km of road 10 min after the evacuation
starts and continues until infinity. For urban scenarios, the dynamic polygons are set to
decrease the number of lanes by half for a finite time. These evacuation scenarios give us
a diverse set of experiments to test different aspects of DCASPER. Additionally, we can
generate more scenarios by simply changing the initial vehicle density or traffic model.
93
Table 5.2: All wildfire evacuation scenarios along with the selected population, shelters, and
dynamic changes
Scenario
Name
Wildfire Safe Zone Dynamic Change
Area
(km
2
)
Evacuee
Count
Vehicle
Count
Area
(km
2
)
Shelter
Count
Area
(km
2
)
Type
Effective
Time (min)
Road
Length
(Km)
LADT* 305 1,050 368,505 194 761 2.5 ½ Lanes 15-300 29
SantaAnaDT 429 750 305,741 334 1,156 2.1 ½ Lanes 20-300 16
SDDT 510 720 259,136 494 372 25.8 ½ Lanes 20-300 23
All_DT 1,245 2,520 933,382 1,023 2,289 30.3 ½ Lanes 15,20-300 68
SB 277 120 34,234 669 69 2.0 Road Block 10-∞ 19
SB_Ventura 651 149 47,347 2,467 690 17.2 Road Block 10-∞ 156
Riverside 2,069 252 123,122 2,629 1,831 23.1 Road Block 20-∞ 152
LA 2,364 571 210,254 1,452 1,519 7.7 Road Block 10-∞ 153
SD 3,002 109 48,364 3,910 1,386 30.1 Road Block 10,15-∞ 305
LowerSoCal 5,071 361 171,486 6,539 3,217 53.2 Road Block 10-∞ 458
Kern_SB 7,983 137 38,481 3,532 1,189 29.7 Road Block 10-∞ 139
UpperSoCal 10,721 737 261,848 5,573 3,046 52.6 Road Block 10-∞ 429
All_Rural 15,792 1,098 433,334 12,112 6,263 105.7 Road Block 10,15,20-∞ 887
* DT stands for downtown and refers to densely populated areas as opposed to rural areas
5.4.2 DSPT Implementation
Now that we have established all of the test cases, we present the comparison between both
SPT algorithms. One creates the tree from scratch and the other dynamically updates the
tree with the DSPT algorithm. Aside from the SPT implementation, we can also change
the edge dirtiness ratio which affects the number of times CARMA updates the tree in a
single scenario. The lower the ratio, the more tree updates. We can also choose to sort
evacuees after each DSPT run or only once at the initial CARMA loop. In total this gives
us six different setups. Table 5.3 lists these six setups. The Dspt prefix in the setup name
indicates the dynamic SPT implementation and the CDspt prefix indicates dynamic SPT
94
implementation with continuous evacuee sort. C0X prefix indicates the edge dirtiness ratio.
For the sake of this comparison, we ignored all dynamic polygons and will only do one
iteration (greedy CASPER) to solve the static problem.
Table 5.3: Running time and evacuation improvement for different SPT implementations
Setup
Average Memory
Usage (MB)
Average EvcTime
Improvement
Average Running
Time Speed Up
Average Running
Time (min)
CASPER_C02 1,311.72 69.51% 4.35% 22.819
CASPER_C01 1,366.56 54.53% 4.46% 23.458
DsptCASPER_C02 1,407.33 69.51% 6.18% 21.304
CDsptCASPER_C02 1,335.61 55.38% 7.68% 20.826
DsptCASPER_C01 1,499.72 54.83% 9.51% 21.039
CDsptCASPER_C01 1,519.06 42.46% 9.73% 20.969
In this experiment, the average of the running and final evacuation times are
calculated over 18 test cases. They consist of all nine rural scenarios each with two different
initial car densities. The EvcTime improvement is calculated as the percentage of
improvement one setup has over the one with the worst evacuation time in each scenario.
Higher EvcTime improvement percentages point to better evacuation plans. We used the
same calculation method for the speed up percentage. Higher speed up percentages point
to faster algorithms. As you can see from Table 5.3, CDsptCASPER has the lowest running
time. The CDsptCASPER_C01 variation has an average of 9.7% speed up compared to the
slowest setup or on average 2.5 minutes faster than CASPER_C02. Since CDspt sorts
evacuees every time, it ends up with a relatively smaller tree; hence, it is slightly faster
than Dspt. We observe that all CDspt implementations on average have higher final
evacuation times but better running times. Overall, all four DSPT implementations are
95
never slower than previous methods and in most cases can provide a noticeable speed up.
Additionally, all DSPT implementations require more memory because they need to
maintain the tree structure.
5.4.3 Selfless Routing
As discussed earlier, CASPER finds evacuation routes one at a time. Each routing
optimization is performed completely selfish. We hypothesized that if we modify the
routing objective to be a selfless function, we might get a better result. To test this idea, we
experimented with a selfless objective function that would consider the extra cost each
evacuee is imposing on the road network. Table 5.4 demonstrates our findings. The table
is sorted by average speed up. The S1 postfix indicates the selfless routing and the S0
postfix indicates the selfish routing. There is no noticeable difference between EvcTime
improvements between the two objective functions. Furthermore, the selfish variant has
slightly better maximum EvcTime Improvement and faster running time.
Table 5.4: Running time and evacuation improvement for two different routing objective
functions
Setup
Average
Memory
Usage (MB)
Average
EvcTime
Improvement
Max EvcTime
Improvement
Average
Running
Time Speed
Up
Average
Running
Time (min)
CASPER_S1 707.89 4.53% 20.13% 10.58% 13.648
DsptCASPER_S1 783.69 4.48% 20.13% 14.19% 13.332
CDsptCASPER_S1 817.28 3.99% 22.32% 14.28% 13.646
CASPER_S0 485.55 4.64% 26.31% 15.08% 13.071
CDsptCASPER_S0 564.50 3.62% 21.62% 18.54% 12.522
DsptCASPER_S0 536.92 4.64% 26.64% 19.15% 12.484
96
5.4.4 Iterative Design
In order to test the iterative CASPER, we started with all the 13 wildfire cases each with
three different initial car densities. That would give us 39 scenarios. Of those we removed
any scenario that was too fast to measure and also scenarios that had unusually high
evacuation times. That left us with 32 scenarios. We then created 20 different variations of
CASPER based on selfishness choice, edge dirtiness ratio, SPT implementation, evacuee
sorting policy, and iterative design. The resulting 640 experiments have been statistically
measured similar to previous experiments. Table 5.5 summarizes the measured average
improvements and speed ups. The table is sorted by average EvcTime improvement. The
Itr and CItr prefixes indicate the iterative design. The CItr prefix specifies the continuous
evacuee sort policy. Both iterative CASPER implementations have the faster DSPT
implementation embedded in them.
There is a clear distinction between the iterative CASPER and the non-iterative
CASPER both in running and evacuation time. As predicted, iterative CASPER is slower
by a constant factor. The measured average running time is almost twice that of the non-
iterative CASPER. Similarly, non-iterative CASPER implementations have an average
50% speed up compared to iterative ones. Iterative CASPER also uses more memory
because it needs to maintain and update more than one path per evacuee. Both ItrCASPER
and CItrCASPER performed well with different evacuation scenarios and created relatively
better routes. On average, CItrCASPER improved the EvcTime by 11%.
97
Table 5.5: Summary of running time and evacuation improvement for all five different static
CASPER implementations
Setup
Average
Memory
Usage (MB)
Average
EvcTime
Improvement
Max EvcTime
Improvement
Average
Running Time
Speed Up
Average
Running Time
(min)
CDsptCASPER 690.89 3.81% 22.32% 53.17% 13.084
DsptCASPER 660.30 4.56% 26.64% 53.32% 12.908
CASPER 596.72 4.58% 26.31% 51.20% 13.360
ItrCASPER 831.69 10.68% 30.83% 20.32% 23.354
CItrCASPER 857.73 11.15% 32.28% 18.39% 22.851
Another interesting observation is that continuously sorting evacuees negatively
affects non-iterative CASPER. However it is playing in favor of the iterative CASPER.
This suggests that the iterative design is no longer sensitive to how evacuees are initially
ordered and how they are sorted throughout the process. Overall, it comes down to
algorithm speed versus route quality. We believe the value of a good evacuation plan far
outweighs the increase in running time. Therefore, we recommend the Iterative CASPER
to solve the evacuation routing problem.
5.4.5 Dynamic Environment
Thus far we have ignored the dynamic polygons in our experiments and only focused on
the static evacuation problem. Now that we have identified each algorithm’s strengths and
weaknesses, we can present the results for the dynamic evacuation routing problem. As
defined earlier, there are four different variations of DCASPER. In order to compare their
results, we have selected all 13 wildfire cases each with three different initial car densities.
That would give us 39 test cases. Of those we removed any scenario that where too fast to
measure. That left us with 37 scenarios. Given that we have four different variations of
98
DCASPER, we end up with 148 experiments. Table 5.6 presents the average performance
and quality of the said experiments. Additionally, the table reports the average number of
stuck evacuees. Since the dynamic changes can happen at any time and any location, there
is always the possibility that some evacuees get enclosed by a polygon and as a result get
completely cut off from the road network. We call them stuck evacuees.
Table 5.6: Running time and evacuation improvement for all four different DCASPER
implementations
Setup
Average
Memory
Usage (MB)
Average
EvcTime
Improvement
Average
EvcTime
Average
Running
Time Speed
Up
Average
Running
Time (min)
Average
No. of
Stuck
Evacuee
SmartDCASPER 1,102.89 11.97% 158.02 23.42% 8.312 3.35
DisableDCASPER 1,021.86 8.84% 170.64 42.13% 6.709 0.00
SimpleDCASPER 1,130.62 7.30% 171.46 30.46% 6.873 0.81
FullDCASPER 1,111.32 4.96% 393.04 10.40% 9.714 3.38
We have selected slightly higher initial car densities compared to the iterative
experiment for two reasons to: (1) avoid running the same exact experiments; and (2)
generate scenarios with relatively lower traffic congestion. Let’s say we have a dynamic
polygon that is changing parts of the network. DCASPER detects the change and has to go
back and quickly update affected routes using its previous knowledge of the graph. If there
is high traffic congestion, it means that many routes need to be updated. It is as if
DCASPER is solving the problem from scratch. While this is OK, it will not allow us to
study the performance of different DCASPER variations. For the same reason, we have
also created small dynamic polygons because we wanted only a small portion of the graph
to change. Another advantage of having small dynamic polygons is that we’ll have less
99
stuck evacuees. This is done not to simplify the problem for DCASPER but to make it
possible to study DCASPER.
DisableDCASPER is the only setup that has no stuck evacuee. The reason is that
DisableDCASPER, by definition, ignores the dynamic polygons. This is an entirely
unrealistic dynamic solver that we have made for comparative purposes (i.e. as ground
truth). For the same reason, DisableDCASPER is the fastest algorithm. SimpleDCASPER
is also an unrealistic solver because it knows about all the dynamic polygons in advance.
This gives it an unfair advantage over the other setups. Because of this extra knowledge,
most evacuees will not get stuck as they follow their paths. However, if a dynamic polygon
completely cuts off an evacuee’s source location (e.g. a neighborhood) then it will get
stuck. As a result, SimpleDCASPER does have a non-zero but a small average number of
stuck evacuees. Both DisableDCASPER and SimpleDCASPER have relatively low
running times because they do not need to dynamically adjust the evacuation routes after
each dynamic change.
Both SmartDCASPER and FullDCASPER are realistic solvers. They both consider
all dynamic polygons and have to adjust their routes after the network changes are detected.
The only difference between them is that FullDCASPER recreates all evacuation routes
from scratch while SmartDCASPER only updates affected evacuation routes. Additionally,
SmartDCASPER has access to the previous tree, heuristic values, and original evacuation
routes and can use them to update affected paths faster. The experiments do confirm that
SmartDCASPER has indeed lower running time than FullDCASPER. These experiments
also show that SmartDCASPER is producing better evacuation plans than FullDCASPER
100
with lower EvcTimes. One possible explanation is that as evacuees are moving toward
shelters, there are less unique routes left for them. Less unique routes means the
combinatorial characteristic of the problem is intensified. Therefore, the problem is harder
to optimize. Since FullDCASPER solves the problem from scratch after every dynamic
event, it may not find the same good routes it itself found in the previous iteration. Overall,
given that we generally do not have any knowledge of future changes to the road network
during disaster events, it is best to use SmartDCASPER to generate dynamic evacuation
routes for the endangered population.
5.5 Conclusions
In this chapter we introduced the dynamic evacuation problem and provided several
possible solutions and compared their performance in terms of running time and evacuation
plan quality. The proposed algorithm is an enhanced version of what we have studied in
the previous chapter. The final design can generate and maintain evacuation routes in a
dynamic environment and it does not need to know the changes in advance. The final
product of this dissertation has been made publicly available. We hope that this work makes
a positive impact on the survival of evacuees in any future disaster.
101
CHAPTER 6: CONCLUSIONS
6.1 Summary
Overall, in this dissertation, we have studied the taxonomy of evacuation planning, pointed
out some of the major shortcomings in evacuation routing and provided several solutions
to the problems. In Chapter 1 the problem is introduced, motivated, and defined. We mainly
focused on natural disasters to talk about evacuation, for example, tsunami and wildfires.
The same analogies could have been used with man-made disasters like a terrorist attack.
In Chapter 2, the evacuation planning problem has been studied and broken down into
smaller manageable sub-problems. The discussed taxonomy also provided the strong
relationships between different sub-problems and identified some of the concerns that are
currently not fully answered. This should provide a clear path for future researchers
interested in urban evacuation routing. Chapter 2 also provided a general overview of
related works in evacuation routing and highlighted those that can potentially be used to
solve the routing problem in large scale. Chapter 3 simplified the evacuation routing
problem into the fastest path problem and detailed one solution that could function in a GIS
setup. It also overviewed some of the existing algorithms to efficiently solve realistic
driving direction queries.
After defining the problem and studying the related works, Chapter 4 built upon the
fundamental path finding theory and developed the CASPER algorithm to efficiently find
all evacuation routes. This chapter also formulated what a traffic model should do in an
evacuation setup and provided a simulation framework that one can test if a traffic model
behaved realistically in that scenario. Chapter 5 re-defined the evacuation routing problem
102
to also include scenarios whereby the road network changes as the evacuation is happening.
Because both CASPER and CARMA had strong ties to the road network (graph) they both
had to be updated with more flexible internal algorithms. As a result a new algorithm,
DCASPER, was developed that is both faster and can generate better routes in a static
environment. It is also capable of handling road network changes as they are reported in a
timely manner. It provides the emergency personnel with several options as to which routes
should be re-processed. The chapter also reported experimental results and highlighted the
advantages and disadvantages of each choice.
6.2 Future Work
While some natural disasters like tsunami do not generally change the road network as they
occur, many other types of man-made or natural disasters do. Wildfire, floods, earthquakes,
or terrorist attacks can all affect the urban infrastructure. Therefore, it is important to have
a system that can elastically adjust to these changes and inform the citizens of the changes
to roads and evacuation routes in a timely manner. We are generally unaware of dynamic
changes to the road network until they materialize. For example during a post-earthquake
evacuation, we do not know if a bridge will survive or collapse. But maybe we can consider
this uncertainty. Also during a flood evacuation, we can probably predict which way the
flood is moving so we can use this extra knowledge in our model. These uncertainties and
projections about the road network can perhaps direct future research in dynamic
evacuation routing.
Another unanswered question regarding dynamic evacuation routing is the
existence of temporary shelters and the ability to schedule evacuees either at source or at
103
these temporary locations to further improve the traffic flow. The idea of assuming capacity
for graph vertices has indeed been studied before but it has never been mixed with traffic
modeling in a dynamic environment. Obviously these are difficult problems to solve
individually let alone the challenge of integrating them all into one super solver. But it will
be possible in the near future, since we will soon have smart cars capable of evacuating
citizens to safety autonomously.
104
REFERENCES
Barron, James. 2011. “With Hurricane Irene Near, 370,000 in New York City Get
Evacuation Order.” New York Times, August.
http://www.nytimes.com/2011/08/27/nyregion/new-york-city-begins-evacuations-
before-hurricane.html?_r=2&pagewanted=all.
Bast, Holger, Stefan Funke, Peter Sanders, and Dominik Schultes. 2007. “In Transit to
Constant Time Shortest-Path Queries in Road Networks.” In SIAM.
Bellomo, N., M. Delitala, and V . Coscia. 2002. “On the Mathematical Theory of
Vehicular Traffic Flow I: Fluid Dynamic and Kinetic Modelling.” Mathematical
Models and Methods in Applied Sciences 12 (12): 1801–43.
doi:10.1142/S0218202502002343.
Boroujerdi, Ali, and Jeffrey Uhlmann. 1998. “An Efficient Algorithm for Computing
Least Cost Paths with Turn Constraints.” Information Processing Letters 67 (6).
Elsevier: 317–21. doi:10.1016/S0020-0190(98)00134-3.
Boscoe, Francis P, Christopher J Johnson, Kevin A Henry, Daniel W Goldberg, Kaveh
Shahabi, Elena B Elkin, Leslie K Ballas, and Myles Cockburn. 2011. “Geographic
Proximity to Treatment for Early Stage Breast Cancer and Likelihood of
Mastectomy.” Breast (Edinburgh, Scotland) 20 (4). Elsevier Ltd: 324–28.
doi:10.1016/j.breast.2011.02.020.
Chan, Edward P.F., and Yaya Yang. 2009. “Shortest Path Tree Computation in Dynamic
Graphs.” IEEE Transactions on Computers 58 (4): 541–57.
doi:10.1109/TC.2008.198.
105
Chen, Xuwei, John W. Meaker, and F. Benjamin Zhan. 2006. “Agent-Based Modeling
and Analysis of Hurricane Evacuation Procedures for the Florida Keys.” Natural
Hazards 38 (3): 321–38. doi:10.1007/s11069-005-0263-0.
Chiu, Yi-Chang. 2004. “Traffic Scheduling Simulation and Assignment for Area-Wide
Evacuation.” In The Seventh International IEEE Conference on Intelligent
Transportation Systems (IEEE Cat. No.04TH8749), 537–42. IEEE.
doi:10.1109/ITSC.2004.1398957.
Chiu, Yi-Chang, Hong Zheng, Jorge Villalobos, and Bikash Gautam. 2007. “Modeling
No-Notice Mass Evacuation Using a Dynamic Traffic Flow Optimization Model.”
IIE Transactions 39 (1): 83–94. doi:10.1080/07408170600946473.
Church, Richard, and Thomas J. Cova. 2000. “Mapping Evacuation Risk on
Transportation Networks Using a Spatial Optimization Model.” Transportation
Research Part C: Emerging Technologies 8 (1-6): 321–36. doi:10.1016/S0968-
090X(00)00019-X.
Cova, Thomas J. 1999. “GIS in Emergency Management.” In Geographical Information
Systems: Principles, Techniques, Applications, and Management, edited by P.A.
Longley, D.J. M.F. Goodchild, and D.W. Rhind Maguire, 845–58. New York: John
Wiley & Sons.
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.134.9647&rep=rep1&typ
e=pdf.
Cova, Thomas J., Philip E. Dennison, Tae H. Kim, and Max A. Moritz. 2005. “Setting
Wildfire Evacuation Trigger Points Using Fire Spread Modeling and GIS.”
Transactions in GIS 9 (4): 603–17. doi:10.1111/j.1467-9671.2005.00237.x.
106
Cova, Thomas J., and Justin P. Johnson. 2002. “Microsimulation of Neighborhood
Evacuations in the Urban - Wildland Interface.” Environment and Planning A 34
(12): 2211–29. doi:10.1068/a34251.
Demiryurek, Ugur, Farnoush Banaei-Kashani, Cyrus Shahabi, and Anand Ranganathan.
2011. “Online Computation of Fastest Path in Time-Dependent Spatial Networks.”
In Advances in Spatial and Temporal Databases, 0238560:92–111. Springer Berlin
Heidelberg. doi:10.1007/978-3-642-22922-0_7.
Dijkstra, E.W. 1959. “A Note on Two Problems in Connexion with Graphs.” Numerische
Mathematik 1 (1). Springer: 269–71.
http://www.springerlink.com/index/uu8608u0u27k7256.pdf.
Ertl, Gerhard. 1998. “Shortest Path Calculation in Large Road Networks.” OR Spektrum,
15–20.
Esri. 2015. “ArcGIS for Desktop.” http://www.esri.com/software/arcgis/arcgis-for-
desktop.
Fang, Zhixiang, Xinlu Zong, Qingquan Li, Qiuping Li, and Shengwu Xiong. 2011.
“Hierarchical Multi-Objective Evacuation Routing in Stadium Using Ant Colony
Optimization Approach.” Journal of Transport Geography 19 (3): 443–51.
doi:10.1016/j.jtrangeo.2010.10.001.
Federal Highway Administration, U. States. 2014. “Delay-V olume Relations for Travel
Forecasting: Based on the 1985 Highway Capacity Manual.”
http://www.fhwa.dot.gov/planning/tmip/publications/other_reports/delay_volume_re
lations/ch04.cfm.
Ford, L.R., and D.R. Fulkerson. 1962. “Flows in Network.” Princeton University Press.
New Jersey, NJ.
107
Frigioni, Daniele, Mario Ioffreda, Umberto Nanni, and Giulio Pasquale. 1998.
“Experimental Analysis of Dynamic Algorithms for the Single.” Journal of
Experimental Algorithmics 3 (September). doi:10.1145/297096.297147.
Frigioni, Daniele, Alberto Marchetti-Spaccamela, and Umberto Nanni. 1998.
“Semidynamic Algorithms for Maintaining Single-Source Shortest Path Trees.”
Algorithmica 22 (3): 250–74. doi:10.1007/PL00009224.
———. 2000. “Fully Dynamic Algorithms for Maintaining Shortest Paths Trees.”
Journal of Algorithms 34 (2): 251–81. doi:10.1006/jagm.1999.1048.
Goldberg, A.V ., and Chris Harrelson. 2005. “Computing the Shortest Path: A* Search
Meets Graph Theory.” In Proceedings of the Sixteenth Annual ACM-SIAM
Symposium on Discrete Algorithms, 156–65. Vancouver, BC: Society for Industrial
and Applied Mathematics. http://portal.acm.org/citation.cfm?id=1070455&dl=.
Greenberg, H. 1959. “An Analysis of Traffic Flow.” Operations Research 7 (1): 79–85.
doi:10.1287/opre.7.1.79.
Hamacher, H.W., and S.A. Tjandra. 2002. “Mathematical Modelling of Evacuation
Problems–a State of the Art.” Pedestrian and Evacuation Dynamics 24 (24).
Springer: 227–66.
http://www.forschungsplattform.de/zentral/download/berichte/bericht24.pdf.
Hart, Peter E., Nils J. Nilsson, and Bertram Raphael. 1972. “Correction to ‘A Formal
Basis for the Heuristic Determination of Minimum Cost Paths.’” ACM SIGART
Bulletin, no. 37 (December): 28–29. doi:10.1145/1056777.1056779.
———. 1968. “A Formal Basis for the Heuristic Determination of Minimum Cost
Paths.” IEEE Transactions on Systems Science and Cybernetics 4 (2): 100–107.
doi:10.1109/TSSC.1968.300136.
108
Hobeika, Antoine G, and Bahram Jamei. 1985. “MASSV AC: A Model for Calculating
Evacuation Times under Natural Disasters.” Emergency Planning, 23–28.
http://md1.csa.com/partners/viewrecord.php?requester=gs&collection=TRD&recid=
0921747CI&q=&uid=788307500&setcookie=yes.
Hoppe, Bruce, and É. Tardos. 1994. “Polynomial Time Algorithms for Some Evacuation
Problems.” In Proceedings of the Fifth Annual ACM-SIAM Symposium on Discrete
Algorithms, 433–41. Society for Industrial and Applied Mathematics.
http://portal.acm.org/citation.cfm?id=314583.
Humann, James, Newsha Khani, and Yan Jin. 2014. “Evolutionary Computational
Synthesis of Self-Organizing Systems.” Artificial Intelligence for Engineering
Design, Analysis and Manufacturing 28 (03): 259–75.
doi:10.1017/S0890060414000213.
Hutchinson, D, a Maheshwari, and N Zeh. 2003. “An External Memory Data Structure
for Shortest Path Queries.” Discrete Applied Mathematics 126 (1): 55–82.
doi:10.1016/S0166-218X(02)00217-2.
Ikeda, T., M.Y . Hsu, H. Imai, S. Nishimura, H. Shimoura, T. Hashimoto, K. Tenmoku,
and K. Mitoh. 1994. “A Fast Algorithm for Finding Better Routes by AI Search
Techniques.” In Vehicle Navigation and Information Systems Conference, 291–96.
IEEE. doi:10.1109/VNIS.1994.396824.
Jarvis, John J., and H. Donald Ratliff. 1982. “Some Equivalent Objectives for Dynamic
Network Flow Problems.” Management Science. JSTOR, 106–9.
http://www.jstor.org/stable/2631077.
Jensen, Christian S., Jan Kolářvr, Torben Bach Pedersen, and Igor Timko. 2003. “Nearest
Neighbor Queries in Road Networks.” Proceedings of the Eleventh ACM
109
International Symposium on Advances in Geographic Information Systems - GIS
2003. New York, New York, USA: ACM Press, 1–8. doi:10.1145/956676.956677.
Jha, Mithilesh, Katie Moore, and Behruz Pashaie. 2004. “Emergency Evacuation
Planning with Microscopic Traffic Simulation.” Transportation Research Record
1886 (1). Trans Res Board: 40–48. doi:10.3141/1886-06.
Kallay, Michael. 2008. “Geometric Algorithms on an Ellipsoid Earth Model.”
Proceedings of the 16th ACM SIGSP ATIAL International Conference on Advances in
Geographic Information Systems - GIS ’08, no. 3. New York, New York, USA:
ACM Press: 1. doi:10.1145/1463434.1463487.
Kim, Sangho, Betsy George, and Shashi Shekhar. 2007. “Evacuation Route Planning:
Scalable Heuristics.” In Proceedings of the 15th Annual ACM International
Symposium on Advances in Geographic Information Systems, 1. New York, New
York, USA: ACM Press. doi:10.1145/1341012.1341039.
Kobayashi, Tetsuo, R.M. Medina, and Thomas J. Cova. 2011. “Visualizing Diurnal
Population Change in Urban Areas for Emergency Management.” The Professional
Geographer 63 (1). Routledge: 113–30.
Koenig, Sven, Maxim Likhachev, Yaxin Liu, and David Furcy. 2004. “Incremental
Heuristic Search in Artificial Intelligence.” Artificial Intelligence Magazine 25.
Lauther, Ulrich. 2006. “An Experimental Evaluation of Point-To-Point Shortest Path
Calculation on Roadnetworks with Precalculated Edge-Flags.” In The Shortest Path
Problem: Ninth DIMACS Implementation Challenge, 19–40.
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.116.121.
Li, Qiuping, Zhixiang Fang, Qingquan Li, and Xinlu Zong. 2010. “Multiobjective
Evacuation Route Assignment Model Based on Genetic Algorithm.” In 18th
110
International Conference on Geoinformatics, 1–5. IEEE.
doi:10.1109/GEOINFORMATICS.2010.5567485.
Li, Wenhui, Jinlong Zhu, Huiying Li, Qiong Wu, and Liang Zhang. 2015. “A Game
Theory Based on Monte Carlo Analysis for Optimizing Evacuation Routing in
Complex Scenes.” Mathematical Problems in Engineering 2015: 1–11.
doi:10.1155/2015/292093.
Lim, G.J., M.R. Baharnemati, Shabnam Zangeneh, and H.R. Parsaei. 2009. “A Network
Flow Based Optimization Approach for Hurricane Evacuation Planning.” In
International Conference on Value Chain Sustainability.
http://www.serri.org/publications/Documents/JSU Project 70004 - ICOV ACS 2009 -
Paper by Lim Baharnemati Zangeneh Parsaei (Aliabadi).pdf.
Liu, Bing. 1997. “Route Finding by Using Knowledge about the Road Network.” IEEE
Transactions on Systems, Man, and Cybernetics - Part A: Systems and Humans 27
(4): 436–48. doi:10.1109/3468.594911.
Lu, Qingsong, Betsy George, and Shashi Shekhar. 2005. “Capacity Constrained Routing
Algorithms for Evacuation Planning: A Summary of Results.” In Advances in
Spatial and Temporal Databases, edited by Claudia Bauzer Medeiros, Max J.
Egenhofer, and Elisa Bertino, 3633:291–307. Lecture Notes in Computer Science.
Berlin, Heidelberg: Springer Berlin Heidelberg. doi:10.1007/11535331_17.
Lue, Evan, John P. Wilson, and Andrew Curtis. 2014. “Conducting Disaster Damage
Assessments with Spatial Video, Experts, and Citizens.” Applied Geography 52.
Elsevier Ltd: 46–54. doi:10.1016/j.apgeog.2014.04.014.
Malone, S.W., C.A. Miller, and D.B. Neill. 2001. “Traffic Flow Models and the
Evacuation Problem.” UMAP Journal 22 (3). Citeseer: 271–90.
111
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.110.8445&rep=rep1
&type=pdf.
Minton, Steven, Mark D. Johnston, Andrew B. Philips, and Philip Laird. 1992.
“Minimizing Conflicts: A Heuristic Repair Method for Constraint-Satisfaction and
Scheduling Problems.” Artificial Intelligence 58 (1): 161–205. doi:10.1.1.56.6125.
Narváez, Paolo, Kai Yeung Siu, and Hong Yi Tzeng. 2001. “New Dynamic SPT
Algorithm Based on a Ball-and-String Model.” IEEE/ACM Transactions on
Networking 9 (6): 706–18. doi:10.1109/90.974525.
Nassir, Neema, Mark Hickman, Hong Zheng, and Yi-chang Chiu. 2014. “Network Flow
Solution Method for Optimal Evacuation Traffic Routing and Signal Control with
Nonuniform Threat.” Transportation Research Board 2459 (Critical Infrastructure,
Emergency Evacuation, and Logistics of Disaster Recovery): 54–62.
doi:10.3141.2459-07.
NAVTEQ’s NAVSTREETS Street Data Reference Manual v2.5. 2007. October.
Papageorgiou, M., and A. Kotsialos. 2002. “Freeway Ramp Metering: An Overview.”
IEEE Transactions on Intelligent Transportation Systems 3 (4): 271–81.
doi:10.1109/TITS.2002.806803.
Pel, Adam J., Michiel C. J. Bliemer, and Serge P. Hoogendoorn. 2011. “A Review on
Travel Behaviour Modelling in Dynamic Traffic Simulation Models for
Evacuations.” Transportation 39 (1): 97–123. doi:10.1007/s11116-011-9320-6.
Pourrahmani, Elham, Mahmoud Reza Delavar, Parham Pahlavani, and Mir Abolfazl
Mostafavi. 2015. “Dynamic Evacuation Routing Plan after an Earthquake.” Natural
Hazards Review 16: 1–8. doi:10.1061/(ASCE)NH.1527-6996.0000183.
112
Ramalingam, Ganesan, and Thomas Reps. 1996. “An Incremental Algorithm for a
Generalization of the Shortest-Path Problem.” Journal of Algorithms.
http://www.sciencedirect.com/science/article/pii/S0196677496900462.
Reynolds, Craig W. 1987. “Flocks, Herds and Schools: A Distributed Behavioral Model.”
ACM SIGGRAPH Computer Graphics 21 (4): 25–34. doi:10.1145/37402.37406.
Saadatseresht, Mohammad, Ali Mansourian, and Mohammad Taleai. 2009. “Evacuation
Planning Using Multiobjective Evolutionary Optimization Approach.” European
Journal Of Operational Research 198 (1). Elsevier B.V .: 305–14.
doi:10.1016/j.ejor.2008.07.032.
Samet, Hanan, Jagan Sankaranarayanan, and Houman Alborzi. 2008. “Scalable Network
Distance Browsing in Spatial Databases.” Proceedings of the 2008 ACM SIGMOD
International Conference on Management of Data - SIGMOD ’08. New York, New
York, USA: ACM Press, 43. doi:10.1145/1376616.1376623.
Sankaranarayanan, Jagan, and Hanan Samet. 2009. “Distance Oracles for Spatial
Networks.” 2009 IEEE 25th International Conference on Data Engineering, no.
April (March). Ieee: 652–63. doi:10.1109/ICDE.2009.53.
Santos, Gabriel, and Benigno E. Aguirre. 2004. “A Critical Review of Emergency
Evacuation Simulation Models.” In Proceedings of Building Occupant Movement
During Fire Emergencies. Disaster Research Center.
http://dspace.udel.edu:8080/dspace/handle/19716/299.
Saul, Michael H. 2012. “Parts of New York City Evacuated for Hurricane Sandy.” The
Wall Street Journal.
http://online.wsj.com/article/SB10001424052970203880704578084701930663668.
html.
113
Shahabi, Kaveh. 2015a. “CASPER for ArcGIS.” ArcGIS Online.
http://esri.com/arccasper.
———. 2015b. “CASPER Source Code.” GitHub. http://github.com/spatial-
computing/CASPER.
Sheffi, Yosef, Hani Mahmassani, and Warren B. Powell. 1982. “A Transportation
Network Evacuation Model.” Transportation Research Part A: General 16 (3): 209–
18. doi:10.1016/0191-2607(82)90022-X.
Shekhar, Shashi, and Duen-Ren Liu. 1997. “CCAM: A Connectivity-Clustered Access
Method for Networks and Network Computations.” IEEE Transactions on
Knowledge and Data Engineering 9 (1): 102–19. doi:10.1109/69.567054.
Shekhar, Shashi, KwangSoo Yang, Venkata M.V . Gunturi, Lydia Manikonda, Dev Oliver,
Xun Zhou, Betsy George, Sangho Kim, Jeffrey M.R. Wolff, and Qingsong Lu. 2012.
“Experiences with Evacuation Route Planning Algorithms.” International Journal of
Geographical Information Science 26 (12): 2253–65.
doi:10.1080/13658816.2012.719624.
Sint, Lenie, and Dennis de Champeaux. 1977. “An Improved Bidirectional Heuristic
Search Algorithm.” Journal of the ACM 24 (2): 177–91.
doi:10.1145/322003.322004.
Smith, J. MacGregor. 1991. “State-Dependent Queueing Models in Emergency
Evacuation Networks.” Transportation Research Part B: Methodological 25 (6).
http://www.sciencedirect.com/science/article/pii/019126159190031D.
Smith, J. MacGregor, and F. R. B. Cruz. 2005. “The Buffer Allocation Problem for
General Finite Buffer Queueing Networks.” IIE Transactions 37 (4): 343–65.
doi:10.1080/07408170590916986.
114
Stepanov, Alexander, and J. MacGregor Smith. 2009. “Multi-Objective Evacuation
Routing in Transportation Networks.” European Journal of Operational Research
198 (2). Elsevier: 435–46. doi:10.1016/j.ejor.2008.08.025.
Sun, Xiaoxun, William Yeoh, Tansel Uras, and Sven Koenig. 2012. “Incremental ARA*:
An Incremental Anytime Search Algorithm for Moving-Target Search.” In
Proceedings of the Twenty-Second International Conference on Automated Planning
and Scheduling.
http://www.aaai.org/ocs/index.php/ICAPS/ICAPS12/paper/viewPaper/4724>.
Szalay, Alexander S, Jim Gray, George Fekete, Peter Z Kunszt, and Peter Kukol. 2005.
Indexing the Sphere with the Hierarchical Triangular Mesh. Area.
Thorup, Mikkel. 2004. “Compact Oracles for Reachability and Approximate Distances in
Planar Digraphs.” Journal of the ACM 51 (6): 993–1024.
doi:10.1145/1039488.1039493.
Uno, Keisuke, and Kazuo Kashiyama. 2008. “Development of Simulation System for the
Disaster Evacuation Based on Multi-Agent Model Using GIS.” Tsinghua Science
and Technology 13 (S1): 348–53. doi:10.1016/S1007-0214(08)70173-1.
Uras, Tansel, Sven Koenig, and Carlos Hernández. 2013. “Subgoal Graphs for Optimal
Pathfinding in Eight-Neighbor Grids.” In Proceedings of the Twenty-Third
International Conference on Automated Planning and Scheduling.
http://www.aaai.org/ocs/index.php/ICAPS/ICAPS13/paper/download/6058/6182.
U.S. Census Bureau. 2010. “Census Population Data.” Census.
http://www.census.gov/popest/data/index.html.
Yang, KwangSoo, Venkata M.V . Gunturi, and Shashi Shekhar. 2012. “A Dartboard
Network Cut Based Approach to Evacuation Route Planning: A Summary of
115
Results.” Geographic Information Science 1: 325–39.
http://link.springer.com/chapter/10.1007/978-3-642-33024-7_24.
Zeng, Maimai, and Cheng Wang. 2009. “Evacuation Route Planning Algorithm: Longer
Route Preferential.” In Advances in Neural Networks–ISNN 2009, edited by Wen Yu,
Haibo He, and Nian Zhang, 5551:1062–71. Lecture Notes in Computer Science.
Berlin, Heidelberg: Springer Berlin Heidelberg. doi:10.1007/978-3-642-01507-
6_119.
Zhan, F. B., and C. E. Noon. 1998. “Shortest Path Algorithms: An Evaluation Using Real
Road Networks.” Transportation Science 32 (1): 65–73. doi:10.1287/trsc.32.1.65.
Abstract (if available)
Abstract
In the face of a natural or man-made disaster, evacuation planning refers to the process of reallocating the endangered population to a set of safe places, often in a hurry. Such a task needs proper preparation, execution, and most definitely a post-disaster response. We have contributed a new taxonomy of the evacuation planning problem and categorized available solutions. Evacuation routing is part of the bigger problem that finds the best routes to relocate the endangered population to safety. Given circumstances, even the tiniest improvement in evacuation routing during execution can save many lives. Therefore, different research communities are looking at this particular problem from their own viewpoints hoping to design a better practical solution. ❧ We propose a new method to perform evacuation routing efficiently under capacity constraints. Traditionally, simulation software or shortest path routing combined with zonal scheduling have been used to solve routing problems. Our method utilizes a state-of-the-art algorithm to connect each source node to its nearest destination. It also intelligently takes into account transportation network capacity and traffic flow to minimize congestion and system-wide transportation times. We have compared our method with previous routing algorithms and a common simulation method in a static environment. We show that our algorithm generates reliable and realistic routes and decreases transportation time by at least an order of magnitude, without any loss of performance. ❧ We also define the dynamic evacuation routing problem and propose a solution. The dynamic solution is capable of updating routes if the network topology is changed during the evacuation process. Effectively, it can solve the evacuation problem for a moving disaster. We argue that an ideal evacuation routing algorithm should be able to generate realistic and efficient routes in a dynamic environment because changes to the road network are likely to happen after natural disasters. For example if a main road is blocked during a flood, the evacuation routing algorithm updates the plan based on this change in the road network and pushes the changed routes to the corresponding evacuees. ❧ In this dissertation we discuss evacuation routing and how it is connected to different aspects of the evacuation planning problem. Major works in this field have been studied and a better algorithm has been developed. The new algorithm’s performance and running time is iteratively improved and reported along with a comparison with previous works. The algorithm is extended to also solve the problem in a dynamic environment. Together these new developments pave the path for future researchers to study the evacuation problem and to integrate it into urban transportation services. Hopefully one day we can save more lives than before when future disasters occur.
Linked assets
University of Southern California Dissertations and Theses
Conceptually similar
PDF
Train scheduling and routing under dynamic headway control
PDF
Dispersed computing in dynamic environments
PDF
Dynamic graph analytics for cyber systems security applications
PDF
Robust routing and energy management in wireless sensor networks
PDF
Generalized optimal location planning
PDF
Ensuring query integrity for sptial data in the cloud
PDF
Human appearance analysis and synthesis using deep learning
PDF
Provenance management for dynamic, distributed and dataflow environments
PDF
Privacy in location-based applications: going beyond K-anonymity, cloaking and anonymizers
PDF
Gradient-based active query routing in wireless sensor networks
PDF
Query processing in time-dependent spatial networks
PDF
Intelligent near-optimal resource allocation and sharing for self-reconfigurable robotic and other networks
PDF
Cyberinfrastructure management for dynamic data driven applications
PDF
Improve cellular performance with minimal infrastructure changes
PDF
Dynamic routing and rate control in stochastic network optimization: from theory to practice
PDF
Scalable processing of spatial queries
PDF
Location-based spatial queries in mobile environments
PDF
Intelligent robotic manipulation of cluttered environments
PDF
Scalable dynamic digital humans
PDF
Scalable exact inference in probabilistic graphical models on multi-core platforms
Asset Metadata
Creator
Shahabi, Kaveh
(author)
Core Title
Scalable evacuation routing in dynamic environments
School
Viterbi School of Engineering
Degree
Doctor of Philosophy
Degree Program
Computer Science
Publication Date
09/21/2015
Defense Date
08/31/2015
Publisher
University of Southern California
(original),
University of Southern California. Libraries
(digital)
Tag
Computer Science,evacuation,geographic information science,location based services,network analysis,OAI-PMH Harvest,route planning,Traffic
Format
application/pdf
(imt)
Language
English
Contributor
Electronically uploaded by the author
(provenance)
Advisor
Wilson, John P. (
committee chair
), Moore, James E., II (
committee member
), Nakano, Aiichiro (
committee member
)
Creator Email
kshahabi@usc.edu
Permanent Link (DOI)
https://doi.org/10.25549/usctheses-c40-185791
Unique identifier
UC11273449
Identifier
etd-ShahabiKav-3942.pdf (filename),usctheses-c40-185791 (legacy record id)
Legacy Identifier
etd-ShahabiKav-3942.pdf
Dmrecord
185791
Document Type
Dissertation
Format
application/pdf (imt)
Rights
Shahabi, Kaveh
Type
texts
Source
University of Southern California
(contributing entity),
University of Southern California Dissertations and Theses
(collection)
Access Conditions
The author retains rights to his/her dissertation, thesis or other graduate work according to U.S. copyright law. Electronic access is being provided by the USC Libraries in agreement with the a...
Repository Name
University of Southern California Digital Library
Repository Location
USC Digital Library, University of Southern California, University Park Campus MC 2810, 3434 South Grand Avenue, 2nd Floor, Los Angeles, California 90089-2810, USA
Tags
geographic information science
location based services
network analysis
route planning