Background - The Challenge
Emergency situations in urban areas require: 1) excellent coordination between different relief /rescue groups; 2) appropriate information (especially geo-referenced information); and 3) intelligence in communicating orders and information to different participants.
Emergency response involves many people: rescue teams on the field, decision-makers at different levels of government, citizens, press (Zlatanova 2005 and Winter et.al.2005).Their tasks, and therefore their data needs, vary drastically from making decision to just following the development of the situation.Good collaboration and understanding is needed at each level, and is critical for units and institutions involved directly in managing the emergency (e.g.field workers and high-level decision makers).Most countries have clear, defined, well written and structured agreements regarding responding to disasters but, sad to say, these are not always successfully implemented in real situations.The problem deepens in cases of cross-boarder operations, where teams from different countries should be able to act as one unit (such as the VIKING project for contingency management of high water).
Geo-information plays an important role in every stage of disaster management and response.Small scale, 2D geo-information (maps or satellite images) is insufficient for urban areas.Often indoor information about a building or an underground construction (distribution of rooms, type of construction, materials used, etc.), utilities (pipe lines, electricity switches), facilities (stairs, emergency exits, evacuation possibilities for disabled, etc.) is highly desirable.These data must be found, analyzed and processed, and supplied to the right person at the right moment and in the most appropriate form.
The distributed management of geo-information, the variety of systems, formats, representations and data structures, make this task extremely challenging.Today, numerous organizations design, store and manage geospatial information about buildings, topography, utilities, etc. These organizations operate independently and their work might be even concentrated on an individual life-cycle phase.Hardly any of them work within a multidisciplinary environment, which means they may not have been required to develop interoperable systems.
The information needs to be delivered to people based on their roles and tasks, time constraints, changing circumstances, stress, pain and fatigue, disturbed (or lack of) communication channels, equipment with limited capacity and damaged or destroyed infrastructure.Communicating information to people depends largely on three general factors as discussed Zlatanova and Holweg 2004.
- Available technology (equipment such as hand-held devices, PCs, virtual or augmented reality devices, wired/wireless communication, etc.)
- Level of emergency/danger (is information being delivered to someone actively responding to a fire, or is the person in a safe place?)
- Physical characteristics (age, gender, disability)
The fundamental issue is, what kind of system would be able to respond to these specifics? Many systems address only a specific set of tasks, dedicated to daily responsibilities of the institution (police, fire brigade, ambulance, municipality).Many emergency response offices also have software for analyzing spatial data (Amdahl 2001), but only for a particular disaster (forest fire, water management, earthquake, landslide, etc.) and usually in well known vulnerable areas.Designed for different purposes, these systems lack a robust communication module, analysis functionality, data management (including dynamic field data), or data discovery mechanisms.
The recent disasters have clearly shown that insufficient functionality is observed not only within one unit but also in communication and exchange of information between different units.
A system for an emergency center in urban areas requires:
- discovery and effective use of various information sources (text, imagery, 2D and 3D graphics, video) for monitoring and decision making
- the ability to provide updated information to rescue units, decision makers and citizens fast, almost real-time, communication to transfer on-site information
- rapid, intelligent determination of evacuation routes considering dynamic factors such as current availability of exits, stairs, etc.and the characteristics of the evacuees (age, gender, disability)
- data integration for analysis and prediction of different complexity
- the ability to alert communities at risk and provide information to press and the general public, as well as maintain statistics about victims and damage
- data presentation on handheld and desktop, wired and wireless, equipment, simultaneously
- alternatives for multi-disaster, multi-team work circumstances.
Bearing in mind the nature of emergency response, dynamic collaboration seems the most appropriate approach.Although many aspects of the system require research and development, technically it can be done.
The major components of this set up are 'positioning and communication middleware' (responsible for the contact with the users) and 'data middleware' (responsible for information delivery).Notice that the location of the middleware is not important.It might differ with respect to the selected components (GIS, CAD, DBMS, or combinations of them).
Let's look at how this architecture might be used in one scenario. Heavy rain are causing flooding and landslides in a city.Due to the high population density and the time of occurrence (morning peak rush hour), there are many seriously injured and trapped people within collapsed buildings, and streets are either blocked by ruins or congested by traffic.In a virtual Civil Protection Center, decision-makers and specialist gather together for monitoring and managing the disaster.Different access profiles are created and corresponding access is granted.
The system needs a period of initialization until sufficient information is available to make decisions.This should not be longer than three or four hours.In the first minutes to one hour, everybody (on the field and from the center) sends data (video, images, text reports) on the current situation and location of rescue units. Simultaneously, a request for information is sent to all the servers in the region for appropriate information.It is not clear what kind of data could be useful, therefore everything that can be related to 'risk maps,' 'location of citizens,' 'weather forecast,' 'rivers and sewage system,' 'weak construction,' and 'traffic info' might be of importance.
Once the data and reports from the field are (automatically or semi-automatically) processed, they can be combined with the information from the servers in the area.Depending on the type of information (text, graphics, images, laser scan data, etc.) it might be necessary to employ different software packages or even make contact with other offices.Seamless exchange of data is not a technical problem.In the first few hours the system should contain sufficient data for initial analysis and decision-making.
Water level information (from reports and images), combined with 3D models of the city, and information about buildings and citizens will give indications of the number of people in the building.Information about gas and electricity network switches, integrated with water level information, will provide planning information about eventual failures in regions currently not affected by the water (Figure 2).Having assessed the situation, rescue teams can be deployed.Several ad-hoc wireless network equipped vehicles can be used to establish reliable communication between the operation center and the areas with lost mobile communication.Through this network, ambulance, fire and police crews can better perform their tasks.At the same time, informative SMS messages of critical importance can be sent to citizens warning them about possible further landslides and suggest safe locations.
How to Build Such a System
Such an emergency response system does not require restructuring or changing the systems police, fire brigades or ambulances use now.The two kinds of middleware mentioned previously will be the connecting (integrating) components between the different systems.The data middleware is the most critical component, and it is clear that the responsibility to create it lies with geospatial researchers and developers.It would need to accept and understand requests from users, find the most appropriate, analyze them and/or perform needed processing algorithms (such as calculate evacuation routes), and prepare the data for the user based on his or her need.
Research questions are numerous, and include the following:
- How to search for the best suited data for the current requirements of a request (e.g.a graph model of a building to be able to compute the evacuation)
- How to manage (probably) fragmented data (e.g.the building can be organized by floors in a local coordinate system)
- How to integrate dynamic data to the system that most probably would come in the form of reports, images or video (e.g.information on which stairs are available).
- How to perform semantically based processing, such as map or database generalization, based on the user profile.
Amdahl, G., 2001, Disaster Response: GIS for Public Safety, ESRI Press Redlands, California.
Winter, S., G.Iglesias, S.Zlatanova and W.Kuhn, 2005, GI for the public: the terrorist attack in London, Geoinformatics Magazine, October/November, 2005, 8 p
Zlatanova, S., 2005, Crisis Designs, Geospatial Today, May-June 2005, Vol.4, Issues 1, pp.30-36
Zlatanova, S.and D.Holweg, 2004, 3D Geo-information in emergency response: a framework, in: Proceedings of the Fourth International Symposium on Mobile Mapping Technology (MMT'2004), March 29-31, Kunming, China 6 p.