Keywords

1 Introduction

In recent years, various natural disasters have occurred throughout the world. In the case of flood and tsunami disasters caused by typhoons, heavy rains, and earthquakes, residents in a disaster-affected area have some time to evacuate to a shelter after an evacuation alert is received from a governmental office.

A delay in evacuation may result in a significant number of casualties. Weathernews Inc. reported the relationship between evacuation delay and human risk during the 2011 Great East Japan Earthquake and following tsunami disaster [1]. The report shows the evacuation start time of both (a) the survivors and (b) the dead and missing residents after an earthquake. There is a significant difference between (a) and (b): 71% of the survivors evacuated within 120 min; by contrast, for the deceased (confirmed dead or missing), only 22% evacuated within the same time. Therefore, an early evacuation is extremely important for decreasing the risk to human life.

The report also indicated that the people who arrived at the emergency shelters decreased their risk of becoming a casualty. Three-quarters of the survivors evacuated to the emergency shelters; however, in the case of the dead and missing, only one-quarter made it to a shelter. During such an emergency, more people may be saved by providing information on the location of the available shelters and the evacuation conditions of the neighborhood.

Another problem is a change in the destination shelter after an evacuation starts. Such a problem occurred when typhoon Hagibis hit Japan on October 12, 2019. The Meteorological Agency issued an evacuation advisory because a huge rainfall and river flooding had been forecasted. At the time, some shelters in Kanagawa [2] and Fukushima prefecture [3] exceeded their capacity and refused to accept additional evacuees. The rejected evacuees were forced to move to another acceptable shelter despite the dangerous conditions. To avoid such a problem, evacuees should know where the optimal shelters with sufficient space are located before starting their evacuation.

Evacuation support for elderly and disable people, who cannot evacuate oneself, is also serious problem in emergency situations. The cabinet office of Japan published the statistics of damage to elderly people in the 2011 Great East Japan Earthquake. The statistics shows that the number of deaths in the disaster is 15,812, and 10,360 of them, about two-thirds of the whole deaths, is elderly people who cannot evacuate alone at the time of a disaster. We defined such a people as Support-required People (SRP) [4]. It is important that the supporters who support the evacuation of such people with sharing the information of the SRP, supporters and shelters’ condition, and take evacuation action promptly.

2 Related Studies

Owing to technical improvements and the popularization of mobile devices and information communication systems, people can now receive up-to-date information easily and quickly from related websites. Once a disaster occurs, an evacuee can access the disaster information published on the websites to decrease the risk of injury.

Many studies have shown that the integration of a geographic information system is effective for a disaster risk reduction. Nakajima et al. [5] built an evacuation guide system based on GPS-capable cellphones, which provides evacuation route guidance on maps for massive evacuations. Rahman et al. [6] proposed a location-based early disaster warning and evacuation system using OpenStreetMap (OSM). They used OSM, a free and rapidly growing open-source map of the world, to share disaster data, such as the type of disaster, the probable disaster-affected area, and the shortest path to a shelter. Itoi et al. [7] proposed an offline mobile application for automatic evacuation guidance in an outdoor environment. They developed an automatic evacuation guidance scheme to estimate the state the evacuees and applied it to the application, which presents a suitable evacuation path.

Regarding to using Social Media in the case of disaster, there are some papers. For example, Hilts et al. (2014) proposed to use of Social Media for U.S. Public Sector Emergency Manager [8] and Abdllah et al. (2017) discussed about the issues on information spreading by Twitter in the case of the disaster [9]. Regarding to the decision making in emergency, Cesta et al. (2014) proposed the training for the decision making in crisis based on plan adaptation [10]. Further, Bernabé et al. (2018) also studied the impact of warning situations for decision making in transportation companies through social media [11].

Above problems are related with the “public support” in an emergency case. In an emergency case, the “public support” has a limitation because of the budget and human resource limitation. Therefore, voluntary evacuation by citizen is important for emergency, and it is necessary for all citizens to share disaster information promptly. Additionally, the above studies did not mention the information sharing on the SRP and supporters, and shelter conditions during a natural disaster. In our previous study, we proposed the Regional Information Sharing System (RISS) and evaluated the effect by multi-agent simulation [4, 12]. But, the actually required and important information to reduce human damage in a regional natural disaster was still unclear.

This paper shows an evacuation time-line model and indicates that the actually required and important information in such a natural disaster are the location information of SRP and supporters, and the current shelter’s detail condition. Based on this concept, we newly developed the Real-time Evacuation Support System (RESS) which can share the information on the location of SRP and supporters, and shelter’s detail conditions. Further, we present a case study of the prototype system for Kamaishi City in Iwate Prefecture, Japan. We conclude that the system will be helpful for local residents to accurately understand the state of the SRP and supporters, and evacuation shelters and reduce the risks of human damage in a natural disaster.

3 Evacuation Time-Line Model

Japanese government organizations have a mechanism to send information from disaster warnings to evacuation orders according to the level of natural disasters. The information level and behavior to be taken are shown in Table 1. This information level changes not only with the magnitude of the disaster, but also with time. So, as our behavior will change according to the time, so we should make a time-line model to best behavior in the case of natural disasters.

In the Level 3 on Table 1, the evacuation is started from the SRP (Support-required People), who is vulnerable people for disasters and required assistance to evacuate, and supporters who assist SRP, and then the general evacuees will evacuate. In those situation, the location information of SRP and supports, and the condition of shelters are very important. The information of shelters includes the location, the state of open or closed, the capacity and current number of evacuees for the capacity. Those information will be changed moment to moment and it should be provided real-time to the every evacuees. In particular, due to the recent situation of the new coronavirus (COVID-19), the capacity of evacuation centers is often limited to half of the normal number, and information on the current number of evacuees for the capacity is very important. There are some cases that ordinary evacuees may need to evacuate to their homes or cars instead of to shelters in such a restricted case.

Table 1. Evacuation Time-Line Model.
Full size table

4 Proposed System

Figure 1 shows our proposed Real-time Evacuation Support System (RESS). In this system, IT volunteers, etc. manage the disaster information and the evacuation shelter information in the area collected from government organizations, social media (radio, TV etc.) and Social Network Services (SNS) in the internet. Then, they send those information to regional residents as early as possible. It is assumed that this system will be used at the initial stage of a disaster and at the available stage of the power supply and communication facilities. Namely, our proposed system RESS is assumed to be used in the case of level 3 and 4 in Table 1.

When level 3 information (evacuation preparation information) is issued, the supporter confirms the location of the SRP and will go to evacuation support. Other supporters confirm the location information of the SRP and the supporters, and if there is not supporter to support the SRP, he/she goes to the SRP. Next, when level 4 is issued, all evacuees including general evacuees go to the evacuation shelter. If the shelter capacity is in over capacity, the general evacuees go to own home, relative’s home or other comparatively safe place such as hotels or cars.

For safety evacuation, the system integrates actually required and important information and provides those information in real time onto a smartphone map of needed people in the area. With our proposed system, supporters and evacuees can check the location of SRP and available shelters and decide where to evacuate by themselves, and thus reach an optimal shelter quickly and safely. Since there was no such a mechanism before, it was difficult to share promptly the location information between a supporter and other supporters as well as SRP and shelter’s detail condition. So, we developed newly following functions.

Fig. 1.
figure 1

Proposed Real-time Evacuation Support System (RESS).

Full size image

4.1 Location Visualize Function of SRP and Supporters

In Japan, each local government office is obliged to compose and keep a list of SRP (Support-required People) as a document. For example, in Kamaishi city on Iwate Prefecture in Japan, there are 2,636 SRP, each name, age, address, contact address, family structure and information of two or three responsible supporters are written in the list of SRP.

Figure 2 and Fig. 3 show the developed structure of the location visualize function and an example of the smartphone display in the system. The markers of Fig. 3(a) show the positions of supporters which obtained as the location information of their smartphones by GPS (Global Positioning System), and an evacuation shelter and a SRP’s house location which can be obtained based on the latitude and longitude information in the address of registered SRP and evacuation list prepared by local government office. When a user taps each marker, the application display modality screen shows its detailed information as shown in Fig. 3(b). The supporters can confirm the evacuation shelter information such as address and the number of current evacuees and the capacity. When evacuation is completed, the marker of SRP is removed from the map by registering. When the supporter launches the application, the application seeds location information that is obtained using GPS on smartphone to the database every 5 s. By creating markers based on those data, supporters can grasp each other’s position.

Fig. 2.
figure 2

The developed structure of the location visualize function.

Full size image
Fig. 3.
figure 3

An example of the smartphone display in the developed system.

Full size image

4.2 Shelter Condition Visualize Function

The Japanese government provides different disaster-related information depending on the local level. For example, the city government provides the addresses of the shelters, the prefectural government provides the current number of evacuees and the open/closed statuses of the shelters, and the national government provides early alerts about disasters and is required to declare an evacuation. However, such data are not integrated, and thus it is difficult for general evacuees to use the information during an actual evacuation. To integrate the shelter information from different resources, we developed the shelter condition visualize function.

The structure of our developed function is shown in Fig. 4. The function consists of four sub-functions: (1) a web crawler, which fetches shelter data from the government website, (2) a database to store the shelter information, (3) a shelter map application for a mobile device, and (4) a web API that connects the above components. The detailed functions of the four sub-function are described in the following.

Fig. 4.
figure 4

Structure of the shelter condition visualize function.

Full size image

  • (1) Web crawler: Data on evacuation shelters are published on government websites. There are two types of data: stable and unstable. Some of these data, such as the name, location, address, and capacity of the shelters, are stable and rarely change, whereas the data on the current condition of the shelters, including the number of evacuees and the open/closed status, are unstable and frequently change. The web crawler fetches these two types of data at different intervals for each type: at 1-day intervals for stable data under typical conditions and at 1-min intervals for unstable data during an emergency. By fetching data based on this method, the system can provide information in real time.

  • (2) Database: The database stores evacuation shelter data, such as the name, location, capacity, and number of evacuees from the web crawler through the web API. If the web API requests to receive data, the database responds.

  • (3) Shelter Maps Application: Our system provides shelter information as a smart phone map. The map includes markers that are placed on the location of the shelters. If the user of our system clicks a marker, the tooltip extends the shelter information such as the name, open/closed status, address, and rate of occupancy. Furthermore, the color of the marker represents the current occupancy rate of the shelter, as shown in Fig. 5. When the color of the marker turns red, it indicates that the occupancy has increased. We believe it will be easy to understand for general evacuees. The map and markers will automatically update if the data in the database are affected, and thus users can check the shelter information in real time.

  • (4) Web API: The web API connects the three subsystems mentioned above. In the relationship among the web crawler, web API, and database, the web crawler fetches the updated data and posts the data to the web API. The database then stores the data posted from the web API. Regarding the relationship among the Shelter Maps App, the web API, and the database, the Shelter Maps App requests map-related resources from the web API, and the web API transfers the request to the database. The database then passes the requested data to the Shelter Maps App through the web API.

The developed, consisting of the sub-functions described above, provides the shelter conditions for evacuees in real time. In the next section, we describe the prototype system and its behavior based on a simulation using actual data from a regional disaster.

Fig. 5.
figure 5

Relationship between color of the marker and the occupancy rate. (Color figure online)

Full size image

4.3 Case Study

In this section, we introduce a case study and implementation of the prototype shelter condition visualize function. For the case study and use of the prototype, we collected data from a past disaster, i.e., typhoon Hagibis in 2019.

Kamaishi city, Iwate Prefecture, Japan, was selected as the case study area because the data required for this research were obtainable. Kamaishi is located in northeast Japan, faces the Pacific Ocean on the east, and has a population of 32,000 and a total area of 440 km2. The city has been damaged by numerous tsunamis: during the Sanriku Earthquake in 1896, Sanriku Earthquake in 1933, and Great East Japan Earthquake in 2011, 4,985, 409, and 1,046 people died or went missing in the city, respectively. Moreover, other disasters such as floods caused by typhoons have occasionally occurred in the city.

Owing to these events, the city manages multiple disaster shelters and publishes its data on a website. We focused on typhoon Hagibis, which hit on October 12, 2019 and collected shelter-related data on the typhoon. The data used for the prototype system were obtained from the following websites:

  1. 1.

    Unstable data including the open/closed status and the current number of evacuees of the shelter are published on the Iwate Disaster Prevention Information Portal by Iwate Prefecture [13] in HTML format.

  2. 2.

    Some stable data, including the shelter name, address, longitude/latitude, and types of disasters to be dealt with, are published on Designated Emergency Evacuation Site Data by the Geospatial Information Authority of Japan [14] in CSV format.

  3. 3.

    Other stable data, including the capacity of the shelters, are published by Iwate Prefecture [15] in PDF format.

  4. 4.

    In addition, data on welfare shelters, i.e., shelters for people who need extra help such as the elderly and disabled people, are published by Kamaishi city [16] in HTML format.

We developed and used a web scraper to gather data written in Node.js and Nightmare.js [17]. As a result, we obtained shelter-related data for a total of 226 shelters from the start of the disaster on October 12, 2019 to the closing time of the last shelter on October 28, 2019.

We developed the prototype shelter condition visualize function and used the collected data in the case study. We used the following programming languages and frameworks to develop the prototype:

  1. 1.

    For flexible software combining the web API and database, the Hasura GraphQL Engine [18] was used.

  2. 2.

    For the Shelter Maps App, Vue.js [19], a reactive front-end framework, and Leaflet [20], an open-source JavaScript library for mobile-friendly interactive maps, were applied.

We did not develop the web crawler to collect the shelter-related data in real time. In addition, to maintain confidentiality, the capacity of evacuees and the actual evacuee data from the welfare shelters could not be contained in the prototype function data. Instead, we simply set the green markers to indicate welfare shelters on the map of the prototype system.

An example of a display image of the prototype Shelter Maps App is shown in Fig. 6. The positions of the markers show the shelter location based on the latitude and longitude information. The color of the markers presents the number of evacuees per shelter at a particular time. The users can see which shelters exceeded the capacity limit, allowing them to avoid going to these locations, and instead evacuating to one of the shelters presented by a blue marker.

When a user clicks a marker, the tooltip extends. The tooltip contains information on the name, address, current number of evacuees, and capacity of the shelter. This function helps users check these current condition data and make a decision regarding where to evacuate.

We confirmed that both the desktop and mobile versions of the Shelter Maps App operate without any problems. However, the function is currently under development and has some missing functions. For example, the Shelter Maps App should show the user’s current position and the optimal evacuation path to the safe shelter on the map. The web crawler is not yet used in the prototype system, and thus we should implement, test, and confirm that the system works well during an actual disaster.

We are planning to add these missing functions and update the prototype function. Further, we will introduce the Shelter Maps App to actual regional areas and verify whether the users can actually evacuate safely and quickly to the optimal shelter in the case of a disaster.

Fig. 6.
figure 6

Example of a display image of the prototype Shelter Maps App. (Color figure online)

Full size image

5 Discussion

5.1 Location Visualize Function of SRP and Supporters

The developed location visualize function can show the positions of supporters, SRP and evacuation shelters. The information of SRP can be obtained based on the SRP list prepared by local government office. However, the list is usually not disclosed to protect personal information. In the case of disaster, the list needs to be quickly provided in available condition to supporters. When the supporters use the application, the application needs to get the location information on each supporter. So, the location information of every supporters should be “ON” condition so that it can be obtained using GPS.

5.2 Shelter Condition Visualize Function

Conventional research [5,6,7] has shown that sharing disaster-related information through visual methods, such as maps, is more effective than using text-based methods. However, these studies did not consider some limitations, such as the capacity of the shelters and the dynamic transition of the conditions during an actual disaster evacuation. Our newly developed function provides information on the capacity of the shelters and the changing conditions in real time. We expect that the developed function will be useful under not only real disasters but also evacuation drills because it can provide conditions on both real shelters and virtual shelters in a simulation. Further, the proposed method can be adopted in other areas that require information on the shelter conditions. For example, a government can create a new shelter construction plan or assignment plan for current shelters based on real experiences or disaster simulations. However, the function is still in the development stage, and there are two issues that should be resolved: (1) data reusability and (2) data format standardization.

Data Reusability.

It is necessary to transfer a large amount of data that are difficult to reuse, such as the location and capacity of the shelters, into digital information. Regarding the data that are difficult to reuse, there are some available examples, such as data on the capacity of the shelters, published as PDFs, and data on the open/closed status of the shelters, expressed as HTML text. However, the HTML text is currently only surrounded by a <p> tag and has no semantics. In the case of the developed prototype, we parsed the HTML texts and found a designated regular expression, and converted the information into a PDF file manually to be used as data in a database because there is no way to correctly recognize text in a PDF. If the data that are difficult to reuse are converted beforehand into a general format such as CSV or JSON, or as published data on a standard web API, the data will be much easier to obtain using a web crawler.

Data Sharing and Data Format.

Currently, data sharing between government staff members in evacuation shelters and in government offices is typically conducted using a paper-based method. For example, in Morioka city, Iwate, Japan, the current population of a shelter is sent by Fax, using the format. In this case, the city-level government (Morioka city office) receives the Fax, and then transcribes it on a spreadsheet tool such as Excel. The spreadsheet is then sent to the prefecture-level government (Iwate Prefecture office) by Fax again. Thus, there is a large time lag when sharing the information, which does not occur in real time. To solve this problem, we believe that digitizing the format for government communication during an emergency will be an effective approach. As a tool for digitalization, web-based and cloud-based spreadsheet tools such as Google Sheet will be suitable in terms of usability and availability. We expect that such a digitized format will increase the speed of the data sharing and increase the opportunities of evacuees to obtain the latest information as a result. We also plan to propose an optimal data input/output format using Google Sheet for government organizations in Japan.

6 Conclusion

In this study, we described the importance of early evacuation in the case of natural disasters in regional areas. Then, this paper showed an evacuation time-line model and indicated that the actually required and important information were the location information of Support-required People (SRP) and supporters, and the current shelter’s detail condition. To realize an early evacuation, the evacuees need to know the shelter conditions in detail and real time. But, there was a problem that the shelter information was not integrated on government websites, people could not determine the best shelter for evacuation. To solve the problem, we newly developed the location visualize function which could share the information on the location of SRP and supporters, and shelter conditions in real time. We also presented a case study of the prototype shelter condition visualize function for Kamaishi City in Iwate Prefecture, Japan. We concluded the function would be helpful for local residents to accurately understand the state of evacuation shelters in detail.

By using our proposed Real-time Evacuation Support System (RESS), which is integrated the location visualize functions of SRP, supporters and shelter conditions, every evacuees can easily check the necessary information in real time on a map and can evacuate in the optimal way. As a result, we believe the system will contribute to reduce the risks of human damage in natural disasters.