Introduction

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

Figure 1 is the UML class diagram presenting the conceptual model for the ER dynamic information. Central to the model are incidents and processes. An Incident can be a RealIncident or Hypothetical. A real incident is often started from complaints of citizens; many incidents, e.g. gas leakage or fire, may create breathing or eye troubles and the citizens are encouraged to report this to the call centre. The association ReportAbout connects Complaints to the RealIncidents for which they are made. Several complaints can arrive for an incident, as shown from the cardinality of ReportAbout association. Class Incident contains information about: incidentID that is a number for identifying an incident, location of the incident, the fenced area, start and end time, and a text description for the incident (see Fig. 2). A RealIncident is characterised by the type of the disaster incident, which may change during the incident, the affected area by the incident, which is also dynamic (i.e. it changes in time), an estimation of the threatened area together with the estimation time, GRIP level and scale of the incident, both (possibly) changing in time, the escalation risk as a word description and the area to be evacuated.

Fig. 1
figure 1

Conceptual schema for dynamic data: classes together with their associations shown by arrows and association classes

Full size image
Fig. 2
figure 2

Part of the conceptual level showing classes and their attributes

Full size image

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

The model described in the previous section represents the information that is created and used collectively by all the first emergency responders. The data collected by people of one ER sector are used by others within the sector as well as by people from the other sectors. However, not all the classes are relevant for all the sectors. Figures 3 and 4 illustrate the classes that are important for the fire brigade and the paramedics, respectively. (Diagrams for all the emergency sectors are provided in Dilo and Zlatanova (2010).)

Fig. 3
figure 3

Information used or created by the fire brigade

Full size image
Fig. 4
figure 4

Information used or created by the paramedics

Full size image

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

Figure 5 shows the logical database schema. The label PK in front of a column name indicates that it is (part of) a primary key, FK indicates that it is a foreign key, pfK indicates that it is (part of) a primary key that is also a foreign key, and * indicates that the column cannot be empty. For each class in the conceptual level, there is a corresponding table in the logical level. All the one-to-one and one-to-many associations are resolved by primary key—foreign key relations; a new table is created for the many-to-many associations.

Fig. 5
figure 5

Logical schema for dynamic data: oracle spatial tables and relationships

Full size image

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.

The logical schema produced by the automatic translation was corrected for all the above-mentioned problems. Afterward, a model transformation was applied within Enterprise Architect to the corrected logical schema. This second transformation translates the logical model to SQL scripts for creating the actual tables in Oracle Spatial. The automatic generation cannot handle the enumeration lists. Also, the new data types need special treatment. We implemented the enumeration lists as (look-up) tables in Oracle. For example, the attribute process_type takes values from a look-up table Process_Type containing information for all the processes. The table Process_Type is created from:

figure a

It is then filled with information for all the processes. Values of process_type attribute are constrained to codes available in Process_Type table, by its declaration inside the Process table:

figure b

The new data types were added manually to the SQL scripts. For example, the patient card uses the new data type Exposure, which is created by:

figure c

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).

We use nested tables in Oracle for the dynamic types. For example, to create MOVING_POINT type, first an object type is created containing a time instance and point location, which is then used to build the sequence as a table of such objects:

figure d

These new data types are used in tables containing attributes of a dynamic nature. For example, Team table has an attribute position that is a moving point. The SQL command that creates the Team table:

figure e

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 spatiotemporal attribute can be filled by adding values (point location or polygon shape) for each time instant one by one, or a block of values at once. Suppose we have GPS logs for the position of a team in the field and have put the data in a temporary table GPStrack, which contains:

figure f

To insert the data from this flat table into the Team table in our model, e.g. for team with ID = 16, the following statement is executed:

figure g

Each individual record of a spatiotemporal attribute can be accessed by performing an un-nesting of the table. For example, the following statement returns the trajectory of team 16 that was entered above.

figure h

For the purpose of visualisation with web services (Scholten et al. 2008), spatiotemporal data are converted to spatial data. We create views to perform an un-nesting of tables that turns the spatiotemporal types to spatial types, which can be accessed by any standard Web service or commercial software. Metadata are added for the spatial attributes created from un-nesting in order to visualise the data. Figure 6a shows the (dynamic) positions of six teams in the field by visualising data from the view TeamTracking that is created from the Team table by:

Fig. 6
figure 6

a Trajectories of six teams in the field; b trajectories of the measurements teams in the last 2 h of an incident

Full size image
figure i

which structure is

figure j

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.