A data model for operational and situational information in emergency response
- 2.1k Downloads
- 7 Citations
Abstract
Many software systems have been created to help the emergency responders in their activities all over the world. These systems are usually dedicated to a specific emergency situation or emergency response sector. Exchange of information between the different systems is difficult or not possible. While much progress is observed in accessing and sharing existing data, management of field (or dynamic) data is often overlooked. A lot of information coming from the field operations is either not archived or is stored in an unstructured way. This makes the analysis of data a difficult and slow process. This paper presents a data model for the management of dynamic data. The data model captures the situational information—incident and its effect—and the operational information—processes activated, people and departments involved. New data types are created for temporal and spatiotemporal information: dynamic counts, e.g. the number of injured or missing people, moving point and moving region, e.g. the position of vehicles or people and the gas plume. The model is derived from the emergency response procedure in the Netherlands. The information needs resulting from this procedure are, in a large part, valid for emergency situations everywhere, therefore the model can be easily adapted for other countries.
Keywords
Database schemas Spatiotemporal data Disaster management GIS Hazards Urban areasIntroduction
The first hours after a disaster strikes are not only very chaotic and difficult but also the most important for successfully fighting the consequences, saving human lives and reducing damages in public and private properties (Diehl and van der 2005; Rao et al. 2007; Zlatanova and Fabbri 2009). Usually several primary organisations are involved in the first-response operations such as the fire brigade, paramedics, police and municipality. Depending on the scale of the disaster, other organisations, e.g. civil protection centres, defence units or Red Cross, might be involved as well. All these organisations rely on well-defined policies and procedures, as well as on the most complete and up-to-date information about an incident.
A multitude of systems are developed to facilitate the operations during an emergency response. These systems are created for specific types of disasters (Benjamin 2009; Chen et al. 2008; Skhal 2006) or as solutions to different problems in emergency response by use of a specific technology (Bahrepour et al. 2010; Erman-Tüysüz and Havinga 2010; Madey et al. 2006; Malizia et al. 2010; Zografos and Androutsopoulos 2008). The works presented in Jennex (2007), Kovel (2000) and Turoff et al. (2004) offer a holistic approach to the design of emergency systems, providing a framework, principles and requirements for such systems. A complete inventory of the information needed during the emergency response is still lacking. This is because of the large variety of types and scales of disasters and the diverse views and interpretations of the different emergency response sectors.
One of the important factors in any emergency response operation is the situational awareness, which can be created only after careful analysis of all the available information (existing and dynamically created in the field). While a lot of progress has been made to access and share existing spatial data (DHS-GDM 2009; Mansourian et al. 2005) or real-time sensor information, some dynamic data such as location/tracking of rescue units, plume movement, flood area changes, etc. are still underestimated. Dynamic data are usually stored as a collection of files without a specific structure. The structuring would facilitate a fast access to a desired piece of information as well as the automation of data analysis and its use in the decision-making process. A database system is perfectly suited for these as an organised way of storing the data, having mechanisms that enable fast access, and functionality for the analysis of data.
This paper presents the conceptual and logical database schemas for the dynamic information created during emergency response. These are the result of a thorough investigation of user requirements (Diehl et al. 2006; Snoeren 2006; Snoeren et al. 2007) collected from all the primary emergency response sectors in the Netherlands. The information needs were translated into a conceptual data model, followed by the logical data model and its implementation in Oracle Spatial. A first version of this model was presented in Dilo and Zlatanova (2008) containing information from a part of emergency response sectors. This paper elaborates on further developments of the model, which includes the information from all the primary sectors. The dynamic data modelled here, together with existing data, which are accessed via Web services, are to be used in an emergency response system. Tasks performed by different actors in the emergency response are translated to context-aware services, which use the dynamic and the existing data, and are accessed via well-designed user interfaces (Scholten et al. 2008).
The following section summarises the information needs for the emergency response. ‘Data model for dynamic information’ presents the developments in the conceptual model and elaborates on the contribution and the views of different emergency response sectors over the (complete) data model. ‘Implementation of the model’ discusses the Oracle Spatial implementation of the data model and presents some examples of querying the data. The last section concludes with analysis of the development and outlines directions for further development and research.
Information needs
A disaster incident in the Netherlands is managed through legally established processes (Diehl and van der 2005; Diehl et al. 2006; Dilo and Zlatanova 2008). The processes define the responsibilities of the first responders (on land): fire brigade, paramedics, police and municipality. They are defined to deal mainly with small and medium disasters, therefore the term used is ‘incident’. Although aimed for all kinds of disasters, these processes do not define the responsibilities of other institutions, e.g. military forces and Red Cross, that are often involved in large disasters. Each process has a well-defined objective, which realisation requires certain information and often produces information during its execution.
The information needed for emergency response (ER) is grouped into two large categories: static information, i.e. existing prior to disasters, and dynamic information that is collected during a disaster incident. The static information consists of: reference data, e.g. topographic maps, aerial photographs and height data; managerial and administrative data, e.g. census data and administrative borders; risk maps containing dangerous settlements, e.g. gas stations, storage places of dangerous goods and vulnerable objects, e.g. schools and nursing homes; utility networks, e.g. gas, water, electricity; cadastre containing owners and cadastral boundaries. Most of these data are commonly available in topographic, cadastre and municipality offices, as well as in private companies. Some information can be specific for an emergency sector. For example, accessibility maps for buildings and industrial terrains and water sources (fire hydrants, un-covered water and drilled water well) are created for the needs of the fire brigade.
Dynamic information is collected during a disaster incident from the processes activated to handle it. Processes are grouped into four clusters according to the ER sector that is mainly responsible for them, fire brigade, paramedics, police or municipality. The information collected from the processes of one cluster is used inside this cluster and the other clusters as well. This information consists of situational information, about the incident and its effect, and operational information, about the processes activated to handle an incident, responsible departments and persons together with their roles. Examples of situational information are: type, scale and affected area of an incident; casualties as number of trapped, missing and injured people; a set of measurements that is performed in case of detection of dangerous substances in the air, water or in the ground. Examples of operational information are: a process that started to handle a disaster and the time it is active; a department responsible for a process; and a team that performed a measurement. As investigations have shown (Snoeren 2006; Snoeren et al. 2007) much of this information is common for all the emergency response processes. Most of the information produced during emergency response is temporal, i.e. it is changing with time, and we need to keep track of changes.
Some additional information might be important to share with emergency responders, e.g. in case of flood, velocity and water depth as well as flood pattern; for an aircraft incident, the type of plane, its function (cargo, military or civilian), the number of people on board or the type of fuel and volume. Such information has to be gathered from other organisations than primary emergency sectors. For example, information about the actual water levels and the likelihood of a flood are to be obtained from the Ministry of Transport, Public Works and Water Management. The model that is described in this paper is restricted to information collected by the first emergency responders. The additional information will be accessed via web services, as well as the static information, and merged with the information coming from the first emergency responders from the services provided via the user interfaces.
An incident could be hypothetical, e.g. a forthcoming large concert or important football match, or a real incident, e.g. serious traffic accident, explosion, gas leakage, a train or a plane crash. The real incident starts with a call to the call centre. The call is dispatched to the emergency response units in the corresponding safety region. Based on the type of the incident, several processes are activated, each process involving one or more departments. Dependent on the severity and scale of the incident (defined in the GRIP levels (Diehl et al. 2006)), more safety regions, ministries or private and public organisations can be involved. Beside individual roles, the processes define roles for teams. All processes require information to complete the tasks. Several processes ‘produce’ data, which should be collected and reported to the control and commando centre. The produced data are related to the incident description and its effects, damages, locations of rescue teams, measurements, etc. The information is reported either as a free text, a drawing, or via filling out a template. For example, when the incident involves release of dangerous substances, a template for measurements is in use. Several measurement teams are formed and sent in the field to perform measurements, from which the shape and the direction of movement of the gas plume is derived.
The way that information is reported is not of importance for the model. However, if templates are used, the intention was to preserve the structure of the template. Additionally, only sensors that are in possession of the emergency responders are considered. For example, data from optical (images and video) or range (laser scan data) sensors are not modelled.
Data model for dynamic information
We used Unified Modelling Language (UML) profiles for database design to model the ER dynamic data and Enterprise Architect as the modelling tool (Sparks 2001).
Conceptual schema
Conceptual schema for dynamic data: classes together with their associations shown by arrows and association classes
Part of the conceptual level showing classes and their attributes
The class Sectormal represents a template used by the person receiving the emergency call; it is created in case the incident involves spreading of dangerous substances in the air. It allows defining approximately the affected area based on information received from the complaints and meteorological information. The information from Sectormal is used to determine locations where measurements have to be performed. Measurement tasks are compiled according to the situation. Measurements are performed following the task, which results are stored in Measurement. These are used to define more precisely the gas plume. It is computed by a dedicated programme on the basis of the measurements, meteorological information, gas chemical characteristics, etc. The resulting shape is stored in Gasmal. An incident often causes damages in infrastructure and people. The classes DamagedCar, DamagedBuilding and EventObject reflect damage in cars, buildings and utility networks, while Casualty and DamagePA reflect damage in people and animals. The last two contain dynamic counts, e.g. number of missing people. These numbers change in time, and we want to keep track of the history of changes. The class EventObject is also used for unclassified spatial objects, i.e. information that cannot be formally described and is different according to the incident. The class contains an attribute description where long descriptive text can be stored. Incident data together with sectormal, measurements, gas plume and damages compose the situational information.
A RealIncident is managed by one or more Processes. As soon as an incident is initiated, the departments involved in it will be specified. In a real incident, the number of the involved departments may increase as new processes are started. Class Department contains information about a department unit. A department is responsible for several processes started for the same incident or processes of different incidents. Several departments may be responsible for the same incident (in case of large incidents). The association ResponsibleFor keeps track of the responsible departments for each process. A department may own one or more vehicles, e.g. a fire brigade owns trucks and boats. Class Vehicle keeps information about vehicles, and BelongTo takes care of the ownership. Class DMSUser contains information about the system users, i.e. emergency response people that are users of the ER system. A system user is involved in different processes of one or different incidents at different times. The association InvolvedIn contains the duration of such involvements. During the response to a disaster incident, several teams are created with people from the ER sectors and volunteers. The class Team keeps information about teams, e.g. number of its members, position of the team. Not all persons from a team are necessarily users of the system, but there is one person who has access to the system. The association Lead indicates the team member that is a system user. A team uses a vehicle to travel to the place of the incident, which is captured by TravelWith association. The information about the emergency response sector (classes within the dashed-line box in Fig. 1) together with processes and their associations constitute the operational information.
Views from different ER sectors
Information used or created by the fire brigade
Information used or created by the paramedics
The fire brigade (ER sector) is responsible for processes coded 1 to 7 (see Fig. 3). Data are produced during the execution of these processes (shown by the ‘create’ label). Other data are needed for the execution of processes, probably created by other sectors (shown by the ‘use’ label). For example, classes MeasurementTask and Measurement contain data created by the fire brigade. They are derived from templates used by the fire brigade and reflect the information related to giving order and performing the measurements (see Dilo and Zlatanova (2010) for more detail). The class MeasurementTask contains location where the measurement should be performed, time of this task assignment and instructions what to measure. The Measurement contains the results of a measurement task and the time that the measurement is accomplished.
The paramedics are responsible for processes coded 8 to 10 (see Fig. 4). Data collected by them are related to injured people and information about relief centres. A very interesting template is the PatientCard that is used by paramedics to record data about medical condition of injured people. The information collected in the patient card is complex, but well structured. The class PatientCard contains the complete information of the analogue patient card (GHOR 2008). New data types are created to reproduce the structure of the patient card: Triage, Exposure, Treatment, MedicalHistory. These are used in the PatientCard class to compile the complete information: personal data, e.g. gender, name, birth date and address; the place where the person was found; allergies in case (s)he has; medication that was given; medical history; the last meal the person has taken; type of injury, exposure to chemical substances or radiation; treatment; triage; etc. Triage is a categorisation that defines the priority levels of handling a patient in the range of 1 to 4. It is a dynamic process: a group of medical checks are performed for a patient in a repeated manner at different places, e.g. at the incident, in the first aid camp, at the hospital or after different treatments that are given to him/her. Counts of patients in each triage category are saved in the Casualty class, together with few other dynamic counts.
Implementation of the model
The conceptual model described in section ‘Data model for dynamic information’ is translated to a logical database schema for Oracle, followed by another translation to SQL (Structured Query Language) scripts for creating the actual tables in Oracle Spatial. We performed automatic translations within Enterprise Architect. The result of each translation was modified in order to get the correct model for the corresponding level.
Oracle Spatial database schema
Logical schema for dynamic data: oracle spatial tables and relationships
The automatic translation does not resolve correctly association classes, dependencies and their identifiers, identifiers consisting of more than one attribute, and specific data types. For example, the association class InvolvedIn between DMSUser and Process is translated to a table resolving the many-to-may association and another separate table containing the attributes, which has no relations to the concerned tables. We replaced the two tables with a new table, UserInProcess, that is a merge of the two separate tables. Classes Sectormal, Gasmal and Casualty that are dependent on RealIncident are converted to tables that have no relation with the RealIncident. The identifier of RealIncident ought to be the identifier for each of these tables. Instead, the translation adds a superfluous attribute to each table as its identifier. The identifier of Process is the attribute pair (incidentID, process_type), while the automatic translation has added the superfluous attribute processID as the primary key of the table. The translation assumes a primary key attribute named after the table name, and adds the attribute in case there is no such. For example, EventObject contains an attribute objectID as identifier, whereas the translation added an attribute eventObjectID as primary key for the table. Several data types in the data model require special treatment, e.g. the spatial types, enumeration types, and boolean. The spatial types were changed to MDSYS.SDO_GEOMETRY, which is the spatial type of Oracle Spatial for all point, line, polygon and solid types. The enumeration types were changed to NUMBER(); the numeric values are used as codes that refer to values in the enumeration list. The boolean types were changed to CHAR(1), and a check constraint is added to restrict values to true and false.
Very important for the model are the temporal and spatiotemporal data types: DYNAMIC_NUM for dynamics counts, e.g. number of missing people; MOVING_POINT for dynamic points, e.g. position of a team in the field; and MOVING_REGION, e.g. the gas plume.
The general approach for temporal data in DBMS is to consider all the records as facts, which can be associated with time when the facts are valid (time stamps). Time stamps are added at the record (object) level or at the attribute level. This is the common approach used also by the most GIS or CAD/AEC systems. Several temporal models have been proposed; some of the models store change at the instant it occurs, others store the period during which a fact or a database state exists (Zaniolo et al. 1997). Classical research on spatiotemporal databases has focused on discrete changes: sporadic events (volcano eruptions and earthquakes), stepwise constant changes (headquarter of field operational team); later research concentrates on continuous changes and uses the term moving objects (Güting et al. 2000; Güting and Schneider 2005). The latter is followed in this implementation. The value of MOVING_POINT attribute is stored as a sequence of pairs point location and time, and a MOVING_REGION as a sequence of pairs polygon geometry and time. Different interpolation techniques can be used for calculating point position and polygon shape for any moment of time (see Meratnia (2005) and Meratnia and de By (2003) for moving point interpolation).
provides as well for an internal storage table TeamPosition, where the data of the nested table column are placed. The following section discusses about the storage, analysis and visualisation of spatiotemporal data.
Spatiotemporal data visualisation and analysis
a Trajectories of six teams in the field; b trajectories of the measurements teams in the last 2 h of an incident
The spatiotemporal data are to be used in the analysis that is performed to help the decision-making process during an emergency. For example, an AGS adviser (for dangerous substances) needs to know the positions of measurement teams in the last two hours. This requires analysis of dynamic data: selecting the positions of measurement teams (\(\texttt{TEAM\_TYPE} = 2\)) since 2 h from the actual time. Figure 6a shows the trajectories of six teams in the field, and Fig. 6b the positions of the measurement teams (12 and 14) in the last two hours.
Analysis usually requires combination of existing data with the dynamic data, which in turn requires combination of spatial functionality (on static data) with spatiotemporal functionality. For example, to organise the evacuation procedure during an incident the command and control centre needs information about the threatened area (dynamic data), residential buildings and the number of registered people in these buildings (static data).
Spatiotemporal operators are to be build on the spatiotemporal types introduced in ‘Spatiotemporal data visualisation and analysis’ to provide the functionality for data analysis. These functions should provide for resolving typical queries during the emergency response, e.g. find police vehicles that are in a radius of 5 km from the incident; which police car is the closest to the incident; calculate the route for an ambulance, which does not overlap with the gas plume; evaluate the evacuation area for the next 8 h from the gas plume shape and its prediction.
Conclusions and future work
This paper presented a spatiotemporal model to handle operational and situational information in emergency response. It was developed after a careful investigation of the information flow from processes performed by the first responders: fire brigade, paramedics, police and municipality. It practically represents pieces of information that are currently collected in an analogue way (paper templates), via telephone or digitally (but stored in an unstructured way). It captures the type of disaster, the involvement of response sectors (allowing registration of their locations), consequences of disasters for people, animals and infrastructure and captures other significant objects. The model is derived from the organisation of emergency response in the Netherlands. Nevertheless, the information that is presented in the model is general for the emergency response to disaster incidents in any country. To our knowledge, it is as well one of the first disaster-independent models. Besides some top–down models such as the model of Department of Homeland Security Geospatial model (DHS-GDM 2009), a large amount of emergency response models have been developed for a specific disaster type, emergency organisation or specific activities (Zlatanova et al. 2010).
The model is currently tested for the management of spatiotemporal data as being the most challenging. Further experiments are needed to validate all the developments and especially the digital replacements of the templates used by the fire brigade and the paramedics. Appropriate digital templates and interfaces (on mobile devices) are needed as well.
Further extension of the model would be to accommodate higher GRIP levels which means involvement of a wider range of organisations, more actors (i.e. people with specified roles) and wider range of information. The model is to be part of a complete ER system where the dynamic data will be combined with existing data accessed via the internet. Investigation of the functionality needed over this combination followed by the development of such functionality is another direction for future work.
The model will be further linked to other existing and dynamic models applying spatial reasoning approaches. It should be realised that emergency response may face a large variety of data and no model can be able to predict and classify all possible variations. Geographical information used in emergency response may have different terms (and definitions), data structure, format, specification etc. and can be maintained by distinct institutions. The heterogeneity of data can be very high and transformation between geographical data is inevitable. One of the most complex problems to solve is semantic heterogeneity. In this respect it is expected that ontology will help in defining the meaning of terms, which will reduce the time for transformation and integration of data (Fan and Zlatanova 2010; Xu et al. 2008). Furthermore, ontology can support context-related search of data. If the data are not relevant to the context, it is useless to the user in that situation. Ontology based systems will allow the user to communicate with the system and between themselves in a more natural way.
Notes
Acknowledgements
The authors would like to acknowledge the Dutch Programme ‘Space for Geo-information’ that made possible the funding of this research as part of the project ‘Geographical Data Infrastructure for Disaster Management’. The work is partially funded by the Dutch project SENSA under the COMMIT programme.
Open Access
This article is distributed under the terms of the Creative Commons Attribution Noncommercial License which permits any noncommercial use, distribution, and reproduction in any medium, provided the original author(s) and source are credited.
References
- Bahrepour M, Meratnia N, Havinga PJ (2010) Fast and accurate residential fire detection using wireless sensor networks. Environ Eng Manag J 9(2):215–221Google Scholar
- Benjamin D (2009) Best practices in chemical emergency response preparedness and incident management: rendering comprehensive models through the utilization of streaming meteorological data, active sensor readings, complex terrain compensation, and GIS intelligence. J Chem Health Saf 16(3):26–29CrossRefGoogle Scholar
- Chen R, Sharman R, Chakravarti N, Rao HR, Upadhyaya SJ (2008) Emergency response information system interoperability: development of chemical incident response data model. J. Assoc. Inf. Syst. 9(3–4):200–230Google Scholar
- DHS-GDM F (2009) Geospatial data model. Federal Geographic Data Committee (FGDC), Department of Homeland Security, Version 2.7Google Scholar
- Diehl S, van der Heide J (2005) Geo-information for disaster management, chap. geo information breaks through sector think, earth and environmental science. Springer, Berlin, pp 85–108Google Scholar
- Diehl S, Neuvel JM, Zlatanova S, Scholten H (2006) Investigation of user requirements in the emergency response sector: the Dutch case. In: van de Walle B, Song Y, Zlatanova S, Li J (eds) Second symposium on Gi4DM, Goa, India, p 6Google Scholar
- Dilo A, Zlatanova S (2008) Spatiotemporal data modeling for disaster management in The Netherlands. In: van de Walle B, Song Y, Zlatanova S, Li J (eds) Information systems for crisis response and management. Harbin Engineering University, pp 517–528Google Scholar
- Dilo A, Zlatanova S (2010) Data modelling for emergency response. GISt report 54, Delft University of TechnologyGoogle Scholar
- Erman-Tüysüz A, Havinga PJ (2010) Data dissemination of emergency messages in mobile multi-sink wireless sensor networks. In: Med-Hoc-Net 2010: the 9th IFIP annual mediterranean ad hoc networking workshop. Juan Les Pins, FranceGoogle Scholar
- Fan Z, Zlatanova S (2010) Exploring ontology potential in emergency management. In: Proceedings of the Gi4DM conference—geomatics for disaster management, Torino, IatlyGoogle Scholar
- GHOR (2008) Basisleerstof GHOR. Tech. rep., GHOR Academie, Nederlands Instituut Fysieke Veiligheid Nibra, Arnhem, the Netherlands (in Dutch)Google Scholar
- Güting RH, Böhlen MH, Erwig M, Jensen, CS, Lorentzos N, Schneider M, Vazirgiannis M (2000) A foundation for representing and querying moving objects. ACM Trans Database Syst 25(1):1–42CrossRefGoogle Scholar
- Güting RH, Schneider M (2005) Moving objects databases. Data management systems. Morgan Kaufmann, San FranciscoGoogle Scholar
- Jennex ME (2007) Modeling emergency response systems. In: Proceedings of the 40th Hawaii international conference on system, sciencesGoogle Scholar
- Kovel JP (2000) Modeling disaster response planning. J. Urban Plann Dev 126(1):26–38CrossRefGoogle Scholar
- Madey G, Szabo G, Barabási AL (2006) Wiper: the integrated wireless phone based emergency response system. In: Alexandrov V, van Albada G, Sloot P, Dongarra J (eds) Computational science—ICCS 2006. Lecture notes in computer science, vol 3993. Springer, Berlin, pp 417–424CrossRefGoogle Scholar
- Malizia A, Onorati T, Diaz P, Aedo I, Astorga-Paliza, F (2010) Sema4a: an ontology for emergency notification systems accessibility. Expert Syst Appl 37(4):3380–3391CrossRefGoogle Scholar
- Mansourian A, Rajabifard A, Zoej MJV (2005) SDI conceptual modeling for disaster management. In: ISPRS workshop on service and application of spatial data infrastructure, Hangzhou, China, pp 125–130Google Scholar
- Meratnia N (2005) Towards database support for moving object databases. Ph.D. thesis, Twente University, Enschede, the NetherlandsGoogle Scholar
- Meratnia N, de By RA (2003) Trajectory representation in location-based services: problems and solution. In: Santucci Kea (ed) Proceedings of fourth international conference on web Information systems engineering workshops (WISEW’03), pp 18–24Google Scholar
- Rao RR, Eisenberg J, Schmitt T (eds) (2007) Improving disaster management: the role of IT in mitigation, preparedness, response, and recovery. The National Academies Press, AtlantaGoogle Scholar
- Scholten H, Fruijter S, Dilo A, van Borkulo E (2008) Remote sensing and GIS technology for monitoring and prediction of disaster, chap. Spatial data infrastructure for emergency response in Netherlands. Environmental Science and Engineering. Springer, Berlin, pp 177–195Google Scholar
- Skhal K (2006) Wireless information system for emergency responders (WISER). J Med Libr Assoc 94(1):97Google Scholar
- Snoeren G (2006) Rampbestrijdingsprocessen: Actoren, werkwijze, data. Internal report for GDI4DM, Bsik project RGI-239, Public Aid ‘Gelderland Midden’ (in Dutch)Google Scholar
- Snoeren G, Zlatanova S, Crompvoets J, Scholten H (2007) Spatial data infrastructure for emergency management: the view of the users. In: The 3rd international symposium on Gi4DM, Toronto, CanadaGoogle Scholar
- Sparks G (2001) Database modelling in UML. Methods & Tools, Spring 2001, pp 10–23Google Scholar
- Turoff M, Chumer M, van de Walle B, Yao X (2004) The design of a dynamic emergency response management information system (DERMIS). J Inform Tech Theor Appl 5(4):1–35Google Scholar
- Xu W, Dilo A, Zlatanova S, van Oosterom P (2008) Modelling emergency response processes: comparative study on OWL and UML. In: van de Walle B, Song Y, Zlatanova S, Li J (eds) Information systems for crisis response and management, Harbin Engineering University, pp 493–504Google Scholar
- Zaniolo C, Ceri S, Faloutsos C, Snodgrass RT, Subrahmanian VS, Zicari R (1997) Advanced database systems. Data management systems. Morgan Kaufmann, San FranciscoGoogle Scholar
- Zlatanova S, Dilo A, de Vries M, Fichtinger A (2010) Models of dynamic data for emergency response: a comparative study. In: Joint symposium of ISPRS technical commission IV & AutoCarto 2010 symposium on geospatial data and geovisualisation: environment, security and society. American Society for Photogrammetry and Remote Sensing, International Society for Photogrammetry and Remote Sensing, and Cartography and Geographic Information SocietyGoogle Scholar
- Zlatanova S, Fabbri AG (2009) Geospatial technology and the role of location in science, earth and environmental science, chap. Geo-ICT for risk and disaster management, vol 96. Springer, Berlin, pp 239–266Google Scholar
- Zografos KG, Androutsopoulos KN (2008) A decision support system for integrated hazardous materials routing and emergency response decisions. Transp Res Part C Emerg Technol 16(6):684–703CrossRefGoogle Scholar