# Twitter-Based Safety Confirmation System for Disaster Situations
## 3 Proposed Application T-@npi
### 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 0(a) 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 0(b) 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.  
Figure 1: _Cont_.  
* Selection of safety status (item (2) in Figure 4): Sending users can select one or more checkboxes to communicate their safety status: \"(Fine),\" \"(Fine),\" \"(Fine),\" \"(Fine) \"(Iinjured/damaged),\" \"(Fine) \"(At home),\" and \"(Fine) \"(Fine) \"(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 \"(Fine) \"(Fine) \"(Fine) \"(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.  
Figure 3: Flow of registering and reregistering the safety information.  
Figure 4: Registration page of safety information presented to the sending user.  
Figure 5: Example tweet of the safety information posted by a user needing rescue from the specified current location.