Keywords

1 Introduction and Motivation

We have had two great earthquakes in Japan in recent twenty four years. The Great Hanshin-Awaji Earthquake on 17 January 1995 caused severe damage to Awaji Island and Kobe area in western Japan, and 6434 people died, 3 are missing and 43792 are injured [1, 2]. The Great East Japan Earthquake on March 11th, 2011 caused severe damage to the northern coast of the main island in Japan, and 15894 people died, 2546 are missing and 6156 are injured [3]. While we have had many natural disasters in Japan, only a few researchers in information processing have been working on the issue such as the use of IT for disaster management. The issue has been researched for long in the other countries [4, 5].

We learned from the related work [5] that case studies were of great help to many researchers. Moreover, we learned that Hiltz and Plotnick started interviewing risk managers on the use of social media [6, 7]. Consequently, we interviewed officers, doctors and volunteers who worked for the earthquake and tsunami emergency response in Iwate and found that information for situation awareness is needed desperately for the first responders [8, 9].

At the disaster, while the inefficiency of the entire communication network would be treated as the major problem for information exchange and situation awareness, we found another important problem that there was no information system available in Japan for immediate use in emergency response. From this perspective, we try and use our IT knowledge to implement systems to be used in disaster response and recovery so that we could see what could be usable. We have implemented some systems required to help out the disaster area [10], such as an unattended store service with a POS system with prepaid cards [11], designed for a use in a trusted community, in temporary housing, the tsunami information system based on Open Street Map (OSM), and a recovery watcher system to keep people being aware of how recovery goes in the disaster area by reporting images from the disaster area [9, 12]. We describe particularly on the recovery watcher system which was originally designed for the recovery phase in the disaster management cycle [5], but could be used for situation awareness in the early stage of emergency response as well. We also found that the system could be also applicable for support for barrier-free.

In this paper we introduce our work on recovery watcher and present some findings. The next section we describe some related work. We present our work on the recovery watcher system in Sect. 3. We discuss on its use for the other use of the system such as emergency response for situation awareness in Sect. 4. Section 5 gives some conclusions.

2 Related Work

Recovery Watcher is an information sharing system through images from cameras set at the disaster area. In this section, we introduce similar systems, one for recovery monitoring developed at Kyoto University and the other prepared for environmental educations. Both systems have several camera sites over Japan and share the images from those cameras to the users. The former has the similar purposes with our system, whereas the latter has been set up primarily for the environment education and included audio as well. Those systems as well as our system are almost similar each other in terms of system architectures, we describe the issues of such systems in the end of this section.

2.1 The Recovery Monitoring Project at Kyoto University

The project team monitored the recovery process after the Great Hanshin-Awaji Earthquake in 1995 by use of CCD cameras in the disaster area and distribute the images over the web [13, 14]. According to the project web page [15], cameras were set up in various places in Northern Japan after the Great East Japan Earthquake in 2011. Those cameras were planned to operate by 2020, however, some of them are terminated now. The system was used for the Chi-Chi Earthquake in Taiwan in 1999 as well as the Miyake Island volcanic eruption in 2000. In case of Miyake Island, the system was used to show the people in the disaster area for evacuation.

The system is composed of a CCD camera at the disaster area sending the image periodically, a few times a day to the server and the images are presented through the web. The images are recorded in the database as an archive, so that one can get back to the images in past. They are stored in a USB memory locally as well for back up.

The system is very similar to our work on recovery watcher, although we do not have a backup local memory. Our system uses a smartphone as a camera with its latest version, so that one can submit his/her image easily.

2.2 Cyber Forest: Live Monitoring Project

The project started in 1997 and provides real-time live monitoring and archiving experiences for environmental education to school children [16] to sense environmental changes in real time. The system provides the information in audio as well as images by use of microphones and web cameras without human attendance. Some environmental data such as temperature and humidity in a natural environment are also provided. Images can be presented as a stream over the web in so-called live monitoring [17]. The system has been used also for disaster recovery observation after the Great East Japan Earthquake in 2011. The system links to SNS such as twitter so that users can share the information and get the related information easily. The system is supposed to provide archives, but some sites are not working currently.

Cyber Forest presumes audio information important which is different from our system. For environmental studies, such information may well bring the feeling of nature to the users. On the other hand, for observing the recovery would need to capture the scenery in which people are passing by and may cause privacy issue caused by the audio information.

2.3 The Issues in Observation of Disaster Recovery

Both systems have similar functions with our system. They provide archives, but some archives are not provided due to the continuity of the project. We have had the same problem. For disaster recovery observation, we might need some continuity scheme, perhaps over the different projects to share some interface or data exchange so that the uses can keep observing the recovery process even one project site is terminated.

Audio information could be useful for situation awareness to know such as how strong the rain is falling or the sound of river when disaster is supposed to come. On the other hand, for recovery observation, we would have privacy issues. We need to carefully design such systems.

Cyber Forest presents environmental information, which would be useful for our system in future for people to be aware of the situations in their areas. Accordingly, the system could be used for warning before a disaster as well as for evacuation after the disaster. The information would be useful for the first responders as well.

3 Recovery Watcher

It takes long to recover and reconstruct the towns and cities at disaster area. Meanwhile the interests into such recovery and reconstructions would be faded out outside the disaster area as time goes by. Accordingly, we came up with the idea on recovery watcher to keep people being aware of what is happening. On the other hand, we could use the system for situation awareness at the early stage of disaster management cycle such as emergency response and even at the rescue phase.

3.1 The Previous Systems

In the beginning, we use the u-stream service and located a camera at the town hall of Yamada, Iwate, Japan. The system used video so that it took some bandwidth at the town hall. We implemented a still image-base system which did not need so much bandwidth [12]. It recorded images in a calendar so that people can look back on the past. We located the system in other two cities in Iwate as well. The system was operated for several years but due to administration changes, we needed to stop operations.

3.2 The Use Model of the Current System

This time, once again we implemented the system with the use of smartphones as cameras. Figure 1 shows the model of the system.

Fig. 1.
figure 1

The model of the current Recovery Watcher System

Full size image

Smartphone cameras are to be located at multiple places in the disaster area. Images are to be uploaded to the server which provides the image share space through Open Street Map (OSM) [18]. Users can also upload images which they take. Uploaded photos from cameras are stored in the space so that one can look them up thought the OSM. Those from users would be managed by the information manager before they are stored in the share area.

The information manager may manage the uploaded sites so that if we add a new camera site, the new calendar will be prepared by the manager so that we control the camera sites.

The users look up for a place over the OSM and look up for the images, current ones as well as archives through the calendar. The smartphones will use either Wi-Fi connections or telecommunication links.

The users can look up for the information from the disaster area and may give some feedback comments. They could also upload the images if they were in the disaster area.

3.3 The System Architecture

We design the system as in Fig. 2. We use a mobile device as a smartphone as a camera and send the images periodically. The server receives and store the images from the registered camera.

Fig. 2.
figure 2

The architecture of the current Recovery Watcher System

Full size image

Individual users could send some images as well. If the images are coming from individual users, the information manager needs to check them. If the manager admitted, those images are stored in the database as an individual report.

The server manages the database of images with their information such as locations and camera IDs. It also interreacts with the users through the client system to get the request for images and show those requested images.

The users can send the server a request for images and get the images by use of the client system. They may be able to send those images they have taken as a report to the server.

3.4 Implementation

We have implemented with the use of android smartphones as a camera [19]. We use the smartphone with Wi-Fi for the moment to communicate with the server over the internet, so that the camera needs to be located at the place with Wi-Fi access. We use Java for implementation of a camera.

The server includes a web server function for the interaction with the users who look up for the images. For the implantation of the server, we use Java as well as PostgreSQL for access to the database as well as HTML and PHP for user interface through a web page, so that a user can access to the web page either over a smartphone or a personal computer.

The server also needs to produce a camera ID.

For the moment, we have not implemented some of the functions, as follows:

  1. 1.

    To manage the database by the Information Manager

  2. 2.

    To report any image from a user

  3. 3.

    To send any feedback comments from a user

  4. 4.

    To use an OSM map to specify a camera

To implement Function 1 above, we need to define who could be the manager. For instance, a person in charge of each camera could be a manager as well. Function 2 could be implemented so that a user can report their images with comments though the recovery watcher web page. Function 3 may well be developed by use of SNS in future. We started incorporating the recovery watcher to an accessibility map based on OSM which we shall describe later in this section.

3.5 Operations for Barrier-Free Support

In order to examine the operability within our university environment, we used the system for inclusive support in such a way that barrier free information is provided through this system for the people with disabilities as well as their supporters to find out the situation of the university campus. It is interesting to know that such situation awareness is required for inclusive support as well as for disaster. We present two cases; one is the use of a video camera showing a bulletin board on the upper floor in a building which has no lift, and the other case with the current system.

Three years ago, we set up a network camera at a bulletin board on the upper floor of a building without any lift for a student with wheelchair. It was quite similar to our previous version of the recovery watcher system for video images. Figure 3 shows this operation. With the network camera, the information page can be accessed thought the web page with many functions such as moving and zooming. One could argue that the information could be presented on a bulletin board in an electronic way, however, some posters and information are sent to the office in a paper media and it is hard for the people in the office to convert them into an electronic form. The student was pleased to see this system and fount it useful. The camera has a zoom-up function so that one can see more closely. Unfortunately, in some cases, the letters are too small to read even by zooming up.

Fig. 3.
figure 3

The image from the video camera showing a bulletin board

Full size image

Figure 4 shows our current system which has been started running since January 2019. At the moment, a user has to know the camera ID to specify the camera. We would like to link our system to an OSM map so that the users can specify a camera through the map. If the number of camera sites increased, we would need a search function as well.

Fig. 4.
figure 4

The image from the current Recovery Watcher

Full size image

The observation period for taking a photograph needs to be specified at each local smartphone. We set it an hour for the moment. It would have been a lot easier if the period could be controlled remotely through the server by an administrator such as the information manager, however, it was not desirable because smartphones were not designed to be controlled from the outside in principle. The situation is different from the network camera used in case of live video camera for the bulletin board in Fig. 3.

We asked a researcher in northern Japan in March 2019 to test the system in terms of disaster recovery, and found it easy to set up. We brought him a smartphone which has set up with a camera ID. Later he modified the observation period into a few more hours as the scenery was not changing so much. In future, we could automate to adjust the period according to the difference of the image data.

3.6 Results from the Operations

We have implemented the recovery watcher system with smartphone cameras and started evaluation by operations. Through the operations we have found the four issues, privacy, observation period, database (DB) management and accessibility support as follows.

We need to be careful when we set up a camera so that any person can be seen and identified personally on the recovery watcher web page. It is a privacy issue. Unless a person agreed, we cannot take his/her photographs due to a portrait right. Moreover, cyber stalking is a serious threat [20]. In this aspect, we need to implement the functions for a user to send a request to the information manager to delete some images, as well as for the manager to manage the database so that when any problematic image was found or requested, it will be deleted by the manager.

For the period of observation, we could automate to change the specified time duration according to the difference between consecutive images as we report in the previous subsection. Moreover, as in the related work, Recovery Monitoring Project, we may need only a few times a day as in the night, nothing could be seen. On the other hand, if we use the system for emergency response or real time check for evacuation, we would need more frequently uploaded images. The period may vary according to applications.

For DB management, a person in charge of a camera could be the Information Manager as well and need an ability to manage the photograph. The researcher in Iwate told us that sometimes he wanted to delete some photographs. We will need to consider more on what timing we could check and manage the images. Moreover, the problem is the size of the DB. The archives would be accumulated to a great extent. We need a large distributed way to accommodate images. This could make it possible to observe the recovery process for a very long time.

We have implemented an accessibility map based on OSM for a use in a university campus [21]. We would need to have a link to the recovery watcher system as in Fig. 5 in future, so that one could see the situation by specifying the place on a map, and will need to conduct experiments with the users in future. This way, one can prepare before coming to the university campus. Figure 5 presents the floor map in a building, but we may well need to set a camera outside so that when we had a rain or any other bad weather, the users can understand the situations better.

Fig. 5.
figure 5

Recovery Watcher with the accessibility map in a university

Full size image

4 Possible Use Cases of Recovery Watcher

The recovery watcher system was originally implemented for disaster recovery. However, we could make use of the system in various applications. In the previous section, we introduced our experimental use for barrier-free support. In this section, we look into another possibility of application of our system.

For disaster, we found that situation awareness is important in the operation in the beginning of disaster, emergency response including rescue operations based on the interview with the first responders [8]. For the use of emergency response, the images need to be uploaded more frequently. We also need to take a picture on demand. Pictures sent from the local users would be of great help as well. This part could be done by use of SNS. The trustworthiness of the images could be implemented. Meanwhile for the trustworthiness problem of information in text at SNS at disaster was resolved by DISANA [22].

We could also apply to the care of the elderly who lives alone in a community. Solidarity death of the elderly particularly at the disaster recovery is a serious problem at the disaster recovery phase in Japan [23]. It is important to consider privacy of the elderly.

Elevant [24] is working on sharing weather information. Presumably natural disaster could be considered a situation of weather, so that a service for sharing weather information could be used at disaster. Indeed, one of our findings was that at disaster people would not dear to use a new interface of a system; they prefer familiar interfaces. If we provide a service to share weather information for a daily use, we could possibly make use of it for disaster as well.

For a long run, we could use this sort of sharing service to convey the warning information at disaster. One of the big issues at the disaster was that one needed to get out of Tsunami as soon as possible without caring your family members—i.e. we need to help ourselves first. This old wisdom was not passed correctly from generation to generation and brought the tragedy again. The coast area of Iwate was attacked by Tsunami once thirty to fifty years again and again. The question is how one can convey such a warning to remind people daily. Our system could be used for sharing the local weather information for situation awareness daily.

5 Conclusions

In this paper, we introduced our system, Recovery Watcher, designed primarily to observe the recovery process after a disaster. The work was motivated from our support activities just after the Tohoku earthquake and tsunami on March 11th, 2011.

We presented some related work, Recovery Observation Project and Cyber Forest. They are technically similar to our work. The former is more for disaster recovery while the latter is for environmental education to present environmental data with image and audio information. Those system could be operated for long, however, some sites were stopped. The continuity seems important when one starts recording images. In this aspect, our system would have more open architecture so that we could accommodate images and information from different systems in future.

We present the issues of our system, such as privacy, time interval for uploading images, database management and accessibility use. We also describe the possible use cases of our system, emergency response, community watcher for preventing solidarity death of the elderly, and weather information sharing. In any application, we will encounter those issues. We also need to have a popular use case so that people would make use of it at disaster as well. We shall try and keep using the system in various way in future.