Twitter-Based Safety Confirmation System for Disaster Situations

: In the aftermath of disastrous events in Japan, safety information and rescue requests, as well as emergency alerts and damage situations, have been shared on Twitter. However, even victims who are familiar with smartphones or similar devices and social media cannot easily share detailed information, such as the coordinates or address of their current location, which are essential components of safety information and rescue requests. Moreover, local governments and rescue experts have difficulty in gathering such tweets from Twitter. In this paper, we propose a novel system to enable the victims to share their safety information, make rescue requests, and enable quick information gathering for decision making by local government staff or rescue experts. The proposed system is a Twitter-based safety confirmation system named T-@npi. Using the proposed application, the users can easily submit their safety information and send rescue requests on Twitter. The users who want to confirm the safety information can check it quickly on Twitter or via this system. Furthermore, the registered safety information is displayed on an online map to support rescue and assistance activities by local governments and rescue experts.

In Japan, large-scale natural disasters, such as earthquakes and floods, are frequent.After a disaster, many people try to confirm the safety of their family and friends, usually by fixed-line and cellphone calls [13].However, the communication infrastructure in Japan is often disabled for long periods after a large-scale disaster.For example, the Great East Japan Earthquake of March 11, 2011 caused extensive damage to communication infrastructures.After the earthquake, many fixed-line and cellphone calls were disrupted.In many places, this situation persisted for a long time because the communication carriers took control of network traffic to prevent congestion.Immediately after the Great East Japan Earthquake in 2011 and the 2016 Kumamoto Earthquake, many people who were blocked from telephone communication by traffic congestion could access the Internet [14].In this situation, Twitter was used for safety-information sharing, rescue requests, emergency alerts, and damage reports [15][16][17].Similar situations occurred during recent disasters such as the 2017 Northern Kyusyu Heavy Rain Disaster and the 2018 Japan Floods [18].Twitter has become an important tool for communicating safety information and rescue requests.
To request a rescue on Twitter in Japan, the @TwitterLifeline account [19] suggests a rule as follows: • Victims should use the hashtag #救助 (meaning #Rescue) and describe accurate and detailed information, such as the requirements, pictures, address, and location on the tweet.• When rescued, victims should report that they have been rescued and should immediately remove the rescue-request tweet that was previously posted.
This rule was posted as a tweet on September 11, 2015 and July 10, 2018.During the recent major flood events, many tweets clarified the rescue needs of their posters using rescue request hashtags such as #救助 (#Rescue) and #救助要請 (meaning #Rescue_request).The effectiveness of tweets with these hashtags has been discussed [20][21][22].To accomplish rescue activities based on the rescue request tweets in future disasters, we require a system that can effectively share such rescue requests as well as safety information.
The above background highlights the need for a novel system through which victims can share their safety information, make rescue requests, and enable quick information gathering for decision making by local government staff or rescue experts.In this paper, we propose a Twitter-based safety confirmation system (T-@npi), a web application that can be accessed by any web browser or device connected to the Internet [23].The name T-@npi derives from the Japanese word "安否" (pronounced anpi), meaning the degree of a person's safety.This paper introduces the operation of T-@npi and a preliminary operational test of the system.The remainder of the paper is organized into Section 2, which describes the related services and studies, and Section 3, which explains the proposed T-@npi system and performs an operational test of safety-information registration by the system.The paper concludes with Section 4.

Safety Confirmation Services in Disaster Situations
The safety of victims must be confirmed immediately after a large-scale natural disaster.Various services are provided for confirming individual safeties.Google Person Finder [24] is a web service that helps people to reconnect after a disaster.The site was launched in 2010 and was used after the Great East Japan Earthquake of 2011, the 2011 Christchurch earthquake, the 2010 Haiti earthquake, the 2013 Boston Marathon Bombing, and other disasters.In the aftermath of the Great East Japan Earthquake, 670,000 people were recorded on the service.Restoring Family Links [25] and Safe & Well [26] also provide online systems for sharing safeties and missing-persons information.
Safety confirmation services in Japan include the Disaster Emergency Message Dial (171) [27] and the Disaster Emergency Message Board (web171) [28].Communication carriers provide these services as alternative channels when the network is congested by a large number of safety confirmation phone calls.After the Great East Japan Earthquake, both 171 and web171 were not used by many people [13].Sekiya and Fukasawa analyzed the reasons why few people use the systems for confirming safeties in disaster situations [29].Examples of such reasons include that the systems are not used at ordinary times, and these systems are difficult to use.To sum up, to gain the maximum advantage from these services, users checking for safety information must use them actively, and victims who have registered their information must use them frequently.Hatayama reviewed the safety confirmation systems including 171 and web171 [30].This article noted an importance of immediate confirmations for people needed to be rescued and such systems cannot contribute to the rescue activities for survivors.Considering that point, the above systems can be useful only to deliver the information about safe people from the disaster affected areas to the outside of the area.
The utilization of social media services is an effective solution for confirming safety information because many people use them at ordinary times and are familiar to them.Some social networking services (SNSs) can provide their own safety confirmation services.An example is Facebook, the most popular SNS worldwide [31].In such a system, users in a disaster zone are expected to confirm their safety by reply, and the response is sent to the users' friends on their respective timelines.A popular communication tool in Asia is LINE (https://line.me/en/), which is more suitable than Facebook for confirming the safety of users to close friends.Users of the LINE application are sent requests for their safety, and their responses are displayed on their timelines [32].On Twitter, many tweets were posted during the recent disasters in Japan.However, Twitter itself does not provide any functions to facilitate sharing the safety information.

Rescue Request Tweets Posted during Large-scale Disasters in Japan
Certain studies have reported the use of social media posts as emergency-dispatch platforms outside Japan [33,34].However, as of yet, no official rules or procedures have been established to respond to rescue request posts in Japan.
A large number of tweets, including safety information and rescue requests, were posted on Twitter during the Great East Japan Earthquake in 2011.Regarding the earthquake, Neubig et al. developed an extraction system using natural language processing (NLP) for disaster-response situations to extract tweets containing safety information [35].Aida et al. developed a website which extracted the rescue request information [36].The website automatically listed similar statements by text filtering to extract the rescue requests from Twitter.This article reported that the website could contribute to execute emergency calls.
As mentioned in Section 1, tweets with rescue request hashtags such as #救助 (#Rescue) and # 救助要請 (meaning #Rescue_request) were posted in the recent major flood events.The use of such hashtags in tweets posted during the 2017 Northern Kyushu Flood has been analyzed in multiple studies [20][21][22].Sato indicated that not many tweets with such hashtags included detailed information on the location of the victims, the current state of damage and injuries, or the number of injured victims, which are necessary to achieve rescue.In fact, only a few rescues were accomplished based on the rescue request tweets [21].On the other hand, Nishikawa et al. collected and analyzed the tweets with rescue request hashtags posted during the 2018 Japan floods [22].The result indicated that the tweets requesting rescues included area names, landmark names, or street numbers, which could prove to be useful when specifying the place where the rescue was needed.However, in both two flood events, many tweets did not include the information directly related to rescue requests.Therefore, we have difficulty in extracting tweets truly requesting rescues.Song and Fujishiro studied a method to efficiently extract the tweets requesting rescues from the dataset of tweets with hashtag #rescue posted the 2018 Japan Floods [37].It performed with a relatively high accuracy rate of 64.7%.To increase the accuracy of extracting the tweets requesting rescues, the victims are required to provide accurately detailed information.However, even people who are familiar with smartphones or similar devices and social media cannot easily provide detailed information.Therefore, a system is required to facilitate sharing the rescue request tweets.

Facilitation of Sharing Disaster-related Information
Geographic information systems (GIS) have also been utilized for disaster response [38,39].One GIS-based framework extracts credible posts on Twitter (tweets) with geographic information in the context of disaster-situation awareness [40].
The integration of social media data and GIS applications has become important for disaster prevention and mitigation.Uchida et al. proposed a web application called the disaster information tweeting and mapping system (DITS/DIMS) [41,42].In this system, smartphone users can easily send their disaster-related information through Twitter, and the registered information is mapped on an online map.This system allows local government staff to gather information and share it with citizens.Educational workshops on disaster prevention using this application have also been organized [43].Similarly, Uchida et al. also proposed a chatbot application on LINE for sharing disaster-related information has been proposed [44].The application enables LINE users to send the information with easy operations and share it on Twitter.These studies commonly aim to help and encourage users to share the disaster-related information actively.By a similar approach in those studies, we propose a system to facilitate the sharing of the safety information and rescue requests.

Proposed Application T-@npi
We propose a Twitter-based safety confirmation system (T-@npi) that enables disaster victims to share their safety information and rescue requests, enabling quick access to the disaster information for decision making by local government staff or rescue experts.

Requirements
The requirements of the proposed system are listed below: 1. Social media adoption: The safety information of victims should be confirmed as quickly as possible after a disaster.The proposed system requires the use of social media such as Twitter for efficient information sharing.2. Facilitation of sending rescue requests: Victims needing to be rescued must provide detailed information and the coordinates of their location on a tweet, as instructed by @TwitterLifeline [19].However, even people who are familiar with smartphones or similar devices and social media cannot easily provide such detailed information.Thus, the proposed system must be equipped with a function that sends rescue requests via an easy operation.3. Renewal and deletion of old information: As instructed in [19], users who sent a rescue request should remove the rescue-request tweet after the rescue, and then update their status (rescue or self-resolution of the emergency).To prevent the spreading of old information, the proposed system requires a reregistration function by which users can delete the previously posted rescue request and post the new information.4. Encouraging mutual and public help: Self-help, mutual help, and public help are important for disaster prevention and mitigation.The existing services can share a user's safety information with families, relatives, and friends (i.e., self-help), but lack functions for sending and sharing rescue requests by victims in trouble (i.e., mutual and public help).To facilitate rescue and support activities, the safety information and rescue requests should be shared with local governments and rescue experts (enabling public help), and with neighbors of the victims.The needs of a large-scale disaster may exceed the capacity of local governments, firefighter rescue parties, and police officers, necessitating the assistance of neighbors (i.e., mutual help.)Thus, the proposed system must support both mutual and public help.5. GIS integration: The registered safety information and rescue requests must be mapped on an online map for decision making decisions by local governments and rescue experts.

Twitter Adoption
In the proposed application, Twitter was adopted for the following reasons: • Twitter is a widely used service.Consequently, most users are conversant with it, and thus, they can use the proposed application easily.Moreover, since users do not often use existing services such as 171 and web171, they are not familiar with using them, and this has been a bottleneck in regard to the acceptance of these applications.The application proposed in this paper addresses this problem.

•
Although Twitter has been previously used for rescue requests and other information sharing, rescue requests are not supported by the existing services such as 171 and web171.Therefore, these services are limited to the communication of safety information only.The proposed system overcomes this limitation.

•
The proposed system is inexpensive.As information is exchanged only on Twitter, the proposed system requires no large-scale hardware.

•
The system administrators and operators do not need to maintain their individual information because all users are uniquely identified by their respective Twitter IDs.

•
Unlike Facebook and LINE, Twitter is an open social media, meaning that the proposed application supports mutual and public help.

Assumed Users and Devices
The application is intended for three types of users.
• Sending user: A user who posts his or her safety information.

•
Confirming user: A user who checks the safety information post of another individual.The confirming user is expected to "follow" the sending user on Twitter.

•
Supporting user: A user such as a local government staff member who checks the safety information of a disaster-stricken area.
User devices are assumed to be smartphones, tablet PCs, or general PCs.

System Outline
The programs of the system are written in PHP (Hypertext PreProcessor), JavaScript, and MySQL database.All programs are deployed on an internet server.The PHP scripts call the Twitter API (application programming interface) [45] to post and search for information on Twitter.
The system is outlined in Figure 1. Figure 1a explains the operation of registering and sending the safety information.Sending users access the T-@npi system through a web browser and enter their safety information on the registration page.This information is simultaneously recorded in the database of the T-@npi system and tweeted on the user's Twitter account.If the user tweets a rescue request, the information is emailed to a supporting user.The e-mail notification is an additional channel that improves the reachability of the rescue request to supporting users.When the sending user reregisters the safety information, the database record is renewed, and the previously posted tweet is deleted.If the reregistering sender has previously requested a rescue, the renewed information is also emailed to the supporting user.Figure 1b explains the operation of confirming the safety information.The confirming users who follow the sending user can find the safety information on the sending user's Twitter timeline.If needed, the confirming user can then distribute this information on Twitter.The supporting users can determine the status of their supported disaster area and view a list or map of the safety information submitted by the sending users from the system's database.

Index Page
Figure 2 shows the index page that appears when a user first accesses the application via a web browser.The user selects the desired operation by pressing one of three buttons: "自分の安否情報を発信・修正する (Register/reregister your safety information)," "他の人の安否情報を検索する (Find somebody's safety information)," and "安否情報の一覧表示 (List the registered safety information)."

Registration of Safety Information
Figure 3 shows the flow of registering and reregistering the safety information.A first-time sending user registers the information by pressing the "Register/reregister your safety information" button on the index page (Figure 2).After a Twitter authentication, the registration page shown in Figure 4 appears (Figure 3a).The registration page displays the items to be provided by the sending user.

•
Selection of rescue request (item (1) in Figure 4): The rescue-request item offers two options, "YES" (a rescue is needed) or "NO" (no rescue is needed).If the sender selects "YES," the tweet to be posted includes the hashtag #救助 (#Rescue).If the user selects "NO," the tweet to be posted includes "Rescue is not needed."• Selection of safety status (item (2) in Figure 4): Sending users can select one or more checkboxes to communicate their safety status: "無事です (Fine)," "被害があります (Injured/damaged)," "自宅にいます (At home)," and "避難所にいます (At an evacuation center)."The status choices are based on those of web171 [28].

•
Additional comment (item (3) in Figure 4): The sending user can enter a comment of up to 40 characters.

•
Current location of the user (item (4) in Figure 4): The location information (latitude and longitude information) of the sending user is obtained by global positioning and geolocation systems and is called by JavaScript.This information is transformed into an address by a reverse geocoding service [46].In the current version of the proposed system, address transformation is available only in Japan.When a user selects the "はい (Yes)" button for the query "現在地も合わせて送信しますか (Do you send your current location information together?)," the user's address is sent together with the safety information.Otherwise, the address is registered as "N/A."If the sending user's device cannot detect the location or the user does not want to provide the location information, the address is also registered as "N/A." Once the "Submit" button is pressed, the relevant information is recorded on the system, and a tweet is posted on Twitter (Figure 3b).The information of a rescue request is notified to the supporting user by e-mail.The confirming user following the sending user can check the sender's tweets on Twitter. Figure 5 is an example tweet of the safety information when the sending user needs a rescue and provides his/her current location information.Figure 6 is an example tweet of the safety information provided by a user not needing rescue, and who does not provide the current location.

Reregistration of Safety Information
Registered sending users can renew their safety information on the system database, remove their previous tweets, and repost their renewed statuses on Twitter.To reregister their safety information, users press the "Register/reregister your safety information" button on the index page shown in Figure 2.
When users who previously tweeted a rescue request need to reregister their updated information, they are presented with the page shown in Figure 7, which asks whether a rescue is still required (Figure 3c).If the "はい (Yes)" option is pressed, the page moves to the registration page shown in Figure 4 (without asking the necessity of the rescue request).The sending user then enters the current safety information on this page.When the "Submit" button is pressed, the entered information is recorded on the system, the previously posted tweet is deleted, a renewed tweet is posted on Twitter, and the information is emailed to the supporting user (Figure 3d).If the sending user no longer needs a rescue, he or she should press the "いいえ (No)" button on the page in Figure 7.As in the "YES" case, the user is directed to the registration page shown in Figure 4.When entering the current information, the rescue requirement of the tweet is described as "救助された、不要にな っ," meaning "Already rescued/no longer needed" (Figure 3e).Again, the updated information is emailed to the supporting user.Figure 8 shows an example of a tweet in this case.When a sending user who previously registered a "No rescue needed" post reregisters the information, the page shown in Figure 9 appears.This page asks whether the user wishes to renew the previously registered safety information.If the user presses " は い (Yes, reregister the information)," the page is redirected to the registration page shown in Figure 4.When the information on this page is reregistered, the former record on the database is renewed, and the former tweet is deleted.

Confirmation of Safety Information
As shown in Figures 5 and 6, a confirming user can check the safety information of his/her following people on the Twitter timeline.In addition, the confirming user can check the safety information by entering the Twitter ID of the sending user he/she wants to find on the page shown in Figure 10.

List and Map view for Supporting Users
The proposed system displays the safety information recorded on the database in both tabular and online map (Yahoo!Japan map) formats.In this way, supporting users can collect the safety information and support victims. Figure 11 shows the map view of a rescue request on this page.The supporting user can filter the information by location and/or rescue-request selections, sort the information on the table, and view it.The mapping is accomplished on Yahoo!Japan online map via the JavaScript Map API [47].The map displays only the safety information that is accompanied by location information.Table 1 provides the meanings of the icon markers on the map and the background colors in the list.When users click on an icon, the information related to that icon is displayed in a balloon (Figure 12).The table and map provide the sequence number on the database, the Twitter ID, the registration date and time of the information, the rescue necessity, the safety information, the location of the information when registered, and a comment.The rescue necessity is one of "必要 (needed)," "不要 (not needed)," or "解決 (no longer needed)."

Operational Test for Registration of Safety Information
To verify the submission of safety information by users, an operational test was conducted from October 30 to November 20 of 2018.The experimental participants (42 in total) were 17 students from the School of Information and Telecommunication Engineering (IT) and 25 students from the School of Business Administration (BA).All students were recruited from Tokai University (Tokyo, Japan).A single account created for this test was shared among all participants.Only one participant failed to submit their safety information, seemingly because they did not correctly enable the location function of his smartphone.
After completion, the operational test was reviewed in a group discussion.None of the IT participants reported difficulty with operating the system.Some participants opined that more detailed information could be provided by offering more functions and answer options.In contrast, some of the BA participants considered that the system should be simplified.The differences in opinions appeared to depend on the skills of the smartphone operations.The skills problem could be solved by providing two types of registration pages: easy mode and advanced mode.
Moreover, the opinions and contentious aspects of the system were obtained from a questionnaire allocated to each participant.Representative comments from the participants are shown below.

•
It would be useful if I could check people who have found my information.(IT)

•
The web application (accessed by web browsers) is time-consuming compared with a native application.This should be improved.(IT) • To popularize the system, the application should collaborate with other popular applications used in ordinary times.(BA)

•
The system should additionally collaborate with SNSs other than Twitter.(BA)

•
The application may be abused because we can post anonymously.(BA) The above comments will guide the improvements of the proposed system.During recent large-scale natural disasters in Japan, Twitter is used to share the safety information and rescue request.It is important to confirm people needed to be rescued quickly.Thus, to accomplish the rescue activities based on the tweets requesting rescues, the victims must provide detailed information such as the coordinates or address of their current location, which are essential components of safety information and rescue requests.Moreover, the local governments and rescue experts need to have a solution to quickly gather such tweets from Twitter.In this paper, we proposed a Twitter-based safety confirmation system called T-@npi.The proposed system enables the victims to easily share their safety information and rescue requests including essential components.The registered information can be mapped on an online map for quick responses by local governments and rescue experts.The system encourages not only self-help, but also mutual and public help, which are important for disaster prevention and mitigation.The registration of safety information was evaluated in an operational test of the proposed system.In future work, we will apply the proposed application to disaster prevention drills in collaboration with local governments.We will also extend the present application into a dual-purpose application that can be used on a daily basis.

Conclusion
(a) Sending the safety information.(b) Confirming the safety information.

Figure 1 .
Figure 1. Outline of the proposed system.

Figure 2 .
Figure 2. Appearance and operation of the index page.

Figure 3 .
Figure 3. Flow of registering and reregistering the safety information.

•
Record to T-@npi server • Post tweet which incudes #Rescue • Notify the supporting user by an email Y Y Check last record at Confirmation page (Figure 7), which asks whether rescue is still needed or not Is rescue still needed?Y • Renew record on T-@npi server • Remove last tweet • Post tweet which incudes #Rescue • Notify the supporting user by an e-mail • Post tweet • Record to T-@npi server Y N N • Renew record on T-@npi server • Remove last tweet • Post tweet including "Already rescued, no longer needed" • Notify the supporting user by an e-mail N • Record to T-@npi server •

Figure 4 .
Figure 4. Registration page of safety information presented to the sending user.

Figure 5 .
Figure 5. Example tweet of the safety information posted by a user needing rescue from the specified current location.

Figure 6 .
Figure 6.Example tweet of the safety information posted by a safe user from an unspecified location.
Summary of Google MapHyperlink to Google map Hyperlink to T-@npi Comment Rescue requests: [Rescue is needed, #Rescue] Address of Current location Safety information: [Injured/damaged, At an evacuation center] Hashtag means a post by T-@npi Hyperlink to T-@npi Comment Rescue requests: [Already rescued, no longer needed] Current location Safety information Hashtag means a post by T-@ npi

Figure 7 .
Figure 7. Page for confirming whether a sending user who previously requested a rescue still needs the rescue.

Figure 8 .
Figure 8. Example of a safety information tweet indicating that the sending user no longer needs a rescue.
Rescue requests: [Already rescued, no longer needed] Current location Safety information Hashtag means a post by T-@ npi

Figure 9 .
Figure 9. Page that requests whether the sending user wishes to reregister the safety information.

Figure 11 .
Figure 11.List and map view page for the supporting users.

Figure 12 .
Figure 12.Safety information displayed on the list and map view page for the supporting users.

Table 1 .
Descriptions of the list and map.