Abstract
Spanish abstract
La necesidad de utilizar tecnología móvil en el proceso de respuesta a emergencias urbanas se ha puesto recientemente de manifiesto, debido a la importancia que tiene contar con información de apoyo para la toma de decisiones en dichos escenarios. La presentación de datos en dispositivos móviles pequeños, como PDAs o teléfonos inteligentes, es un aspecto crítico para tomar decisiones apropiadas y a tiempo. Esta criticidad está dada particularmente por el reducido tamaño de la pantalla y el tipo de información a desplegar que usualmente es geográfica. Este artículo presenta una estrategia para seleccionar y visualizar los “Puntos de Interés” más relevantes sobre un mapa digital, de acuerdo al área de influencia de una emergencia y al nivel de zoom utilizado. Esta estrategia fue implementada en la herramienta MobileMap, luego evaluada a través de situaciones de emergencia simuladas. En esta evaluación participaron comandantes de distintas compañías de Bomberos de Chile.
Keywords: Data visualization, Mobile devices, Small-size screen, Geographic information system, Human-computer interaction, Context information, Urban emergencies.
Spanish keywords: visualización de datos, dispositivos móviles, pantalla reducida, sistema de información geográfica, interacción humano-computador, información de contexto, emergencias urbanas.
Received: 2013-03-01, Revised: 2013-11-05 Accepted: 2013-11-05
1. Introduction
In recent years we have seen a revolution in miniaturization and price of mobile and wireless communication devices [ 1], [ 2]. Mobile devices have significantly captured people’s interest, getting inserted into daily work. This has generated many possibilities to develop software to support various activities. Some of the application scenarios are: education, tourism, health services and daily emergencies.
A mobile device screen can be adapted to show information such as weather condition or vehicle traffic. As humans, we are used to find some information in specific locations. Thus, static and dynamic information should be easy to find.
Many researchers have studied the limitations of the small screen devices to appropriately display information [ 4], [ 5], [ 6]. The existing proposals focus on relevant information and they provide an overview of the context information [ 7], [ 8], [ 9].
This challenge is also relevant for mobile applications which support emergencies, especially in urban areas. Some examples of these events are: fires, car accidents, gas leakages, infrastructure collapses, and chemical/water spills.
Some researchers have identified the use of mobile devices during emergency situations as very important. These devices can provide relevant data from the disaster affected area [ 10], [ 11]. Most required information in an emergency is related to geography, such as: the emergency location, the affected infrastructure, the influence area of the event, the location of the available resources needed to deal with the response process. The geospatial information of the affected area is very important to analyze their vulnerability and manage risks associated with it. Such information is also necessary to perform the event response and recovery activities [ 12], [ 13], [ 14].
This paper presents a strategy to display geographic information on smartphones, avoiding information overload. This strategy was implemented as a new version of MobileMap [ 13] that was developed and delivered to help overcome these limitations. We decided to implement a mobile solution on a portable device, since these gadgets are increasingly becoming ubiquitous, and therefore a firefighter could install this solution on his/her own device.
This paper is organized as follows. Section 2 presents the related work. Then, section 3 presents an analysis of audio recordings from past urban emergencies. That section also presents the methodology used to characterize frequency of sent/received messages in the context of an urban emergency. Section 4 describes the proposed strategy to select and display information which is relevant to an emergency context. Section 5 explains the evaluation methodology used to validate the strategy. Finally, section 6 presents the conclusions and future work.
2. Related Work
Burigat and Chittaro [ 15] reported a research related to the effectiveness of visualization on mobile devices based on macro and micro views. The study addresses unexplored aspects of the design of mobile user interfaces. In particular, they investigate the effect of allowing users to manipulate information over maps and highlight the potential Points of Interest (POI) of an area. Some examples of POI are: police stations, water hydrants, hospitals, schools, fire stations, nursing homes, and any other physical point that is important for emergencies situations. The experimental results suggest that both the manipulation of graphical interfaces and the highlighting of important points in the global view, have positive effects on users’ time performance. This allows completing fast search tasks on mobile devices but it does not provide specific advantages in terms of recovery of spatial configuration of POI objectives.
]]> Moreover, Bederson [ 16] conducted a study of the essential problems of Zoomable User Interfaces (ZUI), which highlights there is more useful information than the one that can be shown on the small screen of mobile devices. The most common solutions to this problem of lack of space in the interface are to use scrolls or links to other windows, or use search and zoom options. These researchers conclude that using zoom options creates significant advantages for spatial perception and memory retention of human beings, and improving navigability on two-dimensional images. The study indicates that the ZUI works well whenever there are a few items to show on screen. However the problem persists when many items need to be displayed on the screen. Similarly Chittaro [ 4] conducted a research on a new approach to display Points of Interest (POIs) on the screen of a mobile device. This study proposes and analyzes the results of the "Halo Technic", which tries to show the information of POIs that are off the screen, using a bulb that has an aura associated with it (like shock waves). In that way, the POIs located off the screen, can be predicted visually: its distance and location. The problem with this approach is that if you have several categories of POIs, then you would have to use multiple distinguishable line colors between them, which could overwhelm curved lines on the screen of the mobile device.
Monares et al. [ 13] proposed a solution called MobileMap that allows exchanging digital information between the Incident Commander (IC) on the field and the Alarms Center (AC). The IC is in charge of the response process in the field, and the AC acts as support for it. The communication between these two nodes is by WiFi and GSM networks, using smartphones and laptops. The results show that the tool helps to reduce the arrival time of the firefighters to the emergency scene. MobileMap shows a map with two arrows, one indicating the location of the emergency, the other one, displaying the vehicle direction. However, the approach has some shortcomings such as the displayed information is not characterized and that the mobile device screen becomes saturated.
The reviewed related work shows there are indeed serious problems to display information on the screen of mobile devices. This paper extends Monares’ proposal and presents a strategy to display emergencies POIs, combining Zoom and the selection of POIs within a radius of action and showing objects dynamically and differentiated by colors. Next section presents a study of past emergencies, where we gathered and classified the relevant sent/received information during an emergency occurrence.
3. Identifying Relevant Information for an Emergency
The goal of this part of the research was to try to identify the type of relevant information that should be shown on the MobileMap screen. We also tried to understand the changing behavior of this information. For this purpose, we analyzed audio recordings of past emergencies, in which the firefighters of Ñuñoa, Santiago, Chile participated. This Department is organized in eleven Companies that serve five districts: Ñuñoa, La Reina, Peñalolén, Macul and La Florida (approximately 3 million inhabitants).
The Ñuñoa AC provided the audio recordings for all radio communications of the urban emergencies occurred during one year (2009). Each recording has the interchanged messages during the response process of an emergency (from beginning to end of an emergency). This information is recorded in *.mp3 audio files. For this work, we just considered small-sized and medium-sized urban emergencies, i.e. emergencies having firemen working less than eight hours on-site. Larger emergencies require further collaboration, including larger communication and coordination efforts than the type of emergency responses we would like to support. Table 1 shows the emergencies that occurred in the past five years, which were managed by the Ñuñoa AC.
Table 1: Ñuñoa’s AC urban emergencies ]]>
Some types of emergencies are more frequent than others, e.g., in our data, structural fires, vehicular crash rescues and wild bush fires account for 54.35% of all emergencies in 2009. In our analysis, the audio recordings selected for our study kept the representativeness of emergency types shown in Table 1. Moreover we also got information from interviews to ICs for complementing the information recorded in the audios, e.g. in case when the radio system was unable to record the voice messages, or when the messages were not understandable enough because of signal interferences. Such activity was done during four focus group sessions.
The methodology for the communication study during emergencies is now explained. First, we selected 130 emergencies (from the 2,997 occurrences in 2009) by stratified random sampling, keeping the representativeness of emergency types occurred during those 5 years. The audio recordings of radio messages from these 130 emergencies (covering all types of emergencies) were chosen for analysis.
The selected emergencies were listened (from the recorded audios), analyzed, and every message exchange between the AC and the IC was classified. Firefighters use codes to convey information more efficiently, e.g. they use code “1-2” for “Request for an ambulance at the emergency site”, “0-5” for “Report your location”, “6-3” for “Equipment at site”, etc. In total, firefighters and the AC use approximately 120 different codes of this type. Naturally, most of the relevant recurring messages correspond to these codes. The coded messages in our study were 2,484. The messages that were most frequently repeated are presented in Table 2. This table provides a ranking of the most important messages exchanged by the AC and ICs in the 130 studied emergencies.
Table 2: Most frequent messages 
However, it is natural to consider that to some extent, the exchanged messages depend on the type of emergency (e.g., the data shows that the “report location” messages (code C3) are eight times more frequent in wild bush fires than in emergencies with hazardous materials). Thus, it is important to support both the most frequent and the least frequent messages when proposing a solution for ICs and the AC.
]]> Exchanged messages may also be classified according to their intent. For example, in Table 2 messages C1, C2, C4, C11 and C14 are informative messages with the purpose of notifying all participants of the status of the equipment (e.g. fire trucks), while C3, C5, C9, C10 and C15 are messages with requests, and C6, C8, C12 and C13 are administrative messages. The types of messages that could be classified into these three categories were more than 89%. From all classified messages, 46% were informative, 27% were requests for information, 16% were administrative messages, and 11% were of other types. These statistics allow us to understand the type of information exchanged between the AC and the IC, and the timing of such exchange. In order to support the participants’ information needs and thus try to reduce the radio channels usage, we have extended the MobileMap application.
4. Selection Strategy and Relevant Information Display
MobileMap can be seen as a Geographic Information System, where Points of Interest (POI) are deployed on demand. A POI is a milestone displayable on the map, which has attributes such as: name, icon, latitude, longitude, and a detail.
Figure 1 shows an example of the structure of a POI named "buildings", which is stored in a "buildings.xml" file and displayed on the user interface on demand. The <Type> </Type> tag represents the POI type, for example: water hydrant, hospital, police station, fire company, important buildings, for this specific case the POI stands for "buildings". The tag <Icon> </Icon> represents the name of the icon to display on the map. Generally a file is 30x30 pixels, it has an average size of 1 KB and has a "*.png" file extension. The <Zoom> </Zoom> tag determines the zoom level at which the representative icon is displayed on the map. The <VisibleOnlyInRadio> </VisibleOnlyInRadio> tag has two possible states: "Yes" or "No"; "Yes" indicates that the POI will be displayed only within the range, otherwise it will be shown in and out of range. The <Name> </Name> tag indicates the name associated with the POI. The <Address> </Address> tag indicates the address (street, avenue) in which the POI is located. The <Coordinates> </Coordinates> tag indicates the POI coordinates (Latitude and Longitude).
In the next steps we will describe the main features of MobileMap, its usefulness, then the selection strategy and the implemented POI.
Figure 1: Structure of file “buildings.XML”
4.1. Zoom Levels
In emergency situations, sometimes there is no Internet connection. MobileMap has maps stored in the device. The full maps are composed of small pieces (tiles). The application has 7 levels of zoom. After an usability study we found that from level 6 up it is acceptable to show the POIs on the map. Under the zoom level 6, it is unnecessary to show them because it saturates the screen with icons (Figure 2). To meet this need, the tag has <Zoom> 6 </Zoom> in which the user specifies the zoom level at which the icon will display the POI.
Figure 2: Water hydrants saturate Smartphone screen
To solve the problem of screen saturation, we decided to show POIs in a range, and from a certain level of zoom. Both are configurable; these variables are represented as system parameters and specified in the “config.xml” file. The range is set using the <RadioAccionPDI> tag. For example <RadioAccionPDI> 200 </RadioAccionPDI> indicates that the application will display POIs that are within a radius of 200 meters, with the center point located at the emergency position. An algorithm was designed (presented later in this article) to select and display POIs in that range. The POIs are selected considering that an emergency can occur at the intersection of two or more districts (municipalities). There is a function that calculates the distance between two points; it has two parameters, each one in coordinates "Latitude and Longitude".
]]>4.2. POIs Out of Range
Showing POIs within a range is very applicable for water hydrants, because there are many hydrants installed in the streets. However, there are other POIs to be shown, either within or outside the range, and whose density is not high, such as Fire Companies or Hospitals. For these cases there is a tag named <VisibleOnlyInRadio> No </VisibleOnlyInRadio>; it indicates the POI can be displayed inside and outside the range without any restriction. These new capabilities of information visualization have enabled fast reading of MobileMap and provide a better view of the information displayed on the map.
Figure 3 shows the icon "
" which represents the scene of the emergency, and clicking on the icon you can see the type of emergency. The figure also shows the water hydrants "
" within a range (e.g. 200 meters). This information allows firefighters quick access to these resources to respond to a fire. Using the ruler "
", which is in the toolbar, we can measure the distance between two points. For example, between an emergency location and a water hydrant, or between an emergency location and a school.
Figure 3 (emergency scenario) shows a building very close to the emergency location; it is represented with the "
" icon. If it is populated, those people might be in needed of evacuation. Figure 3 also shows an Area of Interest (AOI) near the emergency (chemical factory), which is labeled "Inflammable". This means the building is close to a dangerous fire, so the fire spread could cause further damage to the infrastructure that is located around it.
Figure 3 also shows fire trucks that have arrived at the emergency site, e.g. trucks BX-4, S-2 and Q-2. The location of the truck is indicated on the map showing an identifier code for each one. The blue ones (marked with "A") represent trucks that are on site of an emergency assignment, or very close to it. The other ones, trucks B-4 and B-5, are represented by green color and assigned the "V" label, indicating that they are coming to the place of assigned emergency (between 800 and 2000 meters of it).
4.3. Areas of Interest
The tool also displays AOIs. Typically these areas represent resources that can be used for the response process (e.g. a water canal or pool where firemen can get extra water to fight a fire) or risk points such as a school, a nursing home or a factory using inflammable material. These AOIs are stored in ".xml" files. The basic structure used to represent the information of an area of interest is similar to that used to represent a POI. Additionally AOI specifications use a tag named <Centroide> representing the coordinates of the figure center (Figure 4), and the <Vertices> tag represents the vertices of the polygon shown on the map for displaying an AOI.
Figure 4: XML file format representing an AOI
The application lets a person send files to the server in the AC. For example a firefighter can take a picture of an important event during an emergency and send that picture to the AC. To perform this task, the application serializes the bytes of the captured image and then invokes a Web Service that runs on the AC server. The service stores the picture in a shared folder (the folder name is configurable in the "config.xml" file) that the system maintains for each emergency. In that way, the picture is available for firefighters assigned to that emergency. The stored filename of the picture is associated with the name of the emergency and concatenated with hour, minute and second of the event when the picture was taken, for example "2046_173010.jpg".
The MobileMap application can also receive files. This feature lets the IC access to context information and makes him/her able to quickly make decisions. Examples of this type of context information are the electrical blueprints and house gas blueprints (Figure 5).
This functionality is also used when the IC wants to inform drivers of other fire trucks about the best route to take, if the typical path is currently closed or congested. In this case the AC can send a map with the route to be chosen to quickly reach the emergency site (Figure 6).
Figure 5: Smartphone displaying an electrical blueprint
]]>
Figure 6: Alternative route to be followed by a fire truck
4.5. Representation of Colors
The application allows you to display the current status of each truck (availability and location), which helps ICs to have an early warning of the trucks they will have available. Table 3 shows the colors code used in the application, based on the truck proximity to the emergency site. This kind of representation allows the IC to identify the distance to their resources, rather than reading each number.
Table 3: Colors and their meaning
The <Detail></Detail> tag can have a variable number of child nodes, e.g. the user can add or remove any features of POIs, as he needs the information. If a POI has no special feature, then the tag could be empty.
In order to get POIs information, first the “.xml” file is located. Once the application locates the file, then it selects the information within it by using XPath. Xpath is an XML Path Language, used to make queries on an XML file. XPath also allows selecting and referencing text, elements, attributes, and any other information contained in an XML file.
Consequently, for a dynamic reading of the detail of a POI, first the XML file containing this information is loaded, then using XPath the POIs are selected and the result is assigned to an XmlNodeList and so manage the information about the POI. Then, each POI is read to obtain information like: name, address, latitude, longitude and other details. If the detail contains child nodes, we traverse each of these nodes using an enumerator. This way of dynamically traversing an XML file is very important to deploy detailed information of POIs on MobileMap. Figure 7 shows a fragment of code that reads an XML file that contains the POIs associated with a POI category, for example the "buildings" category.
