Open Access

An offline mobile application for automatic evacuation guiding in outdoor environments

  • Junki Itoi1,
  • Masahiro Sasabe1Email author,
  • Jun Kawahara1 and
  • Shoji Kasahara1
Scientific Phone Apps and Mobile Devices20173:1

https://doi.org/10.1186/s41070-017-0013-1

Received: 7 October 2016

Accepted: 17 January 2017

Published: 26 January 2017

Abstract

When a large-scale disaster occurs, evacuees have to move to safe places speedily, under highly stressful situations. For this purpose, an automatic evacuation guiding scheme based on unconscious cooperation between evacuees and their mobile nodes has been proposed and its performance, e.g., average/maximum evacuation times, has been well studied through simulation experiments. In this paper, we focus on the mobile application, which plays the key role of the automatic evacuation guiding scheme. The mobile application should be designed to operate even under offline environments because it may be disconnected from the network due to highly damaged communication infrastructures. We first design such an offline mobile application with required functions, i.e., positioning, estimation of evacuees’ situations, process of road network data, and presentation of useful information. Since positioning data obtained by Global Positioning System (GPS) may include errors, we also propose a scheme to estimate the evacuees’ situations, e.g., current position on road network and encounter with blocked road segments, by applying map matching algorithms, which try to identify a correct position and a road segment of an evacuee from erroneous positioning data. We further implement the offline application on an actual mobile phone. Through experiments, we evaluate the fundamental characteristics of the application, i.e., GPS positioning accuracy, processing time, and continuous operating time. Furthermore, we show the effectiveness of the proposed scheme in terms of estimation accuracy of an actual evacuation route, and that of blocked road segments.

Keywords

Automatic evacuation guiding in outdoor environments Offline mobile application Estimation of evacuees’ situations Map matching

Background

In the 2011 Great East Japan Earthquake, many people could not quickly obtain important information using their own mobile phones (mobile nodes), due to damage to the communication infrastructures (Ministry of Internal Affairs and Communications). In addition, under such highly stressful situations, it may be difficult for disaster victims to operate their mobile nodes as usual. To tackle these problems, an automatic evacuation guiding scheme based on unconscious cooperation between evacuees and their mobile nodes has been proposed (Komatsu et al. 2016).

This scheme is designed for outdoor environments. At first, each mobile node pre-installs a mobile application, which acquires a map and locations of safe places, e.g., primary evacuation areas and regional refuge areas, in usual time. When a disaster occurs, the mobile application first measures the location of its owner of evacuee by using existing measurement techniques, e.g., Global Positioning System (GPS). Then, it provides the evacuee with a recommended route, which starts from his/her location to the nearest safe place. Although the evacuee tries to follow the recommended route, he/she may encounter a blocked road segment on the route. In such a situation, the evacuee will select other action, e.g., proceeding to other road segment or entering a nearby building, etc., at his/her own decision. Note that the application can track this evacuee’s evacuation route by periodically measuring his/her positions. As a result, it can automatically estimate a blocked road segment based on the difference between recommended route and actual evacuation route. Then, it calculates and shows a new route that does not include the discovered blocked-road-segment. It can also share the discovered blocked-road-segments with other mobile applications and/or a cloud system, by using Delay Tolerant Network (DTN) (Fall 2003) and/or remaining communication infrastructures.

In (Komatsu et al. 2016), the authors focus on showing the fundamental characteristics of the automatic evacuation guiding scheme by demonstrating average/maximum evacuation times through several simulation experiments. In this paper, we focus on the mobile application, which plays the key role of the automatic evacuation guiding scheme. The mobile application should be designed to be able to operate even under offline environments because it may be disconnected from the network due to highly damaged communication infrastructures. We first design such an offline mobile application with required functions, i.e., positioning, estimation of evacuees’ situations, process of road network data, and presentation of useful information.

Since the previous work does not consider the effects of GPS positioning errors, we also propose a scheme to estimate the evacuees’ situations, i.e., traveling on road segments, traveling through junctions, and encounter with blocked road segments, from such erroneous positioning data. This is a kind of problems called map-matching (Quddus et al. 2007; Hashemi and Karimi 2014). Map-matching is an algorithm that matches positions including measurement errors to appropriate road segments.

According to the design, we develop a prototype of the offline mobile application. Our application is a hybrid application that can run over multiple platforms, e.g., iOS and Android, and consists of open-source software and open data. Through several experiments, we show the fundamental characteristics of our application, in terms of GPS positioning accuracy, processing time, and continuous operating time. We further evaluate the effectiveness of the proposed estimation scheme, in terms of estimation accuracy of an actual evacuation route, and that of blocked road segments.

The main contributions of this paper are as follows:
  1. 1.

    An offline mobile application for automatic evacuation guiding is designed and implemented as a hybrid application using existing open-source software and open data, which contributes to the penetration and further development of the application.

     
  2. 2.

    To enable automatic evacuation guiding, regardless of the spec of evacuees’ mobile nodes, a lightweight scheme to estimate the evacuees’ situations, e.g., current position on road network and encounter with blocked road segments, is proposed with the help of map matching algorithms.

     
  3. 3.

    Through several experiments, the fundamental characteristics of the proposed scheme is demonstrated, in terms of GPS positioning accuracy for moving objects, processing time and continuous operating time, estimation accuracy of traveling through junctions, and estimation accuracy of blocked road segment.

     

Related work

The proliferation of mobile nodes, e.g., smart phones, has been opening a new vista of evacuation guiding (Iizuka et al. 2011; Winter et al. 2011; Komatsu et al. 2016). Iizuka et al. propose an evacuation guiding system using an ad hoc network whose connectivity is almost always guaranteed (Iizuka et al. 2011). It can present evacuees with both evacuation routes and timing to avoid crowds of evacuees. Winter et al. propose an evacuation guiding system using evacuees’ trajectories (Winter et al. 2011). Evacuees continuously measure their trajectories by their mobile phones, share the trajectories with others through direct wireless communications, and try to find out available paths to safe places using the collected trajectories. Recently, Komatsu et al. propose a new concept of automatic evacuation guiding using evacuees’ mobile phones, which can estimate the surrounding situations and guide evacuees without any operations of them (Komatsu et al. 2016). In this paper, we realize a mobile application for this automatic evacuation guiding.

As for outdoor positioning, GPS becomes one of the major positioning technologies in navigation systems, e.g., Intelligent Transport System (ITS) and Google Maps (Google). GPS, however, also causes gaps in positioning (Langley 1997). Map-matching algorithms integrate such erroneous positioning data with road network data such that they estimate the correct road segment on which the moving object, e.g., vehicle and pedestrian, is traveling, and the location on that road segment (Quddus et al. 2007; Hashemi and Karimi 2014).

Map-matching algorithms can be classified into four groups: geometric, topological, probabilistic, and advanced. Geometric map-matching algorithms simply use the geometric relationship, e.g., distance between positions and road segments (Greenfeld 2002; Bernstein and Kornhauser; Bentley and Maurer 1980). Topological map-matching algorithms consider the topological structure of road network besides the geometric relationship (Greenfeld 2002). Probabilistic map-matching algorithms define an elliptical or rectangular area as a confidence region, and match positions to road segments in the area (Honey et al.). Advanced map-matching algorithms use more refined techniques such as a Kalman Filter (Krakiwsky et al. 1988) or a particle filter (Gustafsson et al. 2002).

Taking account of implementation simplicity and low computation complexity, which are essential features to run the application even over low-spec mobile nodes, we adopt the combination of geometric and topological approaches. Specifically, we use point-to-curve matching that matches GPS positions to their nearest road segments (Bernstein and Kornhauser). Note that the GPS positions can be sophisticated by applying Adaptive Kalman Filtering (Hu et al. 2009), which is more robust to the sudden changes of moving motion and measurement errors than the conventional Kalman Filtering. We also propose a topological map-matching algorithm to estimate the actual evacuation routes after traveling through junctions.

Methods

Design and implementation of mobile application for automatic evacuation guiding

Overall structure of application

Figure 1 shows the overall structure of mobile application for automatic evacuation guiding, where required functions and data, with their relationship, are described. First, evacuees pre-install the application into their own mobile nodes and obtain map, locations of safe places, and graph, i.e., road network, before disasters occur. After the application starts, it measures the current location by positioning, calculates a recommended route to the nearest safe place by route search, and presents the map and recommended route by presentation of useful information. Moreover, it periodically conducts positioning to grasp the evacuee’s actual movement as trajectory, and automatically estimates blocked road segments from the difference between recommended route and trajectory, using estimation of evacuee’s situation. If it newly discovers a blocked road segment, it recalculates recommended route by route search. Finally, it shares information about blocked road segments with other mobile nodes through direct wireless communication and/or with a cloud system through remaining communication infrastructures, by conducting communication control.
Fig. 1

Overall structure of mobile application for automatic evacuation guiding

We develop the application as a hybrid application using Apache Cordova (Apache), so that the application can run over multiple platforms, e.g., iOS and Android. Since Apache Cordova is based on JavaScript, we also use some JavaScript-based open source software. In the following subsections, we give the detail of each function in Fig. 1.

Positioning

This function periodically measures the positions of mobile node using a GPS sensor, and stores the series of measured positions, i.e., trajectory, into the local database. We implement this function using Cordova Geolocation API (W3C). Geolocation API has two methods to measure positions. One is getCurrentPosition that measures positions at a fixed interval and the other is watchPosition that measures positions whenever the location changes. We adopt watchPosition because we observed that it is superior to getCurrentPosition in terms of positioning accuracy and power consumption, through preliminary experiments.

Graph data handling

The application needs a graph of the road network, where edges and nodes correspond to road segments and endpoints of them, respectively. Since it should work even without any communication environments, it locally constructs the graph from XML-based OSM data retrieved from OpenStreetMap (OpenStreetMap). We use Cytoscape (Cytoscape) to handle graph data, e.g., calculating shortest paths as recommended routes. We should note here that OSM data for a target region may not be perfect because they are voluntarily managed by multiple users. For example, some road segments are identical but redundantly registered, and some intersections lose connections with the corresponding road segments. In this paper, we conducted pre-processing to the OSM data to fix the above problems.

Presentation of useful information

The application also obtains map tiles, which are fragments of images of the map, from OpenStreetMap. We use Leaflet (Leaflet), which is an open-source JavaScript library for mobile-friendly interactive maps, to display useful information, i.e., map, recommended routes, blocked road segments, and trajectory. To achieve real-time guiding, the application updates all the information except map whenever it obtains new information.

Estimation of evacuees’ situations

The application estimates evacuees’ situations based on map, recommended route, and trajectory, i.e., actual evacuation route. The evacuees’ situations can be classified into three cases: traveling on the recommended route, traveling through junctions, and encountering blocked road segments. Since positioning errors are not considered in (Komatsu et al. 2016), we newly develop a scheme to estimate the evacuees’ situations, with the help of map-matching algorithm. The detail of the estimation scheme will be given in the next section.

Communication control

In this paper, we focus on offline functions of the mobile application, which includes all the functions except communication control. In what follows, we briefly give the information about communication control. The application shares the information of blocked road segments with other mobile nodes and the server on cloud system. The communication with other nodes can be done through remaining communication infrastructures and/or direct wireless communication, e.g., Bluetooth and Wi-Fi Direct.

Algorithm for estimation of evacuees’ situations

Overview

The application periodically estimates evacuees’ situations by taking account of real-time guiding, estimation accuracy, and power consumption of mobile nodes. Hereafter, we refer to the estimation scheme as the proposed scheme. As mentioned in the previous section, it continuously measures positions of the mobile node using watchPosition. When the application starts, it first obtains the initial location and immediately conducts the proposed scheme. At the succeeding positioning, it conducts the proposed scheme only when the time interval from the previous execution of the proposed scheme is not less than I M (I M>0). As a result, the application can conduct the proposed scheme at an approximate interval of I M. I M should be at least longer than the processing time of the proposed scheme. In the next section, we will evaluate the impact of I M on the system performance.

Algorithm 1 shows the estimation of evacuees’ situations, where each mobile node’s behavior at i-th (i=1,2,…) round of the proposed scheme is described. Table 1 and Fig. 2 give the notation and geographical relationship among them, respectively. When the application starts at time t(0), it first initializes i=0 and set p(0),r,e(0),p e (0),v e (0) to be null, respectively. Algorithm 1 consists of three kinds of functions: (1) road-matching, i.e., estimation of the road segment on which the evacuee is traveling, (2) detection of leaving the road segment on which the evacuee traveled, and (3) estimation of traveling through a junction. With the help of these functions, the application updates the information, i.e., the recommended route, the evacuee’s traveling road segment, and the set of blocked road segments. In what follows, we will give the detail of each function.
Fig. 2

Geographical relationship among notation

Table 1

Notation

Notation

Definition

t(i)

Start time of i-th round

p(i)

Measured position at i-th round

r

Recommended route, i.e., sequence of edges

e(i)

The nearest edge in recommended route from p(i)

p e (i)

Estimated position on e(i)

v e (i)

e(i)’s endpoint in traveling direction

v d

Destination node

G

Graph composed of nodes and edges

\(\mathcal {E}_{\text {NG}}\)

Set of blocked road segments

Road-matching

Road-matching is given by lines 2–6 in Algorithm 1. If the evacuee did not travel on any edge at (i−1)-th round, e.g., initial state, the algorithm tries to calculate recommended route r and the nearest edge e(i) by using \({\sf getRoute}(p(i),v_{\mathrm {d}},G,\mathcal {E}_{\text {NG}})\). Otherwise, it updates the nearest edge e(i) by using getNearestEdge(p(i),r). In what follows, we give the detail of these functions.

We achieve getNearestEdge() using point-to-curve matching (Bernstein and Kornhauser), which matches an erroneous position to its nearest road segment by calculating the distance from the measured position to each candidate road segment. Given position p and candidate set e of edges, getNearestEdge(p,e) returns the nearest edge \(e=\underset {e^{\prime }\in \mathbf {e}}{\text {arg~min}} d_{\mathrm {E}}(p,e')\), the nearest position p e on e from p, and endpoint v e of e in the traveling direction. Here, d E(p,e) calculates the distance between edge e and position p, which is equivalent to the distance between p e and p.

\({\mathsf {getRoute}}(p,v_{\mathrm {d}},G,\mathcal {E}_{\text {NG}})\) calculates the recommended route, e.g., the shortest path, from p to v d. Given position p, destination node v d, graph G, and set \(\mathcal {E}_{\text {NG}}\) of blocked road segments, it first calculates the nearest edge e and point p e on e by using \({\mathsf {getNearestEdge}}(p,\mathcal {E})\) where \(\mathcal {E}\) is the set of all edges in G. Second, it searches for recommended route r from p e to v d, which does not include any edge in \(\mathcal {E}_{\text {NG}}\). \({\mathsf {getRoute}}(p,v_{\mathrm {d}},G,\mathcal {E}_{\text {NG}})\) returns recommended route r, the nearest edge e, the nearest point p e on e, and end point v e on e in the traveling direction. It, however, returns null for each variable if the current position p is apart from the nearest edge e at a certain distance, i.e., d E(p,p e )>θ D(θ D>0). Since appropriate value of θ D depends on the positioning accuracy, we will discuss this point in the next section.

Detection of leaving road segment

Detection of leaving the road segment on which the evacuee traveled is given by lines 7–11 in Algorithm 1. If i-th round’s nearest edge e(i) equals to previous one e(i−1), the proposed algorithm basically estimates that the evacuee smoothly follows recommended route r. It, however, detects leaving edge e(i−1) if one of the following conditions is satisfied:
  • Distance d E(p(i),p e (i)) between current position p(i) and the nearest point p e (i) on e(i) is larger than threshold θ D of distance. This case indicates that the evacuee is not traveling on any road segment but is in free space, e.g., park, building, etc. θ D should be large enough to eliminate the effect of positioning errors. Note that GPS positioning accuracy will degrade when evacuees enter buildings. To improve the positioning accuracy in indoor environments, which is out of our scope, our system can cooperate with existing indoor positioning systems (Liu et al. 2007). Some of such indoor positioning systems can also be GPS-based, such as wireless assisted GPS (AGPS) and GPS weak signal tracking technology, e.g., SuperSense.

  • Average traveling speed \(\frac {d_{\mathrm {G}}(p_{e}(i), p_{e}(i-1))}{t(i)-t(i-1)}\) at the interval between (i−1)-th and i-th rounds is less than threshold θ V of traveling speed. Note that d G(p e (i),p e (i−1)) gives the distance between p e (i) and p e (i−1) along edges of the graph. This case will occur when the evacuee leaves current recommended route r, as shown in Fig. 3 a.
    Fig. 3

    Detection of leaving road segment. a Slowdown of average traveling speed. b Reversal of traveling direction

  • Traveling direction at i-th round is opposite to that at (i−1)-th round. This case will occur when the evacuee goes back the road segment. The condition can be expressed by d G(p e (i),v e (i))>d G(p e (i−1),v e (i−1)), as shown in Fig. 3 b.

If one of the above conditions is satisfied, the algorithm estimates that next road segment getNextEdge(e(i),r) of e(i) on r may be blocked and adds it to set \(\mathcal {E}_{\text {NG}}\) of blocked road segments. Finally, the algorithm recalculates a new recommended route and the nearest edge on the route by using \({\mathsf {getRoute}}(p,v_{\mathrm {d}},G,\mathcal {E}_{\text {NG}})\).

Estimation of traveling through junction

Estimation of traveling through junction is given by lines 12–22 in Algorithm 1. If edge e(i) at i-th round is not equal to edge e(i−1) at (i−1)-th round, the algorithm estimates that the evacuee travels through a junction.

The algorithm first obtains set \(\mathcal {E}_{\mathrm {C}}\) of candidate road segments on which the evacuee may be traveling, by using \({\mathsf {getConnectedEdges}}(v_{e}(i-1), G, \mathcal {E}_{\text {NG}})\). Since the evacuee was traveling from p e (i−1) to v e (i−1) on edge e(i−1) at (i−1)-th round, we define \(\mathcal {E}_{\mathrm {C}}\) as the set of road segments that are directly connected to v e (i−1). Next, the algorithm calculates the average traveling speed for each candidate edge \(e' \in \mathcal {E}_{\mathrm {C}}\) under the assumption that the evacuee travels edge e . Since it can be expected that the average traveling speed for the edge on which the evacuee is actually traveling becomes faster than those for other candidate edges, the algorithm selects the edge with the fastest traveling speed as \(\widehat {e}(i)\). If \(\widehat {e}(i)\) equals to e(i), the algorithm estimates the evacuee is traveling on e(i) as expected. Otherwise, it estimates edge e(i) is blocked and recalculates a recommended route.

Results and discussion

We conducted several experiments using actual mobile phones, i.e., Nexus 5 with Android OS 4.4.2. Figure 4 illustrates a sample screenshot of our application. Through preliminary experiments, we first clarify the fundamental characteristics of our application in terms of positioning accuracy, processing time, and continuous operating time. Next, we show the estimation accuracy of proposed scheme.
Fig. 4

Screenshot of our application, which displays recommended route (red line), original trajectory (blue line), estimated evacuation route (black line), and blocked road segment (red cross)

Evaluation scenario

We conducted fifty independent experiments in the campus of our institute. Figure 5 shows the experimental scenario as a graph. There are eleven road segments labeled e 1 to e 11 and one blocked road segment e 5. In each experiment, an evacuee with Nexus 5 starts his evacuation from node v s. At the same time, our application obtains the initial location and finds out the nearest safe place v d. Then, it calculates first recommended route r 1=(e 1,e 5,e 6,e 7). The evacuee goes along r 1 but encounters blocked road segment e 5 at first junction v 1. He changes the route by himself and proceeds to e 2 instead of e 5. The application detects that the evacuee leaves r 1 using the proposed scheme and adds e 5 to \(\mathcal {E}_{\text {NG}}\). It also calculates new route r 2=(e 2,e 3,e 4), which does not include e 5. Finally, the evacuee can smoothly reach destination v d along r 2.
Fig. 5

Evaluation scenario

In the above scenario, the correct evacuation route should be t true=(e 1,e 2,e 3,e 4). On the contrary, the application obtains estimated evacuation route t est at each experiment. Since it periodically estimates the road segment on which the evacuee may be traveling, the estimated trajectory may include two or more consecutively identical edges. We obtain t est by eliminating such redundant information from the estimated trajectory. Note that there are three junctions v 1,v 2,v 3 in t true and they have correct next edges, e 2,e 3,e 4, respectively. We define successful probability T true(v)(v{v 1,v 2,v 3}), which is the ratio of the number of experiments where the proposed scheme can correctly estimate the next edge of v to the total number of experiments. We also define \(\overline {T}_{\text {true}}\) as the average of T true(v) among v 1,v 2, and v 3.

To evaluate the estimation accuracy of blocked road segment, we apply precision B precision, recall B recall, and F-measure B F−measure (Christopher et al. 2008). Precision means how correct the estimation results are while recall means how complete the estimation results are. F-measure is the harmonic mean of precision and recall. Specifically, these criteria are defined as follows: \(B_{\text {precision}}=\frac {B_{\text {TP}}}{B_{\text {TP}} + B_{\text {FP}}}\), \(B_{\text {recall}}=\frac {B_{\text {TP}}}{B_{\text {TP}} + B_{\text {FN}}}\), and \(B_{\mathrm {F-measure}}=\frac {2 B_{\text {recall}} \times B_{\text {precision}}}{B_{\text {recall}} + B_{\text {precision}}}\), where B TP is the number of correctly estimated blocked-road-segments, B FP is the number of incorrectly estimated blocked-road-segments, and B FN is the number of undetected blocked-road-segments.

During the experiments, the evacuee tried to move at a constant speed and the average traveling speed was 1.25 [m/s]. We set threshold θ V of traveling speed to detect leaving a road segment to be 0.5 [m/s], which is less than half of the average traveling speed.

GPS positioning accuracy for moving object

There have been several reports about GPS positioning errors. In (Committee), it is assumed that they follow a normal distribution. On the contrary, Zandbergen shows that they follow a Rayleigh distribution through experiments where the positioning data are collected by a GPS unit located at a fixed point. In our scenario, we have to reveal the GPS positioning accuracy for moving objects, but it is a challenging problem. Figure 6 illustrates current (actual) edge e(i), measured position p(i), estimated position p e (i), and actual position \(p^{\text {true}}_{e}(i)\) of mobile node at i-th round in Algorithm 1. It is impossible to obtain actual position \(p^{\text {true}}_{e}(i)\) for measured position p(i) in actual situations. In addition, point-to-curve matching focuses on the distance between p(i) and p e (i) rather than that between p(i) and \(p^{\text {true}}_{e}(i)\). Taking account these characteristics, we define the absolute positioning error at i-th round as distance d E(p(i),p e (i)).
Fig. 6

Current (actual) edge e(i), measured position p(i), estimated position p e (i), and actual position \(p^{\text {true}}_{e}(i)\) of mobile node at i-th round

We obtained 1252 samples of positioning data through an experiment where the evacuee traveled back and forth a road segment in our campus. Figure 7 illustrates the histogram of absolute positioning errors, where we omit the direction of gaps. We also show a normal distribution whose average is 0 [m] and standard deviation σ is 6.83 [m]. We observe that the GPS positioning errors can be roughly approximated by the normal distribution. Taking account of the characteristics of a normal distribution, i.e., 95.45% of positioning data fall in the range of 0±2σ, we set θ D to be 2σ=3.66 [m].
Fig. 7

Histogram of GPS positioning errors

Processing time and continuous operating time

Next, we focus on processing time and continuous operating time. Since the mobile application has to conduct offline route search, both both processing time and battery consumption increase with the size of road network. On the contrary, the size of road network should be large enough to include appropriate safe place(s). In Japan, there is a guideline where it is desirable to place a regional refuge area within a range of 2 [km] (Masuda 2002). In the experiments, we used the road network data with 4957 nodes, which corresponds to about one tenth of Ikoma city, i.e., 3.5 [km] × 3.0 [km], in Japan. We observed that the processing time of route search is less than 0.5 [s], which is small enough to achieve real-time guiding.

Figure 8 illustrates average continuous operating time for three cases: 1) display, 2) positioning, and 3) reroute. In display case, the application only displays the screen with the maximum brightness. In positioning case, it displays the screen with the maximum brightness and measure positions every 5 [s]. In reroute case, it displays the screen with the maximum brightness, measure positions and calculates routes every 5 [s]. We observe that our application can keep running about five hours even under the highly loaded situation, i.e., reroute case. In actual situations, the continuous operating time will be longer because our application conducts the route search only when it detects and/or retrieves blocked road segments.
Fig. 8

Average continuous operating time

Taking account of the above results, we set I M to be 5, 10, and 15 [s]. In what follows, we show the average of fifty independent experiments for each I M.

Estimation accuracy of traveling through junctions

Figure 9 shows successful probability T true(v) of estimation of the next edge of junction v (v{v 1,v 2,v 3}) and average \(\overline {T}_{\text {true}}\) among the junctions for I M=5,10,15 [s]. We observe that T true(v) monotonically increases with I M, regardless of v. This can be analyzed as follows. Recall the process of estimation of traveling through junction in the previous section. When the algorithm calculates the average traveling speed for each candidate edge \(e' \in \mathcal {E}_{\mathrm {C}}\) (line 17 in Algorithm 1), \(d_{\mathrm {G}}(p_{e^{\prime }}, p_{e}(i-1))\phantom {\dot {i}\!}\) can be divided into \(d_{\mathrm {G}}(p_{e^{\prime }}, v_{e}(i-1))\phantom {\dot {i}\!}\) and d G(v e (i−1),p e (i−1)). Since d G(v e (i−1),p e (i−1)) is identical for each \(e' \in \mathcal {E}_{\mathrm {C}}\), \(d_{\mathrm {G}}(p_{e^{\prime }}, v_{e}(i-1))\phantom {\dot {i}\!}\) only affects the estimation accuracy. When I M becomes long, \(d_{\mathrm {G}}(p_{e{\prime }}, v_{e}(i-1))\phantom {\dot {i}\!}\) only for the correct edge tends to increase, and thus the estimation accuracy increases. As a result, the proposed scheme can achieve about 98% of \(\overline {T}_{\text {true}}\) in case of I M=15.
Fig. 9

Successful probability T true(v) of estimation of the next edge of junction v (v{v 1,v 2,v 3}) and average \(\overline {T}_{\text {true}}\) among the junctions for I M=5,10,15 [s]

Next, we focus on relationship among successful probabilities of three junctions, T true(v 2)>T true(v 3)>T true(v 1). The following two factors influence successful probability T true(v).
  • The number N(v) of edges connected to junction v, i.e., degree.

  • Existence of blocked road segment(s) connected to junction v.

The estimation becomes simple for a junction with small degree because the number of candidate edges also becomes small. As a result, estimation at v 2, which has the smallest degree, achieves the highest estimation accuracy. On the other hand, both v 1 and v 3 have the same degree of 4. v 1, however, has blocked road segment e 5 on its next edge. Thus, estimation at v 1 becomes more difficult than that at v 3.

Estimation accuracy of blocked road segment

Table 2 gives the estimation accuracy of blocked road segment for I M=5,10,15. We observe that both B precision and B recall monotonically increase with I M, and so does B F−measure. Note that the estimation accuracy of blocked road segment e 5 is linked with that of the next edge of junction v 1, which is already given in the previous subsection. If the algorithm incorrectly conjectures that the evacuee moves to edge e 5 through junction v 1, it judges the next edge e 6 as a blocked road segment. In this case, both B FN and B FP increase by one, respectively. Furthermore, if incorrect estimation of the next edge at junctions v 2 and/or v 3 occur, it increases B FP. As a result, B precision tends to be smaller than B recall. We, however, confirm that the proposed scheme can achieve 0.95 of B F−measure for I M=15.
Table 2

Estimation accuracy of blocked road segments

I M [s]

5

10

15

B precision

0.55

0.78

0.94

B recall

0.68

0.86

0.96

B F−measure

0.58

0.81

0.95

From the above results, we find that I M=15 is enough to achieve highly accurate estimation of both traveling through junctions and blocked road segment.

Conclusion

In this paper, we designed and implemented an offline mobile application for automatic evacuation guiding based on cooperation between evacuees and their mobile nodes. Since the positioning data of mobile nodes are erroneous, we further proposed a scheme to estimate evacuees’ situations with the help of map-matching algorithm. The proposed scheme consists of three functions: (1) road-matching, (2) detection of leaving road segment, and (3) estimation of traveling through junction. Through several experiments using actual mobile phones, we showed that our application with an appropriate control interval, e.g., I M=15, can correctly guide evacuees in a real-time manner and during a sufficiently long period, which is more than five hours.

As part of future work, combining the sensing results of GPS sensor with those of other types of sensors, e.g., gyroscopes and acceleration sensor, will help to further reduce I M while keeping the estimation accuracy. We also plan to implement the function of communication control and evaluate its practicality.

Declarations

Authors’ contributions

The authors have contributed to this paper and all authors read and approved the final manuscript.

Competing interests

The authors declare that they have no competing interests.

Open Access This article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.

Authors’ Affiliations

(1)
Graduate School of Information Science, Nara Institute of Science and Technology

References

  1. Apache. Apache Cordova. https://cordova.apache.org/. Accessed 22 Jan 2017.
  2. Bernstein, D, Kornhauser A. An Introduction to Map Matching for Personal Navigation Assistants. Technical report, Transportation Research Board 1998, https://trid.trb.org/view.aspx?id=681286.
  3. Bentley, JL, Maurer HA. Efficient worst-case data structures for range searching. Acta Informatica. 1980; 13(2):155–68.MathSciNetView ArticleMATHGoogle Scholar
  4. Christopher, DM, Prabhakar R, Hinrich S. Introduction to Information Retrieval. New York: Cambridge University Press; 2008.MATHGoogle Scholar
  5. Committee, FGD. Geospatial Positioning Accuracy Standards Part 3: National Standard for Spatial Data Accuracy. Technical report, Transportation Research Board 1998, https://www.fgdc.gov/standards/projects/accuracy/part3/index_html.
  6. Cytoscape. Cytoscape. http://js.cytoscape.org/.
  7. Fall, K. A Delay-Tolerant Network Architecture for Challenged Internets. In: Proc. of SIGCOMM’03. New York: ACM: 2003. p. 27–34.Google Scholar
  8. Google. Google Maps. https://maps.google.com. Accessed 22 Jan 2017.
  9. Greenfeld, JS. Matching GPS Observations to Locations on a Digital Map. In: Proc. of Transportation Research Board 81st Annual Meeting: 2002. https://trid.trb.org/view.aspx?id=711583.
  10. Gustafsson, F, Gunnarsson F, Bergman N, Forssell U, Jansson J, Karlsson R, Nordlund PJ. Particle filters for positioning, navigation, and tracking. IEEE Trans Signal Process. 2002; 50(2):425–37.View ArticleGoogle Scholar
  11. Hashemi, M, Karimi HA. A critical review of real-time map-matching algorithms: current issues and future directions. Comput Environ Urban Syst. 2014; 48:153–65.View ArticleGoogle Scholar
  12. Honey, SK, Zavoli WB, Milnes KA, Phillips AC, White Jr MS, Loughmiller Jr GE. Vehicle Navigational System and Method. Google Patents. US Patent 4,796,191.1989, https://www.google.com/patents/US5862511.
  13. Hu, C, Chen W, Chen Y, Liu D. Adaptive Kalman Filtering for Vehicle Navigation. J Global Positioning Syst Positioning. 2009; 2(1):42–7.View ArticleGoogle Scholar
  14. Iizuka, Y, Yoshida K, Iizuka K. An Effective Disaster Evacuation Assist System Utilized by an Ad-Hoc Network. In: Proc. of HCI International 2011. Berlin, Heidelberg: Springer: 2011. p. 31–5.Google Scholar
  15. Komatsu, N, Sasabe M, Kawahara J, Kasahara S. Automatic evacuation guiding scheme based on implicit interactions between evacuees and their mobile nodes. GeoInformatica. 2016:1–15. http://link.springer.com/article/10.1007/s10707-016-0270-1.
  16. Krakiwsky, EJ, Harris CB, Wong RV. A Kalman Filter for Integrating Dead Reckoning, Map Matching and GPS Positioning. In: Proc. of IEEE PLANS’88: 1988. p. 39–46. http://ieeexplore.ieee.org/document/195464/references.
  17. Langley, RB. The GPS Error Budget. GPS World. 1997; 8(3):51–6.Google Scholar
  18. Leaflet. Leaflet. http://leafletjs.com/. Accessed 22 Jan 2017.
  19. Liu, H, Darabi H, Banerjee P, Liu J. Survey of Wireless Indoor PositioningTechniques and Systems. IEEE Trans Syst Man Cybernet Part C. 2007; 37(6):1067–1080.View ArticleGoogle Scholar
  20. Masuda, N. Urban Park Planning from the Point of View of the Safe and Secure Urban Environment (in Japanese. J Japan Inst Landsc Archit. 2002; 66(3):180–4.MathSciNetView ArticleGoogle Scholar
  21. Ministry of Internal Affairs and Communications. 2011 WHITE PAPER Information and Communications in Japan. http://www.soumu.go.jp/johotsusintokei/whitepaper/eng/WP2011/2011-index.html. Accessed 22 Jan 2017.
  22. OpenStreetMap. OpenStreetMap. https://www.openstreetmap.org/. Accessed 22 Jan 2017.
  23. Quddus, MA, Ochieng WY, Noland RB. Current map-matching algorithms for transport applications: state-of-the art and future research directions. Transp Res Part C Emerg Technol. 2007; 15(5):312–28.View ArticleGoogle Scholar
  24. W, 3C. Geolocation API Specification W3C Recommendation 24 October 2013. http://www.w3.org/TR/geolocation-API/. Accessed 22 Jan 2017.
  25. Winter, S, Richter KF, Shi M, Gan HS. Get Me out of Here: Collaborative Evacuation Based on Local Knowledge. In: Proc. of Third International Workshop on Indoor Spatial Awareness. New York: ACM: 2011. p. 35–42.Google Scholar

Copyright

© The Author(s) 2017