This article appeared in a journal published by Elsevier. The attached copy is furnished to the author for internal non-commercial research and

Transcription

1 This article appeared in a journal published by Elsevier. The attached copy is furnished to the author for internal non-commercial research and education use, including for instruction at the authors institution and sharing with colleagues. Other uses, including reproduction and distribution, or selling or licensing copies, or posting to personal, institutional or third party websites are prohibited. In most cases authors are permitted to post their version of the article (e.g. in Word or Tex form) to their personal website or institutional repository. Authors requiring further information regarding Elsevier s archiving and manuscript policies are encouraged to visit:

2 ISPRS Journal of Photogrammetry and Remote Sensing 64 (2009) Contents lists available at ScienceDirect ISPRS Journal of Photogrammetry and Remote Sensing journal homepage: A flexible geospatial sensor observation service for diverse sensor data based on Web service Nengcheng Chen a,b, Liping Di a,, Genong Yu a, Min Min a a Center for Spatial Information Science and Systems, George Mason University, 6301 Ivy Lane, Suite 620, Greenbelt, MD 20770, USA b State Key Lab for Information Engineering in Surveying, Mapping and Remote Sensing (LIESMARS), Wuhan University, 129 Luoyu Road, Wuhan , China a r t i c l e i n f o a b s t r a c t Article history: Received 26 July 2007 Received in revised form 22 October 2008 Accepted 8 December 2008 Available online 20 January 2009 Keywords: Sensor Web SOS CSW MySQL EO-1 Achieving a flexible and efficient geospatial Sensor Observation Service (SOS) is difficult, given the diversity of sensor networks, the heterogeneity of sensor data storage, and the differing requirements of users. This paper describes development of a service-oriented multi-purpose SOS framework. The goal is to create a single method of access to the data by integrating the sensor observation service with other Open Geospatial Consortium (OGC) services Catalogue Service for the Web (CSW), Transactional Web Feature Service (WFS-T) and Transactional Web Coverage Service (WCS-T). The framework includes an extensible sensor data adapter, an OGC-compliant geospatial SOS, a geospatial catalogue service, a WFS- T, and a WCS-T for the SOS, and a geospatial sensor client. The extensible sensor data adapter finds, stores, and manages sensor data from live sensors, sensor models, and simulation systems. Abstract factory design patterns are used during design and implementation. A sensor observation service compatible with the SWE is designed, following the OGC core and transaction specifications. It is implemented using Java servlet technology. It can be easily deployed in any Java servlet container and automatically exposed for discovery using Web Service Description Language (WSDL). Interaction sequences between a Sensor Web data consumer and an SOS, between a producer and an SOS, and between an SOS and a CSW are described in detail. The framework has been successfully demonstrated in application scenarios for EO-1 observations, weather observations, and water height gauge observations. Published by Elsevier B.V. on behalf of International Society for Photogrammetry and Remote Sensing, Inc. (ISPRS). 1. Introduction A sensor network is a computer-accessible network of spatially distributed sensors that monitor conditions such as temperature, sound, vibration, pressure, motion, or pollutants at different locations. Measurements made from sensor systems, whether in-situ sensors (e.g., water monitoring) or dynamic sensors (e.g., satellite imaging), contribute most of the volume of the geospatial data used in geospatial systems today. The term Sensor Web was first proposed by the National Aeronautics and Space Administration (NASA) Sensor Web Applied Research Planning Group. In 2001, NASA provided the following definition (Delin and Jackson, 2001): a Sensor Web is a system of intra-communicating spatially distributed sensor pods that can be deployed to monitor and explore new environments. NASA s direction for 2005 and beyond (NASA, 2005) stated, NASA will develop new space-based technology to monitor the major interactions of the land, oceans, atmosphere, ice, and life that comprise the Earth system. In the Corresponding author. Tel.: ; fax: addresses: cnc_dhy@hotmail.com (N. Chen), ldi@gmu.edu (L. Di). years ahead, NASA s fleet will evolve into human-made constellations of smart satellites that can be reconfigured based on the changing needs of science and technology. From there, researchers envision an intelligent and integrated observation network comprised of sensors deployed to vantage points from the Earth s subsurface to deep space. This sensor web will provide timely, on-demand data and analysis to users who can enable practical benefits for scientific research, national policymaking, economic growth, natural hazard mitigation, and the exploration of other planets in this solar system and beyond. In 2005, the Geospatial Information and Communication (GeoICT) Lab (Liang et al., 2005) in Canada broadened the above scope by including a wide range of sensors and applications in the definition of the Sensor Web, which they defined as an electronic skin of the Earth, offering full dimensional, full-scale, and full-phase sensing and monitoring at all levels, global, regional, and local. Di (2007), the director of Center for Spatial Information Science and Systems (CSISS) at George Mason University (GMU) has defined the Geospatial Sensor Web as the Sensor Web that performs Earth observations (EO) and envisioned that major new EO sensors in the future will be Web-ready. Lee and Reichardt (2005) discuss the three approaches for Sensor Network construction that of the Institute of Electrical /$ see front matter. Published by Elsevier B.V. on behalf of International Society for Photogrammetry and Remote Sensing, Inc. (ISPRS). doi: /j.isprsjprs

3 N. Chen et al. / ISPRS Journal of Photogrammetry and Remote Sensing 64 (2009) and Electronics Engineers (IEEE), the National Institute of Standards and Technology (NIST), and the Open Geospatial Consortium (OGC). The IEEE 1451 Smart Transducer Interface Standards, OGC s SWE program and NIST s Network Sensor Standards have been used for Homeland Security (HLS) sensor networks. OGC and the International Organization for Standardization (ISO) have been developing standards and protocols for the geospatial sensor web. The SWE program initiatives (Simonis, 2005; Botts, 2006; Cox, 2006) have developed three information models and four service implementation specifications. NASA has tested the EO-1 Sensor Web (Ip et al., 2006) as an OGC project, mainly to verify whether the SWE standard could be used for data from sensors on earth observation satellites. OGC s specifications for web services, geospatial portals, spatial data infrastructures, and sensor webs provide implementation specifications and architecture for the Global Earth Observing System of Systems (GEOSS). They have been put forward by Percivall (2006). The Sensor Observation Service (SOS) (Na and Priest, 2006) is one of the four service implementation specifications. OGC defines SOS as a service that provides standard Application Programming Interfaces (APIs) for managing deployed sensors and retrieving sensor data. It has three mandatory core operations GetCapabilities, DescribeSensor and GetObservation, two optional transactional operations RegisterSensor and InsertObservation, and six optional enhanced operations GetResult, GetFeature- OfInterest, GetFeatureOfInterestTime, DescribeFeatureOfInterest, DescribeObservationType, and DescribeResultModel. The three mandatory core operations are used to help consumer discover and retrieve sensor and observations, the two optional transactional operations are used to help provider register sensor and observations, the six optional enhanced operations are used to improve the quality of sensor and observations retrieval. Many SOS prototypes have been developed in the worldwide Sensor Web community described in Section 2. However, the existing systems have many problems: (1) Current SOS systems cannot support a unified sensor model for geospatial sensors, which are heterogeneous. Observations can be made from satellites, aircraft, boats, and land. Once a sensor model has changed, the relevant SOS must be modified, repackaged, and redeployed. (2) Currently implemented SOS systems cannot meet the heterogeneous requirements for storing and managing data observed by sensors. Geospatial sensor data may be stored in a flat file, a relational database, an object database, or an XML database. Once a data storage model has been changed, the relevant SOS must be redesigned and re-implemented. (3) Existing SOS systems are implemented as a Servlet or a PHP program. Service-oriented architectures that are more flexible, in particular the emerging Web Service Architecture, cannot currently meet the diverse requirements of the Catalogue Service Web Profile (CSW), Web Feature Service (WFS), Web Coverage Service (WCS), and Multi-Protocol Geospatial Client (MPGC) clients. More specifically, existing SOS systems cannot meet the large number of individual user requirements. This paper deals with the above issues. It explains how to use Service Oriented Architecture (SOA) and Java 2 Enterprise Edition (J2EE) Web service technology to design and implement a multipurpose Sensor Observation Service. Related work is summarized in Section 2. Design considerations, architecture, and the main components of the system are described in Section 3. The detailed implementation information for the multi-purpose SOS is discussed in Section 4. In Section 5, the framework is adopted for three typical use cases, to demonstrate the feasibility of the proposed method. Section 6 summarizes findings and discusses what steps are needed next. 2. Related work There have been many SOS implementations. The current 52 North SOS 1 release implements a core profile. It consists of three mandatory operations and an optional GetFeatureOfInterest operation. The SOS of 52 North is implemented as a servlet and can be deployed in any servlet container, for example, Tomcat 5.5. Sensor observation data can be stored in the PostgreSQL database. Some template files are provided for users to create customized SQL query tables with new data and metadata. On the client side, the OX-Framework (abbreviation for OWS Access Framework) provides an architecture that is sufficiently flexible and extendable to allow access to SWE SOS and subsequent visualization of the queried data. It is connected to the SOS by a service-connector component, SOS-Connector. The 52 North SOS implementation is applied to a broad range of areas, ranging from forest fire fighting to water pollution monitoring, for example, the AFIS (Advanced Fire Information System) project of the Council for Scientific and Industrial Research (CSIR) in South Africa. GeoBliki 2 emerged as a fusion of many web technologies. To keep the cost of entry extremely low and avoid proprietary implementations that would have increased the barriers to entry, the GeoBliki team chose an open source approach. Ruby-on-Rails was chosen in GeoBliki SOS development for its quick prototyping speed, its Model-View-Controller approach, its MySQL support, and its built-in testing framework. The three mandatory core operations GetCapabilities, DescribeSensor, and GetObservation for SOS were implemented. A typical application of GeoBliki SOS is the Earth Observing-1 (EO-1) Sensor Web project. The EO-1 mission has now shifted its emphasis from hardware to software. EO-1 Sensor Web experiments include the Autonomous Sciencecraft Onboard Experiment, Onboard Cloud Cover Detection and Prediction, and Automated Detection of Volcanoes and Fires with Collaborating Space Ground Assets. The final goal is to experiment with an evolving ground spacebased software architecture to enable Sensor Webs and eventually to develop full Autonomous Mission Operations Systems. EO- 1 Hyperion data after T15:19:39.000Z can be served through EO-1 SOS. 3 The VisAnalysis Systems Technologies 4 Team (VAST) performs applied research and development on scientific visualization and analysis, as well as on standard web-based technologies. It is part of the Earth System Science Center at the University of Alabama in Huntsville (UAH), located within the National Space Science and Technology Center (NSSTC). On the client side, the Space Time Toolkit (STT) supports parsing and executing of SensorML processing chains and SOS. The STT allows display of measurements or derived quantities as an interactive 4D visual display. The following five types of SOS are implemented in VAST: Satellite Orbital Elements SOS, Satellite Nadir Track SOS, Satellite Sensor Footprints SOS, Airdas unmanned aerial vehicle (UAV) SOS and Weather Station SOS. The Deegree 5 SOS has been designed and implemented to support the OGC SOS specification version 0.9.0, to connect to PostGIS, Oracle Spatial, or any database management system supporting JDBC and to support the GetCapabilities, DescribeSensor, DescribePlatform and GetObservation operations. Deegree SOS 1 N52 North SOS: task=showproject&id=4&itemid=127. (Accessed July 21, 2008). 2 GeoBliki: (Accessed July 21, 2008). 3 EO-1 SOS demonstration: (Accessed July 21, 2008). 4 VAST: (Accessed July 21, 2008). 5 Deegree: (Accessed July 21, 2008).

4 236 N. Chen et al. / ISPRS Journal of Photogrammetry and Remote Sensing 64 (2009) Table 1 The SOS implementation comparison. Feature Type 52 North GeoBliki VAST Deegree Functions GetCapabilities GetObservation DescribeSensor GetFeatureOfInterest InsertObservation RegisterSensor GetResult GetFeatureOfInterestTime DescribeFeatureOfInterest DescribeObservationType DescribeResultModel DataBase PostgreSQL MySQL NONE MySQL Program language Java Perl Java Java Service Servlet PHP Servlet Servlet User interface Html Ajax Html Html DCP request GET/POST POST GET/POST GET Sensor type In-situ Remote Remote In-situ Client OX-Framework STT igeoportal Typical application AFIS EO-1 Weather station Supported; Unsupported. is highly configurable so that existing relational databases can be connected. On the client side, igeoportal is the web-based portal framework and offers visualization of geodata through a standard web browser. Table 1 shows that, while, as of October 22, 2008, almost all SOS have implemented all the mandatory operations, RegisterSensor and InsertObservation transaction operations have not yet been implemented. Both in-situ and remote sensors are supported. Sensor data storage and management in the SOS is either flattened file or sole Relational Database Management System (RDBMS). The Distributed Computing Platform (DCP) request is just HTTP Get or Post protocol. In short, the existing SOS cannot meet the requirements of the diverse sensor networks, heterogeneous sensor data storage, and different users. 3. Design 3.1. Considerations One of the critical components of a system enabled for the Sensor Web is an infrastructure that can serve Observation and Measurement (O&M) data provided by a sensor observation service. The system must be interoperable with Sensor Planning Service, OGC CSW, WCS, and WFS. The system must be sufficiently flexible to meet the requirements of diverse sensors. The goal of the system being developed is to provide middleware components to manage and retrieve sensor observation data. The design of the system must use a loosely coupled architecture, in order to satisfy the requirements of diverse sensors and multiple users Service oriented architecture A service-oriented architecture (SOA) is used to design, develop, and deploy the multi-purpose SOS. Every function in the SOS is a service and can perform a well-defined set of operations. Services can be registered, discovered, and accessed by different clients using a uniform protocol. The system can be invoked and integrated with others through the open interfaces and standard protocols Diverse sensors Geospatial sensor Web data can be either feature or coverage data. Remote sensors, such as satellites, UAV, Laser Imaging Detection and Ranging (LIDAR), and Aerial Digital Sensors (ADS), can be used to produce images of terrestrial phenomena. Observations encoded by coverage type can be served by WCS (Evans, 2003; Lee et al., 2005) or WCS-T servers. Spatially distributed in-situ sensors are commonly used to monitor conditions at different locations. Some of these conditions are temperature, sound intensity, vibration, pressure, motion, and pollutants, these observations can be encoded as a feature type and served by WFS (Vretanos, 2002) or WFS-T servers dynamically. The RegisterSensor interface in the transactional profile of SOS enables the sensor registry Heterogeneous database A uniform data adapter interface of different relational database management system (RDBMS) can be used to store and manage spatiotemporal data. Current SOS implementations adopt different RDBMS. Development of a flexible framework to feed multiple O&M data sources into a heterogeneous data management system is a major challenge. The InsertObservation interface in the transactional profile of SOS enables storage and management of sensor observation data Architecture To satisfy the above goals, service-oriented middleware architecture has been adopted for the O&M data service for the geospatial Sensor Web. As shown in Fig. 1, the architecture contains the following three layers: the presentation layer, the business layer and the data layer. The presentation layer consists of components with which users can access, view, and manipulate geospatial sensor data. A Multiple Protocol Sensor Client (MPSC) makes a request to a CSW service, gets SOS instances, binds the request to a specified SOS, obtains the O&M data from a SOS, and gets the coverage or feature data from a WCS-T or a WFS-T. It includes a sensor map and some method for interacting with the sensor map through CSW, WFS-T, or WCS-T. A business layer consists of multiple adapters, one multiplepurpose SOS, and a uniform WSDL service description. The adapters find and retrieve the Sensor Web data from the data layer described in the next paragraph. The multi-purpose SOS is the core business logic. From the viewpoint of a sensor data consumer, it

5 N. Chen et al. / ISPRS Journal of Photogrammetry and Remote Sensing 64 (2009) Fig. 1. Service-oriented architecture of a flexible SOS. Fig. 2. Interaction diagram of SOS with other components. implements the OGC-compliant Sensor Observation Service operations: GetObservation, GetCapabilities, and DescribeSensor. From the viewpoint of a sensor data publisher, it implements the optional transactional operations, RegisterSensor and InsertObservation, for inserting new sensors and sensor observations into an SOS. The WSDL description is used to expose the service, bindings, port types and operations of a specified SOS, so that the service can be invoked by different clients. A data layer provides the data source for the business layer. The data layer stores and manages live sensor data. The sensor data source can be a live remote sensor, an in-situ sensor, a tiny wireless sensor, an operational SOS, a dynamic spatio-temporal database, or a simulation system. The O&M data can be stored through the business layer in a flattened file, an RDBMS, or an XML database. The WCS-T for an SOS transaction operation allows a MPSC client to complete requests that a WCS server import one or more new coverages from SOS and update or delete existing coverages. The WFS-T for an SOS transaction operation also allows a MPSC client to fulfill requests for a WFS server to import one or more new layers from SOS and update or delete existing layers. Both operations refer (externally and internally) to the data to be inserted or updated in the WCS server, and the server must resolve these references, fetch data, and store data for future access Interaction Fig. 2 is the interaction diagram. It shows that, in the method implemented, an SOS communicates with CSW, the consumer, the publisher, and other SOSs Interactions between a sensor data consumer and a SOS A Sensor Web data consumer discovers SOS instances from a CSW catalogue using the GetRecords operation. The consumer then obtains the service-level for each service instance by requesting the capabilities document and inspecting the observation offerings. The consumer invokes the DescribeSensor operation to retrieve detailed sensor metadata for those sensors advertised in the observation offerings of the identified SOS instances. This metadata is in SensorML or TML. The consumer selects an appropriate SOS and binds the SOS server to perform GetObservation operation. Finally, the consumer calls the GetObservation operation to actually retrieve the observations and serves the O&M data as a coverage or a feature to the consumer using a WCS-T or WFS-T server Interactions between a Sensor Web data publisher and a SOS Fig. 2 shows how a producer of Sensor Web data interacts with an SOS instance that supports the transactional profile. The producer invokes the GetRecords operation on a CSW catalog to discover an SOS. When the producer determines that the SOS is communicating with a new sensor, the catalog service invokes the RegisterSensor operation and registers the new sensor with the SOS. The producer invokes the InsertObservation operation and publishes sensor observations from all sensors of the SOS. The SOS instance then invokes the appropriate adapter and updates the corresponding database Interactions between a SOS and a CSW Fig. 2 also shows how a SOS instance interacts with a CSW (Chen et al., 2005; Nebert and Whiteside, 2005; Voges and Senkler, 2005; Wei et al., 2005) instance that supports the ebrim profile. In a catalog registry, an SOS service information model is registered as a ServiceType, SOS capability content is registered as an OfferingType, and SOS observation metadata can be registered as either a WCSCoverage or a WFSLayer data granule. The capability content and data granule can later be discovered by a CSW GetRecords operation.

6 238 N. Chen et al. / ISPRS Journal of Photogrammetry and Remote Sensing 64 (2009) Implementation 4.1. Adapter for multiple sensors Fig. 3 shows that the SOS service can access zero or more SOS resources. Each SOS resource may be represented by an entity like a service, a relational database, or an XML database. A sensor data adapter can be instantiated dynamically and used to access the different sources of sensor data. The SOS service and its sensor data adapter will reside on the same server. A SOS resource has an associated set of configuration files. These files specify the activities it supports, the session information, and the class name of its data resource adapter. The SOS data adapter is designed and implemented using the Abstract Factory design pattern. The Abstract Factory pattern is intended to provide an interface for creating families of related or dependent objects without specifying their concrete classes (Gamma et al., 1995). Fig. 4 shows that an Abstract Factory class SOSDBFactory provides interfaces for creating a number of data adapter instances (MySQLDB and existdb). The system would have any number of derived concrete versions of the data base creator class like MySQLFactory or existfactory, each with a different implementation of createdb that would create a corresponding object like MySQLDB or existdb. Each of these data adapters is derived from a simple abstract class like SOSDB of which Fig. 3. Adapter for multiple sensor data sources. the client is aware. The client code would get an appropriate instantiation of the SOSDBFactory and call its factory methods. The resulting objects would all be created from the same createdb implementation and would share a common theme. The client would need to know how to handle only the abstract SOSDB class, not the specific version that it got from the concrete factory. The interface design and implementation of this SOS is based on a Sensor Observation Service specification (Na and Priest, 2006), that defines the formal HTTP protocol binding interfaces and operations a SOS should support. The specification also provides the request, response, and exception messages for each operation. Fig. 5(a) shows that service discovery, observation discovery, sensor metadata retrieval, sensor observation retrieval, sensor registration, and publication of observations are designed and implemented as eleven Java interfaces in the SOSDB abstract class: IInsertObservation, IGetCapabilities, IGetFeatureInterest- ByTime, IDescribeObservationType, IDescribeSensor, IGetResult, IGetObservation, IGetObservationById, IRegisterSensor, IDescribe- FeatureOfInterest, and IGetFeatureOfInterest. Fig. 5(b) and (c) show that MySQLAccessor and existaccessor are concrete implementations. Moreover, users can customize their implementations of the above eleven interfaces to support other databases. Fig. 5(b) shows a MySQL adapter implemented using Java classes. MySQL is a multithreaded, multi-user SQL database management system (DBMS) (Schumacher and Lentz, 2008). MySQL supports spatial extensions that allow the generation, storage, and analysis of geographic features. The set of geometry types proposed for MySQL is based on the OpenGIS Simple Geometry Model. Here, implementation of SOS interfaces that update and retrieve sensor data is discussed, for example, MySQLRegisterSensor, MySQLInsertObservation and MySQL GetObservation, using the geometry column to store the O&M data from a data layer. The MySQLAccessor class and the MySQLConfig class are used to create a MySQL adapter instance. The MySQLConnectionPool class creates and manages a connection to the MySQL database. Fig. 5(c) shows how an exist adapter is implemented using Java classes. The exist database.. (Meier, 2003) is an open Fig. 4. Abstract factory implementation of SOS data base adaptor.

7 N. Chen et al. / ISPRS Journal of Photogrammetry and Remote Sensing 64 (2009) (a) The common interface of SOS. (b) The MySQL implementation. (c) The exist implementation. Fig. 5. MySQL and exist adapter implementation. source native XML database featuring efficient, index-based XQuery processing, automatic indexing, extensions for full-text search, XUpdate support, XQuery update extensions, and tight integration with existing XML development tools. The exist database provides a powerful environment in which XQuery and related standards can be used to develop web applications. Web applications can be written entirely in XQuery, using XSLT, XHTML, CSS, and possibly JavaScript (for AJAX functionality). XQuery server pages can be executed from the file system or stored in the database. The system extends exist to allow the generation and storage of Point type geometry. SOS interfaces (for example, existregistersensor, existinsertobservation, and existgetobservation) are implemented for updating and retrieving the O&M sensor data from a data layer. Users can implement the proposed factory and interface to support different databases. For example, if the objective is to extend a data adapter to register a sensor, to insert observations and to get observations from the PostGreSQL database. a PostGreSQLFactory and PostGreSQLDB class must be written. The concrete PostGreSQLFactory class is used to create an instance of PostGreSQLDB and the PostGreSQLDB class is used to implement the proposed eleven common interfaces of the SOSDB abstract class Uniform invocation using WSDL for SOS The schema of a SOS GetCapabilities operation contains a GetCapabilities element used for requests and a Capabilities element used for responses. A capabilities response consists of five main elements: ServiceIdentification, ServiceProvider, Operations Metadata, Filter_capabilities, and Contents. The Contents element contains one or more ObservationOffering elements containing data and functions that the SOS server provides: intendedapplication, eventtime, procedure, observedproperty, featureofinterest, resultformat, resultmodel, and responsemode elements. The observedproperty element is the observables/phenomena that can be requested in this offering. The responsemode element allows the client to request the form of the response. The schema of a SOS DescribeSensor operation contains a DescribeSensor element used for requests and a Sensor element used for responses. The response of the SOS DescribeSensor operation contains identification, referenceframe, inputs, and outputs elements. The schema of a SOS GetObservation operation contains a GetObservation element used for requests and an Observation element used for responses. The response of the SOS GetObservation operation contains service and version attributes and the ObservationOffering element, also offering and result elements. In general, the EO dataset is described in the result element. The schema of a SOS RegisterSensor operation contains a RegisterSensor element used for requests and a RegisterSensorResponse element used for responses. This operation is designed to register new sensors at the SOS. The response of the SOS RegisterSensor operation contains the InsertId element. This ID is used to link the sensor to an observationtype. The schema of a SOS InsertObservation operation contains an InsertObservation element used for requests and an InsertObservationResponse element used for responses. This operation is designed to insert new observations. The request contains the ID obtained by the registersensor operation and the observation encoded as O&M specification. The response of the SOS InsertObservation operation is successful or failed. Web Service Description Language (WSDL) provides a model and an XML format for describing services. WSDL allows separation of the description of the abstract functionality offered by a service from the concrete details of a service description, for example, how and where that functionality is offered. In general, a WSDL instance is divided into four parts: Operations, PortTypes, Bindings, and Services. Fig. 6 shows the components of the SOS WSDL: three kinds of porttypes (HTTP Get, Post and SOAP), three mandatory operations (GetCapabilities, DescribeSensor, and GetObservation), two optional transaction operations (RegisterSensor and InsertObservation), three kinds of bindings (SOS_HTTP_POST_ Binding, SOS_HTTP_GET_Binding and SOS_SOAP_Binding) and EO1_SOS, Weather_SOS and Camera_SOS Service components. Fig. 7 shows how input and output parameters are defined as messages in WSDL using SOS schema. For example, the input message of the GetCapabilities operation is the GetCapabilitiesInput defined as the sos:getcapabilities element and the output message is the GetcapabilitiesResponse defined as the sos:capabilities element. A publisher can use the pre-defined parameters to invoke the RegisterSensor and InsertObservation operations described in the WSDL of SOS to register a sensor and update the O&M information. A consumer can use the pre-defined parameters to invoke the DescribeSensor and GetCapabilities operations described in the SOS WSDL to obtain the sensor and SOS

8 Author's personal copy 240 N. Chen et al. / ISPRS Journal of Photogrammetry and Remote Sensing 64 (2009) Fig. 6. The uniform WSDL of multiple purpose SOS. Fig. 7. The message of multiple purpose SOS WSDL. service information, and then use this information to invoke the GetObservation operation to get O&M sensor data. In short, both publisher and consumer can talk directly to the SOS WSDL and transparently invoke the SOS operations. 5. Case studies This section illustrates the application of the multiple-purpose Sensor Observation Service to retrieval and management of EO1 Hyperion observation data, IFGI water measurement data, and NSSTC weather station observation data, demonstrating the advantages of using the Web service technology proposed in this paper SOS transaction operations for diverse sensor experiments SOS has two transaction operations: RegisterSensor and InsertObservation. The three set of data have been used to test the feasibility of uniform transaction operations for diverse sensors in the proposed SOS. The EO-1 spacecraft carries three instruments, of these three, two are still operating: the Advanced Land Imager (ALI) and Hyperion. ALI acquires data in 10 spectral bands that cover a wavelength range from the visible to short wave infrared with resolution similar to Landsat 7 satellites. Hyperion acquires data in nm-wide bands from 0.4 to 2.6 µm.

9 N. Chen et al. / ISPRS Journal of Photogrammetry and Remote Sensing 64 (2009) Fig. 8. Sample of EO-1 Hyperion observation data. Fig. 9. Sample of gauge height observation data. Fig. 8 shows Hyperion observation data generated from EO- 1 SOS and the content of O&M data records inserted into the multi-purpose SOS through the InsertObservation operation. The URL of the detailed EO-1 data product can be given in the result element, for example EO1H PY T17:02:18Z.tar.gz link attribute. Fig. 9 shows water observation data generated and inserted into the multi-purpose SOS using an InsertObservation operation. A water observation consists of time of measurement, location of the instrument, water level, accuracy of attribute (quantattributeaccuracy), and completeness of measurement (completenessomission). The time is between T10:15:00-05 and T10:15: The observation has six records. For the T10:15:00-05, id_1001, 50.0, 1, 10 record, the time of measurement is T10:15:00-05, the id of a referenced Point object is id_1001, the water level is 50.0 cm, the quantattributeaccuracy is 1, and completenessomission is 10. The multi-purpose SOS can be used to register NSSTC weather sensors, inserting weather observations into SOS using the InsertObservation operation. Fig. 10 shows how the NSSTC weather station observation data can be encoded in an O&M specification and inserted into SOS through the proposed flexible Sensor Observation Service. Consider a weather observation between T04:00:0001:00 and T04:00:4001:00. The observation has five items, separated by commas. For the T04:00:0001:0, 35.0, , 20.4, record, the time of measurement is T04:00:0001:00, the air temperature is 35.0 C, the atmospheric pressure is mbar, the wind speed is 20.4 km/h, and the wind direction is deg Experiment on Sensor Web data storage in different databases The Sensor Web data contains information about the sensor encoded in SensorML and observational data encoded using the O&M specification. The following illustrations show how PostgreSQLAdapter, MySQLAdapter, and existadapter are used to store water observation data and demonstrate the feasibility of heterogeneous database storage and management support in the multi-purpose SOS. Observed data can be stored in a PostgreSQL database through the PostgreSQLAdapter and queried by SQL Query. A SQL query for select time_stamp, procedure_id, feature_of_interest_id, offering_id, and numeric_value from an observation, where the feature_of_interest_id= id_1001 yields the six records (see Fig. 9) in Fig. 10. Sample of weather observation data. the result set. The id_1001 is linked to a Point geometry object encoded using the PostgreSQL spatial type-point. The results can be encoded in an O&M specification and served using a GetObservation operation implemented in the multi-purpose SOS. The observed data can be stored in a MySQL database through the MySQLAdapter and served as data encoded in the O&M specification through the proposed MySQL adapter in the flexible Sensor Observation Service. The items of the SOSDB table are observation_id, time, offering_id, feature_id, and numeric_value. Execution of a select observation_id, time, offering_id, feature_id, offering_id, numeric_value from sosdb SQL query yields the six records (see Fig. 9) in the result set. The id_1001 is linked to a Point geometry object encoded in MySQL spatial type-point. The results can be encoded in the O&M specification and served by a GetObservation operation implemented in the multi-purpose SOS. The observed data can be stored in the exist XML database through the exist adapter and queried by XML XPath or XQuery. The XPath expression /ObservationCollection/Observation/result/ [time> T10:15 :00-05 ] can be used to obtain time, feature ID, and gauge height with the results encoded in the O&M specification and served by a GetObservation operation implemented in the multi-purpose SOS.

10 242 N. Chen et al. / ISPRS Journal of Photogrammetry and Remote Sensing 64 (2009) Discussion Tests of the RegisterSensor and InsertObservation operations in the multi-purpose SOS using the EO-1 SOS, the IFGI water sensor, and the NSSTC weather sensor show that the SOS transaction operations are suitable for diverse sensors. The operations can register other sensors in SOS and insert other observational data. Use of the PostgreSQL, MySQL and exist databases to test the feasibility of the sensor adapter for heterogeneous databases shows that the adapter can be extended to retrieve, store, and manage Sensor Web data using other databases. Acknowledgements This work was supported by grants from the U. S. NASA ESTO/AIST Sensor Web program: General Framework and System Prototype for the Self-Adaptive Earth Predictive Systems (SEPS) Dynamically Coupling Sensor Web with Earth System Models (No. NNX06AG04G, PI: Dr. Liping Di), 863 program (No. 2007AA12Z230, PI: Dr. Nengcheng Chen) and NSFC program (No , PI: Dr. Nengcheng Chen). We also sincerely thank our colleague, Dr. Barry Schlesinger, for proofreading the manuscript. The authors would like to thank the anonymous reviewers for their valuable comments and insightful ideas. 6. Conclusions and outlook To develop a Geospatial Sensor Observation Service that can harmonize diverse sensor networks, support heterogeneous sensor data storage and meet the individual requirements of different users is a great challenge. This paper proposes a service-oriented framework to integrate and assimilate sensor observations and measurements under a multi-purpose SOS in combination with other standard services CSW, the WFS-T and the WCS-T. The proposed method was successfully tested using three typical sensor observation data sets. The approach overcomes many problems, discussed in Section 2, that plague existing Sensor Observation Service implementations. The new approach has the following improvements over the existing SOS implementation: (1) A flexible architecture. The strategy adopts service-oriented architecture to package the multi-purpose Sensor Observation Service to discover and retrieve diverse sensor and observations in business layer. This SOS service can be independently deployed with service middleware and can communicate with CSW, the consumer, the publisher, and other SOSs through standard interfaces. (2) Uniform transaction interfaces for diverse sensor data providers. The strategy adopts the RegisterSensor and InsertObservation standard interfaces to implement the SOS transactional operation and exposes the service transactional operations to register sensor and observations in WSDL. The service can be invoked by different sensor data providers to publish their observation data flexibly. (3) An extensible access framework for heterogeneous databases. The extensible sensor data adapter for flattened files, RDBMS and the XML database is responsible for discovery, storage, and management of the data from live sensors, sensor models, and simulation systems. It is designed and implemented using Abstract Factory design patterns. Users can support different databases through the common interfaces. (4) Uniform access to interfaces for individual observation data consumers. The strategy adopts the standard GetCapabilities, DescribeSensor and GetObservation interfaces to implement the SOS basic operation and exposes the service basic operation to retrieve sensor and observations in WSDL. The service to obtain observation data can be invoked on-demand by different consumers of sensor observation data. (5) Sensor Web data can be published, stored, and served ondemand through the multiple-purpose Sensor Observation Service. The next step is to study how to use Geo-Processing Workflow (GPW) technology to provide self-adaptive geospatial data service by harmonizing SOS, SPS, WCS-T, WFS-T and Web Processing Service (WPS). References Botts M. (Ed.) OpenGIS r sensor model language implementation specification (Version 1.0). In: Open Geospatial Consortium, OGC, Document Number: r2, Wayland, MA, USA, 117p. Chen, A., Di, L., Wei, Y., Liu, Y., Bai, Y., Hu, C., Mehrotra, P., Grid enabled geospatial catalogue web services. In: Proc. American Society for Photogrammetry and Remote Sensing, ASPRS, Annual Conference, Baltimore, USA, 7 11 March, 10p. Cox S. (Ed.) OGC TM Observation and measurement (Version ). In: Open Geospatial Consortium, OGC, Document Number: r3, Wayland, MA, USA, 136p. Di, L., Geospatial sensor web and self-adaptive earth predictive systems, SEPS. (accessed ). Delin, K., Jackson, S., The Sensor Web: A new instrument concept. In: Proc. the International Society for Optical Engineering (SPIE) s Symposium on Integrated Optics, San Jose, CA, USA, January, 9p. Evans, J.D., OGC TM Web coverage service specification (Version 1.0.0). In: Open Geospatial Consortium, OGC, Document Number: r6, Wayland, MA, USA, 67p. Gamma, E., Helm, R., Johnson, R., Vlissides, J., Design Patterns. Addison- Wesley, Reading, MA, 395p. Ip, F., Dohm, JM., Baker, VR., Doggett, T., Davies, AG., Castano, R., Chien, S., Cichy, B., Greeley, R., Sherwood, R., Tran, D., Rabideau, G., Flood detection and monitoring with the Autonomous Sciencecraft Experiment onboard EO-1. Remote Sensing of Environment 101 (4), Lee, E., Kim, M., Kim, M., Joo, I., A web services framework for integrated Geospatial coverage data. Lecture Notes in Computer Science 3481, Lee, K.B., Reichardt, M.E., Open standards for homeland security sensor networks Sensor interconnection and integration through Web access. Institute of Electrical and Electronics Engineers (IEEE) Instrumentation and Measurement Magazine 8 (5), Liang, SHL., Croitoru, A., Tao, CV., A distributed geospatial infrastructure for Sensor Web. Computer and Geoscience 31 (2), Meier, W., exist: An open source native XML database. Lecture Notes in Computer Science 2593, Na A., Priest M. (Eds.) OpenGIS r sensor observation service implementation specification (Version 0.1.5). In: Open Geospatial Consortium, OGC, Document Number: r1, Wayland, MA, USA, 187p. NASA, The new age of exploration, NASA s direction for 2005 and beyond. (accessed ). Nebert D., Whiteside A. (Eds.) OGC TM catalogue services specification (Version 2.0.0). In: Open Geospatial Consortium, OGC, Document Number: r3, Wayland, MA, USA, 187p. Percivall, G., OpenGIS international standards for GEOSS interoperability arrangements. In: Proceedings of Institute of Electrical and Electronics Engineers, IEEE, International Geoscience and Remote Sensing Symposium, IGARSS, 2006, Denver, USA, 31 July 04 August. 4p. Schumacher, R., Lentz, A., Dispelling the Myths., MySQL AB. com/tech-resources/articles/dispelling-the-myths.html (accessed ). Simonis I. (Ed.) OpenGIS r sensor planning service implementation specification (Version ). In: Open Geospatial Consortium, OGC, Document Number: r1, Wayland, MA, USA, 152p. Voges U., Senkler K. (Eds.) OpenGIS r catalogue services specification 2.0 ISO19115/ISO19119 application profile for CSW 2.0 (Version 0.9.3). OGC Document Number: r2, Wayland, MA, USA, 89p. Vretanos P.A. (Ed.) OGC TM web feature service implementation specification (Version 1.0.0). In: Open Geospatial Consortium (OGC) Document Number: , Wayland, MA, USA, 105p. Wei, Y., Di, L., Zhao, B., Liao, G., Chen, A., Bai, Y., Liu, Y., The design and implementation of a grid-enabled catalogue service. In: Proc. Proceedings of Institute of Electrical and Electronics Engineers (IEEE) International Geoscience and Remote Sensing Symposium (IGARSS) 2005, Seoul, Korea, July, 4p.