AN ARCHITECTURE FOR AUTOMATED FIRE DETECTION EARLY WARNING SYSTEM BASED ON GEOPROCESSING SERVICE COMPOSITION

Rapidly discovering, sharing, integrating and applying geospatial information are key issues in the domain of emergency response and disaster management. Due to the distributed nature of data and processing resources in disaster management, utilizing a Service Oriented Architecture (SOA) to take advantages of workflow of services provides an efficient, flexible and reliable implementations to encounter different hazardous situation. The implementation specification of the Web Processing Service (WPS) has guided geospatial data processing in a Service Oriented Architecture (SOA) platform to become a widely accepted solution for processing remotely sensed data on the web. This paper presents an architecture design based on OGC web services for automated workflow for acquisition, processing remotely sensed data, detecting fire and sending notifications to the authorities. A basic architecture and its building blocks for an automated fire detection early warning system are represented using web-based processing of remote sensing imageries utilizing MODIS data. A composition of WPS processes is proposed as a WPS service to extract fire events from MODIS data. Subsequently, the paper highlights the role of WPS as a middleware interface in the domain of geospatial web service technology that can be used to invoke a large variety of geoprocessing operations and chaining of other web services as an engine of composition. The applicability of proposed architecture by a real world fire event detection and notification use case is evaluated. A GeoPortal client with open-source software was developed to manage data, metadata, processes, and authorities. Investigating feasibility and benefits of proposed framework shows that this framework can be used for wide area of geospatial applications specially disaster management and environmental monitoring. * Corresponding author.


INTRODUCTION
Rapidly discovering, sharing, integrating and applying geospatial information are key issues in the domain of emergency response and disaster management.Using standardized web services according to the OGC specifications, a seamless integration is feasible for a wide variety of applications.The implementation specification of the Web Processing Service (WPS) is a standard to process spatial data on the web, defined by the Open Geospatial Consortium (OGC).This standard provides online geoprocessing systems such as spatial computations (e.g.coordinate transformations, orthorectification), thematic computations (e.g.geoparsing, geocoding), temporal computations (e.g.change detection, temporal proximity) and metadata computations (e.g.statistical calculation, geographic annotation) (Lopez-Pellicer, F.J et al. 2012).Composition of WPS services can be used to enable distributed processing of geospatial information, especially remote-sensing observations.This standard focuses on providing geospatial processing interfaces to wrap other existing and planned OGC services (Schut, P., 2007).Several authors have addressed the use of service chaining in many specific geospatial applications to represent value added services.Alameh identified service chain as one of the key concepts in enabling enhanced chains in SDIs (Alameh. N., 2003).She introduced three different architecture design to chain geospatial web services.Weiser and Zipf, evaluated the suitability of the Web Service Orchestration (WSO) technology as potential solution for a part of an evacuation scenario after a bomb has been found (Weiser, A., Zipf, A., 2007).They use BPEL as an orchestration engine for creating geoprocessing workflows.Stollberg and Zipf illustrated the usage of WPS for chaining of OGC web services as an alternative for BPEL (Stollberg, B., Zipf, A., 2007).Friis-Christensen et al. demonstrated feasibility of using services as a basis for distributed service oriented geoprocessing to provide users with a distributed application that enables the assessment of fire damaged areas, based on land coverage data in a given area (Friis-Christensen, A., et al. 2009).He discussed different data and control flow patterns in a workflow of geospatial web services.Chen et al. presented a common GPW framework for Sensor Web data service as part of the NASA Sensor Web project (Chen, N., et al. 2010).Inside the GENESIS project, Smolders et al. have adopted the Open Geospatial Consortium (OGC) Web Processing Standard as the Web Service interface specification for various distributed processing applications (Smolders, S., et al. 2011).V. Rautenbacha et al. evaluated existing WPS frameworks for orchestration of web services to prepare, discover and present information, instead of data, to the user (Rautenbacha, V. et al., 2012b).This author implemented an intelligent geoportal to orchestrate geoprocessing web services produce thematic maps (Rautenbacha, V. et al., 2012a).

FIRE DETECTION
The fire detection algorithm is based on the Enhanced Contextual Fire Detection Algorithm for MODIS that was introduced by Giglio L., et al. (Giglio L., et al. 2003).The detection algorithm uses several bands of MODIS data to extract the fire events.A workflow of distributed processes are used for hot pixel detection using MODIS data to implement the feasibility of the proposed architecture (Figure 1).In this workflow by retrieving MODIS data with radiance number value, brightness temperatures are derived from the 4 and 11 µm channels, denoted by T 4 and T 11 (Justice, C.O, et al. 2002).After calculating brightness temperature from satellite imageries, the fire detection rules were utilized to find hot pixels.The 250-m near-infrared band (0.86 µm), denoted by 2 , is used to realize highly reflective surfaces to find false alarms.Several steps are considered to find and extract fire events.These steps are configured as the following (Giglio L., et al. 2003):  To avoid false detection, pixels with one of the following conditions are immediately eliminated as possible fires:

(daytime only)
 A pixel is classified as a fire pixel by utilizing combination of following tests (the background window for computing statistics is identified by finding sufficient number of water and cloud pixels): ( A pixel is classified as a fire pixel if: 4) are true and [ test (5) or test ( 6) is true ] }, otherwise it is classified as non-fire.The result of this workflow is a binary image in that pixels with value 1 are detected as fire pixels.Finally a raster to vector process is used to convert hot pixels to point features.

GEOPROCESSING SERVICE CHAINING
It is a common approach to make workflows of elementary geoprocessing operations to create more complex processes in order to achieve specific geospatial analysis.Geoprocessing workflow can be seen as "an automation of a spatial process/model, in whole or part, during which information is passed from one distributed Geoprocessing Service to another according to a set of procedural rules using standardized interfaces" (Schaeffer B., 2009.).The usage of available data and processing resources on a flexible infrastructure as a composite service is one of the benefits of service oriented architecture that provides a higher level of functionalities and applications.With the implementation specification of the WPS, it is possible to integrate different geoprocessing services in an individual WPS service and expose it as a single web service.This standard is a generic interface without any restriction on supporting any specific process (Schut, P., 2007).A WPS process can be designed to call a sequence of web services including other WPS processes, thus acting as a service chaining engine (Schut, P., 2007).In this paper our major aim is on the developing and aggregating WPS processes.The standard interface of WPS mainly focused on the implementation of geo-processing computations and didn't mention any orchestration functionality.Two different approaches are possible to chain geoprocesses using a WPS interface (Stollberg, B., Zipf, A., 2007).In a centralized approach a WPS can serve as an orchestration service for activating other services.The central service is responsible for invoking the web services in a specified sequences and provide the inputs and receive the outputs as an orchestration engine (Figure 2).On the other hand, the second option of chaining WPS processes is a nested request encoding.The standard interface of WPS adopts executing request of another WPS service or data retrieve request of WFS or WCS web services as an input of process in a cascaded pattern.In this approach the last process which provides the final output of the entire processes, is invoked first of all.This process call the other process and this pattern is followed by nested geoprocesses.When the first output is provided the sequence is followed in a reverse pattern to provide the main result of the chain of processes (Figure 3).In this paper, for processing and detecting fire events, a centralized WPS service in an opaque pattern was designed.This service invokes several data access and processing services as a single and aggregated service to detect hot pixel points.In this aggregated pattern, several outputs are provided by the composite WPS service that enable us to achieve the result of each process in the workflow beside the final output features.

ARCHITECTURE AND BUILDING BLOCKS
The overall architecture of proposed system as depicted in Figure 4, is based on standardized service interfaces.A service oriented architecture has been implemented for detection and alerting fire hazards.As a framework for this application, we consider a generic architecture, which consists of several components.These components are divided into layers according to the types of functionality they provide.The whole components and layers are configured in the architecture as an enterprise GeoPortal application.
GeoPortal Central Module as a major component in the architecture acquire data from external data sources.This component handles the interactions between different layers to store the data and its metadata and initiates the workflow to detect and publish the fire events.Vector and raster data sources can be accessed through standard Web Feature Service (WFS) and Web Coverage Service (WCS) web services.To enable data processing, the standard interface of WPS has been used.This service integrates different web services and sends the result of the process chain to the authorities via a Web Notification Service (WNS).The architecture is responsible to form a mechanism to dynamically feed and use remote sensing data in GeoProcessing Workflows.When some data were injected to system, GeoPortal Central Module initiates the designated procedures.First of all data and its metadata should be inserted to the standard web services WCS and CSW.When the injected data is available to be fetched from the services, a composite WPS (Figure 5) is invoked from the GeoPortal Central Module to execute the predefined processes.All of the designed and implemented processes are chained in a main fire detection processing service.This service is responsible to invoke each process and service in a sequence.In this sequence, first the desired region, for example country boundary, for extracting fire events is clipped from MODIS data, bands 21 and 31.These data are provided for calculating brightness temperature by Brightness Temperature process deployed in the WPS service.A pre-process of removing false alarms is executed by another process service to avoiding recognizing these as hot pixels.The false alarm removed product beside the water and cloud product is represent for the rules that recognize fire events.A binary product would be provided by this process.Finally a raster to vector process is considered in the workflow to extract point feature from the raster product of fire rules (Figure 6).

EXPERIMENTS AND RESULT
For the implementation of described system, an open source web service software and java technology have been used.To implement the required processes and chain these processes in a workflow, 52 north WPS server was utilized.This server provide a mature platform to provide several geoprocesses on the web in a standardized way.52 north WPS server software supports many geospatial data types especially raster formats to process satellite imageries.It is possible to execute long time running processes by supporting both synchronous and asynchronous communication patterns.Each processing service in the composite WPS is responsible to retrieve data from data access services in a cascaded request design.Processes with long running time is executed by asynchronous method that is provided by the 52 north WPS server.The final result is represented for GeoPortal Central Module to manage the storing, visualizing and notifying the derived alerts.Liferay portal as an enterprise web platform is used for delivering the representation layer.This portal is configured as an enterprise GeoPortal to represent user interfaces to interact with various web services.As depicted in Figure 7, it is possible to search metadata and request for desired data stored in the database by the proposed GeoPortal.Different query conditions are considered in the search area to enable creating fully customized queries by users and archive or retrieve the specific data and visualize it.Visualization of detected fires from the processed imageries is the other role of this GeoPortal.After execution of the process chain by composite WPS, existence of any fire points is checked and a transaction to WFS is called to store the points.Finally GeoPortal retrieve the result of processes to visualize the events to the user on the map (Figure 8).A standard WNS web service is used to notify alarm to the authorities who can either confirm, reject, or set the alarm as expired.Different notification and communication ways are provided by this web service such as E-Mail or SMS.
Figure 8. Visualization and alert confirmation section of fire event from MODIS imageries

CONCLUSION
With the implementation specification of OGC Web Processing Service, a widely applicable interface is available to provide the geoprocessing functionalities on the web.Our goal was to evaluate the feasibility of using this standard in a real world fire hazard alerting system.This paper proposed a high level architecture for detection and notifying fire events using OGC web services.This architecture consists of individual layers to enable the automation of whole procedure to extract and notify fire events.As a framework for this application, we consider a generic architecture, which consists of several components.These components are divided into layers according to the types of functionality they provide.For the implementation of described system open source web service software and java technology have been used to process the MODIS imageries in a workflow and represent results.To achieve the interoperability issue, OGC standard interfaces are utilized for storing, processing and representing remote-sensing data.WPS plays the main role in this framework and supports satellite imagery processing in each step of the scenario and chains these processing services as a composition engine.This standard provides mechanisms to retrieve geospatial data in a desired data type, initiate the process, and manage the output from the process.The workflow exposed as an opaque composite WPS service.All of the designed and implemented processes are chained in a main fire detection processing service.Interactions and sequence of processing services are managed in the composite WPS.Interoperability, flexibility and reusability are the main privileges of this framework.It is possible to extend and reuse the components of this architecture in the wide area of geospatial applications.In the future work we plan to implement the workflow by a workflow language to extend the functionalities of composite service.There are some weakness in the opaque design patterns that make some restrictions to user of the service.Using of chaining engines improve the dynamicity and automation of composition of services.In addition, we aim to enable the composite service to search in the catalogue service and make it possible to discover the desired data, metadata, or process.

Figure 1 .
Figure 1.Sequences of fire detection processes

Figure 4 .
Figure 4. Architecture of fire detection early warning system

Figure 5 .
Figure 5. Sequence diagram of proposed architecture

Figure 6 .
Figure 6.Workflow of services for fire detection