subscribe

subscribe

International Journal of Applied Earth Observation and Geoinformation 12 (2010) 431–438 Contents lists available at ScienceDirect International Jour...

359KB Sizes 1 Downloads 28 Views

International Journal of Applied Earth Observation and Geoinformation 12 (2010) 431–438

Contents lists available at ScienceDirect

International Journal of Applied Earth Observation and Geoinformation journal homepage: www.elsevier.com/locate/jag

Real-time notification and improved situational awareness in fire emergencies using geospatial-based publish/subscribe Ala’ Kassab ∗ , Steve Liang, Yang Gao Department of Geomatics Engineering, University of Calgary, Alberta, Canada T2N-1N4

a r t i c l e

i n f o

Article history: Received 26 June 2009 Accepted 7 April 2010 Keywords: Geospatial Publish/subscribe Situational awareness Emergency management

a b s t r a c t Emergency agencies seek to maintain situational awareness and effective decision making through continuous monitoring of, and real-time alerting about, sources of information regarding current incidents and developing fire hazards. The nature of this goal requires integrating different, potentially numerous, sources of dynamic geospatial information on the one side, and a large number of clients having heterogeneous and specific interests in data on the other side. In such scenarios, the traditional request/reply communication style may function inefficiently, as it is based on point-to-point, synchronous, and pulling mode interaction between consumer clients and information providers/services. In this work, we propose Geospatial-based Publish/Subscribe, an interaction framework that serves as a middleware for real-time transacting of spatially related information of interest, termed geospatial events, in distributed systems. Expressive data models, including geospatial event and geospatial subscription, as well as an efficient matching approach for fast dissemination of geospatial events to interested clients, are introduced. The proposed interaction framework is realized through the development of a Real-Time Fire Emergency Response System (RFERS) prototype. The prototype is designed for transacting several topics of geospatial events that are crucial within the context of fire emergencies, including GPS locations of emergency assets, meteorological observations of wireless sensors, fire incidents reports, and temporal sequences of remote sensing images of active wildfires. The performance of the system prototype has been evaluated in order to demonstrate its efficiency. © 2010 Elsevier B.V. All rights reserved.

1. Introduction Fire emergency systems are responsive in nature; dispatching and rescuing operations are performed in response to the occurrence of fire crises. Delaying the response would cause an increase in the loss of lives and property, where a few seconds can separate between fire containment and flashover (ESRI, 2007). In order for successful response operations to be conducted, fire services rely on information that is an accurate reflection of the crisis scenario, both prior and during the emergency. Geographical data has been broadly utilized to comprehensively describe the spatial and descriptive semantics of fire hazards and their surrounding features. The advent of Geographical Information Systems (GIS) technology has widely supported the planning, preparedness, mitigation, and delivery of fire services through effective storing, retrieving, analyzing, and processing of geospatial information. This technology has become a key component in the crisis incident management process and as a result can bring numerous benefits to

∗ Corresponding author. Tel.: +1 403 220 4916. E-mail addresses: [email protected] (A. Kassab), [email protected] (S. Liang), [email protected] (Y. Gao). 0303-2434/$ – see front matter © 2010 Elsevier B.V. All rights reserved. doi:10.1016/j.jag.2010.04.001

decision support systems (Keramitsoglou et al., 2004; Wybo, 1998). Here, information communication plays a key role in effectively coordinating sources of situational data from one side, and emergency response teams and other involved parties from the other. Since time is a critical factor in such situations, real-time awareness of crucial data is also of utmost importance. Where information is not made available in a timely manner, important decisions are delayed, leading to failure in emergency response. The distributed nature of dynamic event sources, as well as the variety of parties involved in the emergency, requires a sophisticated data communication infrastructure or protocol to effectively integrate both the data and the parties. The traditional interaction style, namely client/server or request/reply, has been widely adopted for transacting information in distributed systems. In order to obtain particular information, clients have to submit a request (e.g., a database query) then wait to get the response containing the information from the addressed server (i.e., information provider). This point-to-point and synchronous interaction has served information browsing activities very well. However, it is not considered to be an efficient interaction model for emergency support systems. This is due to the fact that it may prevent real-time dissemination of events and leads to rigid structured applications which in turn may affect the scalability of the system (Eugster

432

A. Kassab et al. / International Journal of Applied Earth Observation and Geoinformation 12 (2010) 431–438

Fig. 1. Publish/subscribe system components.

et al., 2003). As of late, the publish/subscribe paradigm is gaining increased attention from researchers and the industry, who hope to overcome the burden of the request/reply model (Eugster et al., 2003; Pietzuch, 2004). ‘Publish/subscribe’ is an asynchronous and powerful event-driven communication paradigm that supports many-to-many interactions between event clients. This communication paradigm aids distributed systems in terms of scalability, integration of autonomous and heterogeneous components, intelligent dissemination of relevant information, and timely delivery of crucial events data. This work aims to develop an information communication framework, based on the publish/subscribe interaction paradigm, that is to be used for disseminating, in a timely way and to the correct location, information about geospatial events of interest; thus contributing to the objective of ensuring public safety and increasing situational awareness. This paper is organized as follows. Section 2 briefly introduces the publish/subscribe interaction model in distributed systems. Section 3 discusses the geospatial-based publish/subscribe interaction framework, and its models. The system architecture of an application for real-time fire emergency notification is presented in Section 4. The performance of the proposed system is evaluated in Section 5. Section 6 provides a brief survey of related works. Finally, we provide a summary of conclusions from this work as well as a brief discussion of future work.

2. Publish/subscribe systems Publish/subscribe is a common interaction model widely used in event-based computing. It manifests a powerful informationdriven middleware for efficient interaction between clients in large-scale and distributed systems (Muhl et al., 2006). By means of this model, clients interact by exchanging event messages, where an event is an instantaneous occurrence of interest or a change of state (Mansouri-Samani and Sloman, 1997). The role of an event client in the system is to produce events, called publishers, to consume events, called subscribers, or to act as a producer and consumer at the same time. Publishers observe their local environment, including their own state changes, and publish events that might be of interest to other clients in the system network. Subscribers, on the other hand, register their interests, called subscriptions, by defining the type of event messages that they would like to receive, regardless the source of those events. The core component of the system interaction is the middleware, also called event-notification service. The middleware component takes charge of conveying event messages between clients asynchronously and in real-time. It handles the publications from publisher clients, matches them with previously registered interests of subscriber clients, and finally pushes the published events to the matched subscribers.

The key concept of the publish/subscribe interaction is that clients are only loosely coupled, since they interact without direct knowledge of each other. The only way in which clients are related to one another is through the content data and the values of the events information messages. This form of interaction ensures that information is disseminated at the right time and to the right place. It also ensures that disparate sources of information, as well as clients with heterogeneous interests in data, are integrated. Finally, it also ensures that the system can scale and grow easily and effectively. Fig. 1 depicts the high-level system architecture and components of a publish/subscribe interaction model. In this work, our focus is to exploit the publish/subscribe interaction in transacting spatial types of events, in other words, events that are related to the geographic space. We refer to these types of events as geospatial events. Geospatial events can be a useful abstraction for representing sudden occurrences of earth phenomena or dynamic state changes of geographic features. GPS locations of emergency vehicles, locations of fire incidents, meteorological sensor observations, and temporal images of wildfire spreading are some examples of dynamic geospatial information that can be represented as geospatial events. Extending the scope of publish/subscribe events to contain geospatial semantics seems promising for numerous web GIS applications. Emergency response situations, in particular, demand that dynamic geospatial information be proactively disseminated to the right people in a timely manner. However, associating geospatial semantics with events in publish/subscribe systems would invoke new challenges to the underlying communication protocol. Thus, the proposed model, namely geospatial-based publish/subscribe, attempts to provide a suitable interaction framework for transacting geospatial events between distributed clients. 3. Geospatial-based publish/subscribe In this section, we propose Geospatial-based Publish/Subscribe, a generic model for transacting geospatial events between distributed clients. Data models used in the geospatial-based publish/subscribe, including the geospatial event model and geospatial subscription model, are presented. The next sub-section describes the structure for each model. Following this, an efficient matching approach for evaluating published geospatial events against registered geospatial subscriptions is proposed. This approach is intended to be implemented as part of the middleware component in order to accelerate information dissemination within the context of geospatial-based publish/subscribe interaction. 3.1. Data models 3.1.1. Geospatial event model A single geospatial event egeo is structured by a set of attributes (a1 , a2 , . . ., an ). Each attribute ai is a name/value pair (ni , vi ) that

A. Kassab et al. / International Journal of Applied Earth Observation and Geoinformation 12 (2010) 431–438

433

Table 1 Examples of spatial interests’ expressions and their respective spatial predicates formation. Spatial interest

Geospatial notification Source desc.

Respective spatial predicate Comparison geometry

Base geometry Gb

Spatial operator SOp

Buffer value buff (m)

Notify me if any vehicle intersects a municipality boundary

Current vehicles positions

Contain

0

Notify me if any fire incident happens within 5 km of my location

Fire incident reporters

Contain

5000

Notify me if any fire spreads to the neighborhood area

Temporal fire spreading area

Overlap

0

Notify me if any police car is within a distance of 2 km from the highway road

Current police car positions

Contain

2000

defines a single property, spatial or descriptive data. Each name ni is assumed unique in the attributes set and has a single data type associated with it. The value vi should be assigned according to the data type of the name ni . The data types supported for constructing the name/value pairs are similar to the SQL data types, briefly: string, integer, float, boolean, date/time, and byte-array. In addition to that, geometry data types for simple geographic features, including GeometryPoint, GeometryPolyline, GeometryPolygon, GeometryMPoint, GeometryMPolyline, and GeometryMPolygon, are added to the collection in order to assign spatial geometries to the generated geospatial events. The value of an attribute that has a geometry data type is a single or conjunction of XY coordinates corresponding to the shape and location of a geospatial event. For instance, a geospatial event that represents the current location of an emergency asset encapsulates an attribute with a GeometryPoint data type and a value of (−1351656.9 1735269.3), (i.e., {GeometryPoint, (−1351656.9 1735269.3)}). Subsequently, to create an instance of a geospatial event, the content data usually comprises two data components, a descriptive component and a spatial component. The descriptive component can be formatted by a set of name/value pairs with traditional data types, such as string, integer, and date/time. On the other hand, the spatial component is defined by adding a name/value pair with one geometry type from the list mentioned above. The following is an example of a geospatial event published by a moving emergency vehicle, Publish[{GeometryPoint, (−1351656.9 1735269.3)}, {AssetID, 4}, {Speed, 87}, {PosTIME, “12/9/2008 1:00:06 pm”}]. 3.1.2. Geospatial subscription model Geospatial subscriptions can be seen as filters or boolean-valued functions that evaluate published geospatial events to determine whether or not they match the defined constraints. One can think of geospatial subscriptions as database queries where the evaluation process is nothing more than selecting the rows that match those queries. Generally, the design of the subscription model should follow the underlying event data model. Having descriptive and spatial content data in the published geospatial events entails incorporating types of predicates capable of expressing specific interests in the descriptive information, as well as in the spatial features of geospatial events. Therefore, two types of predicates are supported

in the geospatial subscription language model: attribute predicates (AP) and spatial predicates (SP). A single geospatial subscription is formulated as, Subi = [SPi , APi (s)] Spatial predicates are introduced in the subscription language model, thereby offering the subscribers more expressiveness to define their interests in geospatial events that satisfy certain spatial constraints. A spatial predicate SPi is defined in terms of three parameters: base geometry Gb, a spatial operator SOp, and a buffer value buff (i.e., SPi = (Gbi , SOpi , buffi ). The following is a list of the supported values for each parameter. • Base geometry Gb: simple features of Point, Polyline, Polygon, Multi-point, Multi-polyline, and Multi-polygon. • Spatial operator SOp: Contain, Disjoint, Cross, Touch, Overlap, Within, and Equal. • Buffer value buff (optional): any numeric value of the type ‘float’. The base geometry Gbi is either one of the simple geometries listed above. The spatial operators listed above have been recognized as basic topological relationships between two-dimensional simple geometries (Franzosa and Egenhofer, 1993; Schneider and Behr, 2006). The output from evaluating a spatial predicate against a geospatial event is a boolean value: true if the comparison meets the function criteria, and false otherwise. For instance, in order to evaluate whether the position of an emergency truck (point object) is located inside a county region (polygon object), the spatial operator contain is used as “(Polygoncounty ) contain (Pointtruck )”. The output here is either true if the emergency truck is inside the county area, or false otherwise. The buffer value buff is an optional numeric value of type float assigned if a zone area is required around the base geometry to be included in the evaluation process. Attribute predicates are utilized to constrain the selection of geospatial notifications according to their content descriptive data. An attribute predicate APi specifies an attribute name string, a comparison operator, and a comparison value, for example “HUMIDITY” > 0.30. The result of this evaluation process is either true in case of a match or false otherwise. If the attribute name string does not exist in the geospatial notification content data, the geospatial notification is considered to not match the subscription.

434

A. Kassab et al. / International Journal of Applied Earth Observation and Geoinformation 12 (2010) 431–438

The comparison operators supported herein are =, >, <, ≥, and ≤ for numeric values, and ‘ = ’ and LIKE for string values. The comparison values should be consistent with the assigned comparison operator. We consider that the definition for geospatial subscriptions, proposed above, can be used to express a substantial level of finegrained interests. Table 1 shows some examples of spatial types of interests in geospatial notifications and their respective expressions of spatial predicates. 3.2. Geospatial events matching approach Published events should be provided to interested subscribers in timely manner. However, incorporating large numbers of clients, with a high diversity of interests (i.e., registered subscriptions) would slow down the real-time delivery of notifications, since the matching process would become more time consuming. Thus, it is necessary to enhance the event matching process. The goal here is to achieve the minimum time latency consumed by the matching process. Achieving this means rapid streaming of geospatial notifications to interested clients, thereby improving situational awareness in time-sensitive situations. This section describes, in detail, an efficient matching approach. The matching problem can be formulated as follows. Let’s assume a geospatial event egeo is published throughout the publish/subscribe system. A set of subscriptions Sub1 , Sub2 , . . ., Subn have been previously registered, where each Subi defines a filter on geospatial events that are of interest. The matching process determines a subset of subscriptions, where each Subi in the subset matches the geospatial event egeo . According to the geospatial subscription model discussed in Section 3.1.2, each Subi comprises two boolean functions, SPi and APi (i.e., Subi [SPi , APi ]), of a spatial constraint and an attribute constraint, respectively. Both functions take egeo as an input, evaluate it according to the assigned conditions, and generate a boolean value as an output. The Subi is considered to match egeo if the output boolean values from both functions are true, i.e., Subi [true, true]. Otherwise they do not match, i.e., Subi [true, false], Subi [false, true], or Subi [false, false]. In cases where the key word “NULL” is assigned to any one of the subscription’s functions; the output of the associated function is considered true; without evaluating egeo . Matching a geospatial event with a single geospatial subscription seems quite simple. However, the matching process becomes more complicated and expensive as potentially thousands or even millions of geospatial subscriptions are involved in the matching process. The naïve solution of the matching process, known as the brute force method, is to store all the subscriptions in one table inside the middleware component and to conduct the matching procedure on a one-by-one basis, i.e., evaluating the published geospatial notification against one subscription at a time. However, it is evidently inefficient and is a time consuming process when the number of registered subscriptions increases. Our proposed approach for matching published geospatial events with registered geospatial subscriptions is performed in two phases: a pre-processing phase and a matching phase. The following explains each phase in more detail. The spatial predicate assigned in a geospatial subscription is considered the primary constraint. A geospatial subscription contains a base geometry, a spatial operator, and optionally a buffer value (see Section 3.1.2). The spatial operator and the buffer value parameters vary from one subscription to another. In the preprocessing phase, we attempt to transform the subscriptions set into homogenous groups of subscriptions, where all geospatial subscriptions within each group have a similar spatial operator and a zero buffer value (i.e., no further buffering is required on the base geometry). The geospatial subscriptions are then clustered

into feature classes according to their assigned spatial operators. For instance, all geospatial subscriptions assigned the Contain spatial operator are clustered into a single feature class, where all geospatial subscriptions assigned the Overlap spatial operator are clustered in another feature class, and so on. As the geospatial subscription language supports six types of spatial operators (see Section 3.1.2), the output from the clustering process described above will have at most six feature classes of geospatial subscriptions. In each feature class, the base geometry of each geospatial subscription is later buffered according to the buffer value assigned. Note that the buffering process can be skipped if the buffer value is originally assigned zero. The final step of the pre-processing phase is to structure the subscriptions’ feature classes into spatial indexes. Each feature class is assigned one index by which the geospatial subscription features can be accessed and retrieved. At this stage, geospatial subscriptions are pre-processed into homogeneous feature classes and structured into spatial indexes. In the matching phase, as soon as a geospatial event egeo reaches the notification service, the matching engine uses the prepared spatial indexes of registered geospatial subscriptions and executes the matching process. The process takes the geometry (i.e., the spatial component) of the geospatial event and uses it as a spatial query to retrieve the matched set of geospatial subscriptions from the stored feature classes. Note here that the roles of the geospatial event and geospatial subscriptions are reversed. Instead of taking geospatial events as spatial data and geospatial subscriptions as spatial queries, we consider geospatial subscriptions as spatial data and geospatial events as the basis for executing spatial queries. As there are potentially six subscriptions’ feature classes, a maximum of six spatial queries are executed. The formulations of these queries are as the following: • (the geometry of ng ) Within (the geometries of Contain feature class). • (the geometry of ng ) Contains (the geometries of Within feature class). • (the geometry of ng ) Disjoint (the geometries of Disjoint feature class). • (the geometry of ng ) Crosses (the geometries of Cross feature class). • (the geometry of ng ) Touches (the geometries of Touch feature class). • (the geometry of ng ) Overlaps (the geometries of Overlap feature class). Note that in the first two feature classes, namely Contain and Within, the spatial operators Within and Contains are used respectively as the spatial relationship is reversed by using the geospatial event egeo as a query. For the remaining four feature classes, Disjoint, Cross, Touch, and Overlap, similar spatial relationships are used in their respective queries as the function criteria does not change with a reversing of the base geometry and the comparison geometry. The geospatial subscription features selected by executing the above spatial queries are considered candidate matches to the geospatial event egeo . Lastly, as geospatial subscriptions may also encapsulate attribute predicates (see Section 3.1.2), the spatially matched subscriptions sets obtained from the above process are evaluated with the content-attributes of the geospatial event egeo . Those subscriptions that pass through the attribute evaluation process fully match the geospatial subscription. 4. Development of a Real-Time Fire Emergency Response System prototype This section presents a Real-time Fire Emergency Response System (RFERS) prototype developed from this work, which has

A. Kassab et al. / International Journal of Applied Earth Observation and Geoinformation 12 (2010) 431–438

435

Fig. 2. Overall architecture of RFERS.

implemented the proposed geospatial-based publish/subscribe interaction framework. RFERS targets transacting four types of spatio-temporal geospatial events, called topics, designed to be employed within the context of fire incidents and emergencies, including: GPS location of emergency field assets (e.g., fire trucks and police cars), temperature and humidity observations of wireless sensors, 911 reports of urban fire incidents, and thermalinfrared airborne imageries of active wildfire. Potential users of RFERS may include first responders, officers, fire chiefs, managers, responsible agencies and even public users as those parties are interested in being notified about certain occurrences of geospatial events in real-time. The next sub-sections describe the development of the RFERS prototype in more detail. 4.1. System architecture The overall architecture of RFERS, shown in Fig. 2, is divided into three tiers: the client tier, the business logic tier (also called application server), and the database tier. Publishers and subscribers fall inside the client tier. They interact with the middleware tier, particularly through the notification service, by sending and receiving messages (i.e., geospatial events/notifications). The notification service component resides in the business logic tier, where most of the application processing work occurs. The business logic tier, from one side, communicates with the client tier by handling all the incoming publications and subscriptions and consequently sending out notification messages. From the other side, the processes running inside the business logic tier are permitted to access the database tier for data storing and retrieving. A portion of the business logic functions resides in the users’ applications in the client tier for the purpose of processing and visualizing the message data. APIs and TCP/IP protocols facilitate the underlying communication among the tiers. Moreover, subscriber clients are granted access to various GIS layers through a mapping service. They can utilize

the mapping service to overlay the received geospatial events and potentially conduct further modeling and geoprocessing analysis. As mentioned earlier, four geospatial event topics are designed in RFERS: Emergency Asset Locations, Wireless Sensor Observations, Fire Incident Reports, and Wildfire Thermal-Infrared Images. The data model of each topic is predefined as a set of name/value pairs. Those topics then are considered as built-in standards that are recognized by the notification service unit. The RFERS clients should implement those topics’ data models and follow their structures in order to successfully compile their issued operations. Otherwise, those operations will be discarded and not processed by the notification service. In the Emergency Asset Location topic, publishers (e.g., emergency vehicles mounted by GPS devices) broadcast geospatial events that represent their current positions in the geographic space. Subscribers can subscribe to this topic if they are interested in receiving information about certain positions of publishers. For instance, a commander requests to be notified of any emergency vehicles within a distance of 1000 m of the incident location, or the speed of certain vehicles exceeding 80 km/h. For the Wireless Sensor Observation topic, we assume the deployed wireless sensor devices publish temperature and relative humidity observations through the RFERS framework. Clients subscribe to this topic in order to be notified about critical readings (e.g., high temperature and low humidity conditions) potentially observed in the field. The Fire Incident Reports topic allows clients to publish addresses or locations of fire incidents occurrences. Civilians or public users can contribute to this publishing process. On the other hand, responsible parties (e.g., emergency call operators, dispatchers, and officers) can subscribe to this topic to receive instantly published fire incident reports. They can also register their interest in those reports that are located within a certain region. Finally in the Wildfire Thermal-Infrared Images topic, the remote sensing images captured by airborne sensors at the scene of an active wildfire can

436

A. Kassab et al. / International Journal of Applied Earth Observation and Geoinformation 12 (2010) 431–438

Fig. 3. Average matching time of a single geospatial event using the proposed matching approach.

be published to notify subscribers about the status of the hazard. The geospatial events in this topic usually encapsulate temporal images of the wildfire acquired over a period of time. The georeferencing data can be attached to those geospatial events, allowing subscribers to directly map and visualize the images once published. 4.2. Prototype implementation The notification service component (see Fig. 2) is implemented using C# and ArcGIS Engine v9.3 .NET SDK. In addition, Enterprise TIBCO Messaging Service (EMS) v4.4 API is used for receiving published geospatial events as well as for dispatching them to matched subscribers’ applications. The RFERS database is created using ArcSDE v9.3 and SQL Server 2005. Feature classes are prepared in the RFERS database to store the geometry features of the geospatial subscriptions that are issued by subscribers. The multilevel grid spatial index, a maximum of three grid levels, is utilized to index geospatial subscriptions. The GIS map service component (see Fig. 2) hosts a map service that can be consumed by subscribers’ applications to view a base map for Canada. The map service is created using ArcGIS Server v9.3. The implementation of clients’ applications is independent of system behavior. In other words, the clients can utilize any software platform or application to communicate with the notification service and be part of the system interaction. However, clients’ applications have to implement the APIs provided by the notification service in order to perform publish/subscribe operations. In the RFERS prototype implementation, a desktop GIS application for use by subscriber clients has been implemented. Simulation programs have been developed to act as publishers of geospatial events. Those applications are developed for the purposes of this work to demonstrate the interaction mechanism and to evaluate the underlying geospatial-based publish/subscribe model.

Intel Core 2 Duo E6320 CPU and 2GB RAM also running Windows XP is employed to run the GIS subscriber application and publisher simulation programs. For simulating geospatial subscriptions, the FSA 6-digits postal code boundaries (i.e., polygon features) for Alberta, Canada are used to represent the base geometries of registered geospatial subscriptions. All of the geospatial subscriptions are assigned a spatial filter with a polygon base geometry (the created postal code geometries), Contain spatial operator, and zero buffer value. The spatial indexing technique used in structuring the geospatial subscriptions is the Multi-Grid indexing technique. Using the simulation program, around 1000 geospatial events are published (100 events per second) and the matching time is measured for each event. Fig. 3 shows the relation between the average matching time and the number of registered geospatial subscriptions. As can be seen from the graph, the average matching time for a single event is measured against several sets geospatial subscriptions, which contain 100,000–1,000,000 features. The proposed matching approach takes about 4 ms to match one geospatial notification with 100,000 subscriptions. While matching 100 geospatial notifications with 1,000,000 subscriptions requires around 135 ms. The relation, shown in the graph, between the number of subscriptions and the matching time follows a logarithmic curve. The increasing ratio of the number of subscriptions is getting larger than the increasing ratio of the matching time, which means, the performance is improved in proportion to the larger number of subscriptions. We believe this relation results from the effect of spatial indexing in structuring the subscriptions, which leads to better performance in the matching process. In summary, our experiments have shown that the matching engine implemented in the RFERS prototype will be capable of matching 100 geospatial notifications against 1,000,000 geospatial subscriptions in almost 14 s. 6. Related work

5. Performance evaluation The matching time, which is the processing time that the matching engine takes to find matched subscriptions upon publishing geospatial events, is an important measure for evaluating the performance of the implemented RFERS prototype. Achieving high matching speed means quick awareness of dynamic geospatial events that are potentially crucial to accelerating the decisionmaking and response actions in emergency situations. In this section, the matching time is measured to demonstrate how the performance of the matching engine changes with respect to the number of registered geospatial subscriptions. A server workstation with 2.4 GHz Intel Core 2 Quad-Q6600 CPU and 4GB RAM running Windows XP is used to deploy the RFERS middleware and the database, and a local computer with 1.86 GHz

SIENA (Carzaniga et al., 2001; Carzaniga, 1998), HERMES (Pietzuch, 2004) and JEDI (Cugola et al., 2001) are some of the major research prototypes utilized in developing large-scale distributed event-based systems. These pioneers have served in conducting a substantial theoretical background for the purpose of this research work. In terms of applicability, however, those systems support primitive data types of events (mainly descriptive/textual attributes), while our research tackles the ability of accommodating geospatial types of events and notifications. Handling geospatial events in the publish/subscribe interaction raises the need to deal with spatial types of interests or subscriptions; this is also not well addressed in the previous publish/subscribe prototypes. In Bauer and Rothermel (2002), specifications and definitions of the subscription language for handling spatial semantics of events

A. Kassab et al. / International Journal of Applied Earth Observation and Geoinformation 12 (2010) 431–438

in location-aware applications were proposed. This work was more focused on defining an event and an event composition within the context of spatial locations. Also in Romer and Mattern (2004), an event-based approach for detecting certain states of real world phenomena via Wireless Sensor Networks (WSN) was examined. Temporal as well as spatial constraints were realized in the subscription language. Both works, however, were more focused on defining events, events composition, and subscription predicates, within the context of their applications. Also, there was no study about the mechanism by which spatial events are matched with subscriptions. In Chen et al. (2003a), the authors investigated the issue of accommodating spatially related events and subscriptions in the context of Location Based Services (LBS) applications. The spatial subscription model was designed to accommodate spatial predicates and allow subscribers to express their spatial interests in events. However, the subscription language only supported two types of spatial predicates: Within and Distance. The same work was extended to propose the CAMEL project (Chen et al., 2003b), aiming to develop a spatial publish/subscribe system for LBS. The system utilizes a predefined and well-known set of zones, rectangles and circles, limiting the subscribers in registering their spatial predicates. In our work, the subscription language accommodates a wider range of spatial constraints (e.g., Disjoint and Overlap), which increases the expressiveness in defining fine-grained interests. In Burcea and Jacobsen (2003), the authors proposed LToPSS (Location-aware Toronto Publish/Subscribe System), a publish/subscribe system for LBS applications. Publisher and subscribers were addressed in L-ToPSS as being either stationary (i.e., fixed location) or mobile users (i.e., location is changing over time). The central publish/subscribe server in L-ToPSS is responsible for matching the spatial locations of publishers with previously registered subscriptions and then notifying the subscribers about publishers who are within a certain distance. Events and subscriptions were represented by points in the geographic space, and distance was the only relationship for relating the publications with the subscriptions. The matching engine of L-ToPSS uses the counting-based algorithm for spatial matching processing. This procedure can be considered efficient enough for L-ToPSS, as the matching process is limited by testing only the spatial distances constraints. However, accommodating a wider range of spatial data types (i.e., points, lines and polygons) as well as other spatial relationships, needs a more effective matching procedure. 7. Conclusions and future work In this work, we have proposed Geospatial-based Publish/Subscribe, an interaction framework based on the publish/subscribe protocol to transact dynamic geospatial events in order to support timely decision making and increased situational awareness in fire emergencies. Disparate sources of dynamic geospatial information, on the one side, and a large number of clients with heterogeneous and fine-grained interests in data, on the other side, can be integrated in an asynchronous and real-time manner. The proposed geospatial event and geospatial subscription data models can be utilized to represent a wide range of events and interests, respectively. An efficient matching approach for disseminating published geospatial events to interested subscribers has been presented. The evaluation results clearly demonstrate the efficiency of the matching procedure. The interaction framework has been realized in the development of a RFERS. The system prototype has been designed to integrate four types (i.e., topics) of geospatial events that are crucial for fire emergency response, including: emergency asset locations,

437

fire incident addresses, metrological observations of wireless sensors, and remote sensing images of active wildfires. Our future work includes extending the RFERS prototype to develop an enterprise service capable of integrating numerous clients distributed over large-area of networks. Investigations to apply the geospatial-based publish/subscribe interaction to support emergency management of crisis situations such as earthquakes, floods, tsunamis, tornados and other natural hazards should also be conducted.

Acknowledgements This research is financially supported by the Canadian ‘Geomatics for Informed Decisions’ (GEOIDE) network and Natural Sciences and Engineering Research Council of Canada (NSERC).

References Bauer, M., Rothermel, K., 2002. Towards the observation of spatial events in distributed location-aware systems. In: Proceedings of the 22nd International Conference on Distributed Computing Systems, pp. 581–582. Burcea, I., Jacobsen, H.-A., 2003. L-ToPSS – push-oriented location-based services. In: Proceedings of the 2003 Workshop on Technologies for E-Services, pp. 131– 142. Carzaniga, A., 1998. Architectures for an event notification service scalable to wide-area networks. In: Computer Science. University of Colorado, Milano. Carzaniga, A., Rosenblum, D., wolf, A., 2001. Design and evaluation of a widearea event notification service. ACM Transactions on Computer Systems 19 (3), 332–383. Chen, X., Chen, Y., Rao, F., 2003a. An efficient spatial publish/subscribe system for intelligent location-based services. In: Proceedings of the 2nd International Workshop on Distributed Event-based Systems, pp. 1–6. Chen, Y., Rao, F., Yu, X., et al., 2003b. CAMEL: a moving object database approach for intelligent location aware services. In: Proceedings of the 4th International Conference on Mobile Data Management, pp. 331–334. Cugola, G., Nitto, E.D., Fuggetta, A., 2001. The JEDI event-based infrastructure and its application to the development of the OPSS WFMS. IEEE Transactions on Software Engineering 27 (9), 827–850. ESRI, GIS for Fire Station Locations and Response Protocols, White Paper, Redlands, CA, 2007. Eugster, P.T., Felber, P.A., Guerraoui, R., et al., 2003. The many faces of publish/subscribe. ACM Computing Surveys (CSUR) 35 (2), 114–131. Franzosa, R.D., Egenhofer, M.J., 1993. Topological spatial relations based on components and dimensions of set intersections. Proceedings of SPIE, Vision Geometry Journal 1832 (1), 236–246. Keramitsoglou, I., Kiranoudis, C.T., Sarimveis, H., et al., 2004. A multidisciplinary decision support system for forest fire crisis management. Environmental Management 33 (2), 212–225. Mansouri-Samani, M., Sloman, M., 1997. GEM: a generalized event monitoring language for distributed systems. IEE/IOP/BCS Distributed Systems Engineering Journal 4, 96–108. Muhl, G., Fiege, L., Pietzuch, P., 2006. Distributed Event-based Systems. Germany, Springer. Pietzuch, P.R., 2004. Hermes: A Scalable Event-based Middleware. Queens’ College, University of Cambridge, Cambridge, United Kingdom. Romer, K., Mattern, F., 2004. Event-based systems for detecting real-world states with sensor networks: a critical analysis. In: International Conference on Intelligent Sensors, Sensor Networks and Information Processing (ISSNIP’04), Melbourne, Australia, pp. 389–395. Schneider, M., Behr, T., 2006. Topological relationships between complex spatial objects. ACM Transactions on Database Systems (TODS) 31 (1), 39–81. Wybo, J.-L., 1998. FMIS: a decision support system for forest fire prevention and fighting. IEEE Transactions on Engineering Management 45 (2), 127–131. Ala’ Kassab is a graduate student and research assistant in the Department of Geomatics Engineering at the University of Calgary, Canada. Ala’ holds a B.Sc. degree in Surveying and Geomatics Engineering from Al-Balqa Applied University, Jordan. He worked as a GIS specialist and software trainer. He gained practical experience by working closely with private industries and government sectors in conducting local and national GIS projects. Currently, Ala’ is perusing a M.Sc. degree in Geomatics Engineering at the University of Calgary. His research focuses on the integration of Geospatial Information technology with the modern Event-based and Publish/Subscribe interaction paradigm.

438

A. Kassab et al. / International Journal of Applied Earth Observation and Geoinformation 12 (2010) 431–438

Steve Liang is an assistant professor in Geographical Information Systems at Department of Geomatics Engineering, Schulich School of Engineering, University of Calgary. His general research areas are Geospatial Information and Communication Technologies (GeoICT). Currently, his specific research interests lie at the intersection of GeoSensor Networks, Peer-to-Peer (p2p) computing, Internet GIS and Social Networks, specifically in the area of the Spatial Sensor Web (SSW), which is a spatial information infrastructure for heterogeneous sensor networks.

Yang Gao’s research is centered around the theoretical aspects and innovative applications of satellite-based positioning and navigation systems such GPS. Dr. Gao has been involved in a number of research projects in both governmental and industrial sectors and his research has contributed to the development of several new positioning and navigation systems including commercial products that have been sold world wide. He is the recipient of several academic awards including two US Institute of Navigation best paper awards and a Canadian Institute of Geomatics Intermap award. Prior to joining UofC, Dr. Gao has spent two years as a post-doctoral fellow at the Geodetic Survey of Canada and three years in the industrial sector as a research scientist and R&D manager.