Integration of hydrological observations into a Spatial Data Infrastructure under a Sensor Web environment

Abstract

Various sensors connected to the World Wide Web are used to obtain real-time hydrological observations. Thus, real-time management and utilization of such distributed in situ observations in the cyber-physical environment becomes possible. A Sensor Observation Service (SOS) chaining Web Feature Service (WFS) method is proposed to integrate geographical reference observation data collected by a hydrological Sensor Web into a virtual globe. This method hides the complexity of a series of information and service models in the Sensor Web realm to enable the integration of heterogeneous distributed hydrological data sources into a Spatial Data Infrastructure (SDI). The core components – a dynamic schema transformer and automatic information extractor – were designed and implemented. The SOS schema is matched to WFS schema that uses the schema transformer dynamically. The information extractor extracts and serves features automatically, conforming to standard SOS operations for observation retrieval and insertion. Feasibility experiments conducted on the Jinsha River tested this proposed method. Results show that the proposed approach allows the integration of SOS servers into legacy applications that have a higher degree of availability within many SDIs. However, this is accompanied with the drawback that only a limited part of the SOS functionality is available to clients.

Keywords:

• Sensor Web
• data management
• service middleware
• Sensor Observation Service
• Web Feature Service

1. Introduction

Hydrological monitoring is a critical process in water conservancy (Chow, Maidment, and Mays 1988). Different types of human activity, such as water, environmental, and disaster risk management, require continuous spatial and temporal hydrological data collection. The development of sensor and sensor network technologies have changed the way users obtain hydrological information. All kinds of hydrological observation data are now collected using various in situ sensors, sensor networks, wireless sensor networks, and Sensor Web environments.

A ‘Digital Earth’ is a ‘multiresolution, three-dimensional (3D) representation of the planet into which we can embed vast quantities of geo-referenced data’ (Gore 1998). Many aspects of this vision have been realized and some significant progress has been achieved, such as the China Digital Earth Prototype System (EPS/CAS) (Guo, Fan, and Wang 2009), Spatial Data Infrastructures (SDIs) (Craglia et al. 2008), open geospatial web service discovery (Chen et al. 2011), Sensor Web Enablement (SWE) (Longueville et al. 2010), and virtual globe (Butler 2006). The SWE specifications provide the functionality to integrate sensors into SDI. This integration provides a feasible way to link real-time sensor data with Geoinformation Systems (GISs). In some cases, the Sensor Observation Service (SOS) is already included in National Spatial Data Infrastructures (NSDIs) specifications, such as the Germany Spatial Data Infrastructure (GDI-DE 2012), but in most countries, the SOS is not yet included in NSDI architecture definitions. In a parallel development, there has been much work in directly representing the SOS on virtual globes, such as the Geospatial Cyber infrastructure for Environmental Sensing (GeoCENS) browser. GeoCENS is a Sensor Web 3D browser based on the open source World Wind virtual globe system (Liang et al. 2010). Most virtual globes, however, still cannot support the SOS in the Observation and Measurement (O&M), which is part of the suite of SWE standards. Therefore, the mechanisms to dynamically integrate real-time hydrological observation data into NSDI in cyber-physical space and representing these data on a virtual globe using Geography Markup Language (GML) through the World Wide Web is a huge challenge.

To address this challenge, this work comes up with an approach of a real-time feature service method using an SOS chaining Web Feature Service (WFS) middleware that integrates in situ observations into legacy applications. In situ observation data are served by SOS in SWE O&M in a Sensor Web environment and integrated via transactional WFS as features in the GML. This study focuses on three aspects: a standardized WFS proxy for an SOS, which dynamically integrates hydrological observation data using the GML feature; methods to use the rich visualization functions in a virtual globe to represent hydrological observation data; and a proposed SOS chaining WFS method for the Jinsha River hydrological monitoring system.

The paper contains the following sections: Section 2 introduces previous related work, including the current status of OGC web service, Sensor Web service, registry, and discover technology. Section 3 describes the framework of the prototype system, including system architecture, components, and the realization of those components. A case study of the Jinsha River is detailed in Section 4. Experimental results and discussions are presented in Section 5. Finally, the conclusions of this paper are elaborated and future work discussed.

2. Background

2.1. Relevant OGC specifications

The OGC has developed a set of web-based interoperability protocols for data access and services, such as Web Map Services (WMSs) (Beaujardiere 2007), WFS (Vretanos 2005), and Web Coverage Services (WCSs) (Whiteside and Evans 2008). The WMS defines web interfaces for accessing raster map data. The WCS defines web interfaces for accessing online multidimensional, multitemporal geospatial data in an interoperable way. Coverage data include gridded geospatial data and remote sensing images. The WFS defines web interfaces for accessing feature-based geospatial data. The International Organization for Standardization (ISO) general feature model GML represents feature information (Portele 2007).

The Sensor Web is a group of interoperable web services that comply with a specific set of sensor behaviors, data models, encodings formats, and interface specifications. The Sensor Web enables discovery, access, tasking, and alerting the anonymous and heterogeneous sensors distributed all over the world through the Internet. According to OGC, ‘a Sensor Web refers to web accessible sensor networks and archived sensor data that can be discovered and accessed using standard protocols and application program interfaces (Botts et al. 2008).’ The SWE initiative of the OGC defines information models and service interfaces to build such a Sensor Web.

The current SWE framework consists of the following elements: the SWE common data model (Robin 2011), O&M (Cox 2007a, 2007b), Sensor Model Language (SensorML) (Botts 2007), and Event Pattern Markup Language (EML) (Everding and Echterhoff 2008). The SWE common data model defines common and basic data types used throughout the SWE framework. The O&M standard defines a domain independent, conceptual model for the representation of spatiotemporal O&M data. The SensorML defines standard models and XML schema for describing sensor metadata and related processes. The EML is used to define event patterns as processing rules for complex event processing (CEP) and event stream processing (ESP). In the latest SWE framework (Bröring, Echterhoff et al. 2011), the service implementation specifications include SWE service model (Echterhoff 2011), Sensor Planning Service (SPS) (Simonis and Echterhoff 2011), SOS (Bröring, Stasch, and Echterhoff 2012), Sensor Event Service (SES) (Echterhoff and Everding 2008), Sensor Instance Registry (SIR) (Jirka and Nüst 2010), and Sensor Observable Registry (SOR) (Jirka and Broering 2009). The SPS defines interfaces for queries that provide information about the capabilities of a sensor and can be used for tasking the sensors. The SOS provides an API for managing deployed sensors and retrieving sensor data, more specifically ‘observation’ data. In the SOS 2.0 Interface Standard, the temporal and spatial filters are increased. SOS 2.0 can also handle the query options described above. The SES provides operations to register sensors at the service application and let clients subscribe to observations available from the service, which provides filtering and processing functionality. The SIR and SOR enable a discovery mechanism for sensor-related resources. The SIR provides a web service interface for automatically harvesting, transforming, and managing the sensor metadata as well as the SOR for managing the definitions of the phenomena measured by sensors. When these components work together, it is possible to use web services to discover; access; and control sensors, sensor networks, and wireless sensor networks.

The goal of the Sensor Web is to enable all types of sensor resources that are discoverable, accessible, and useable via the Web. To integrate sensors into the Sensor Web, the open source initiative 52°North provides the Sensor Bus, which establishes an intermediary layer between sensor resources and the Sensor Web (Bröring, Foerster et al. 2010). The Sensor Interface Descriptor (SID) (Bröring and Below 2010) is used to describe the sensor protocol (Bröring, Bache et al. 2011). Through a combination of the SID concept, the Sensor Bus, and an inclusion of a semantic mediation framework, 52°North realizes Sensor Plug & Play (Bröring, Maue et al. 2011).

With the development of the OGC, an increasing number of international organizations have begun using these standards for hydrological applications. For example, the Consortium of Universities for the Advancement of Hydrologic Science (CUAHSI) provides hydrological data over the Web using the OGC geospatial standards like WMS for map representation, WFS for delivery of geographic feature information, and SOS for data delivery (Bermudez and Arctur 2011). Additionally, the SWE has permitted great progress in diverse applications such as risk monitoring and disaster management (Jirka, Bröring, and Stasch 2009a); fire detection (Chen, Di, Yu et al. 2010); snow, ice, water, land, and cloud classification (Chen, Li et al. 2010); and atmospheric chemistry composition feed services (Chen, Di, Gong et al. 2010). Guru et al. (2008) also proposed a hydrological Sensor Web for forecasting short-term river flow.

2.2. Registry and discovery mechanism

At present, for the geospatial domain, the metadata of data-sets and services is constructed and accessed by an OGC Catalogue Service for the Web (CSW) (Nebert, Whiteside, and Vretanos 2007). The OGC CSW is implemented with two profiles: the ISO Metadata Application Profile (Voges and Senkler 2007) and the Electronic Business using eXtensible Markup Language (ebXML) Registry Information Model (ebRIM) Profile (Martell 2007). There are seven operations in the CSW: GetCapabilities, DescribeRecord, GetRecords, GetRecordById, GetDomain, Harvest, and Transaction. The GetCapabilities operation allows CSW clients to retrieve service metadata from a server. The DescribeRecord operation allows a client to discover elements of the information model supported by the target catalog service. The GetRecords request allows queries to the catalog metadata records by specifying a query in OCG filter or Common Query Language (CQL) languages. The GetRecordById request retrieves the default representation of catalog metadata records using their identifier. The GetDomain operation obtains runtime information about the range of values of a metadata record element or request parameter. The Harvest operation can pull data into the catalog. The Transaction operation defines an interface for creating, modifying, and deleting catalog records.

Liang, Croitoru, and Tao (2005) proposed that a geospatial Sensor Web must have the ability to locate, access, and use arbitrary sensors. They developed a distributed geospatial infrastructure for the Sensor Web, called GeoSWIFT. It includes a Sensing Server, a Service registry, and a Service requester. But, the Service registry is implemented as a catalog file, not a web service. Chen et al. (2009) have done some work on remote sensing observation data registry and discovery in a Sensor Web environment. They proposed a middleware that can register SOS into a CSW. Jirka, Bröring, and Stasch (2009b) have studied the registry and discovery of sensors within the OGC SWE framework. They present a discovery framework for the Sensor Web, suggesting a conceptualization incorporating SIR and SOR. The SIR is a web service interface for discovering sensors, collecting sensor metadata, handling sensor status information, and automatically inserting sensor metadata into OGC catalogs. The SOR is a web service interface providing definitions of phenomena observed by sensors, for resolving Uniform Resource Identifiers identifying these definitions and for exploring semantic relationships between phenomena.

3. An architecture for SOS/WFS chaining

3.1. Architecture

The goal of the proposed service middleware is to harvest real-time in situ observation data from a hydrological Sensor Web environment and dynamically integrate the observation data into a WFS compatible 3D virtual earth under an SDI. Service Oriented Architecture (SOA) has been adopted for the service middleware prototype implementation. As shown in Figure 1, the architecture of prototype system is split into three layers: application layer, business layer, and Sensor Web layer.

Figure 1. The architecture and components of the proposed method.

The Sensor Web layer includes two parts: the SOS and the sensors. The main function of the Sensor Web layer is publishing hydrological observation data via standard SOS interface.

The business layer is the core of prototype system. One aspect is to combine a WFS and an SOS into service middleware that enables access to in situ observations in real-time for a specified spatial-temporal range. This accessibility facilitates the on-demand serving of observation data by the middleware. The middleware exposes the universal standard WFS interfaces to client partners and the universal standard SOS interfaces to in situ sensor partners. The other aspect is a CSW that can register and discover the sensor, sensor service, and observation data. The registry function is implemented by SIR and SOR.

The application layer is a WFS compatible 2D map or 3D virtual earth client in an SDI. The client consists of components through which users can access, view, and process hydrological sensor observation data in GML. The client can be deployed as an Internet-based web application or an intranet-based desktop application.

3.2. Components

3.2.1. Sensors

The sensors include in situ sensor and wireless sensor network (WSN). The in situ sensor includes the horizontal acoustic doppler current profiler (H-ADCP), water level gage, and rain gage. These sensors allow for the easy acquisition of hydrological data, including flow rate, water level, and precipitation. The observation data are transmitted via the Public Switched Telephone Network (PSTN), General Packet Radio Service (GPRS), Global System for Mobile Communications (GSM), or satellite communications. The information center can then publish observation data through the SOS on the Internet. The WSN is directly connected to the Internet through a gateway and follows the IEEE 1451 standards. The IEEE 1451 sensors can be integrated into the SOS framework (Song and Lee 2008, 2009).

3.2.2. SOSs

The SOS component offers an approach for encapsulating in situ observations into the web service with deployment in a web container. ‘RegisterSensor’ and ‘InsertObservation’ operations are used to register sensor properties and insert observation data into an SOS. ‘GetCapabilities,’ ‘DescribeSensor,’ and ‘GetObservation’ operations are used to retrieve sensor properties and data from an SOS. The GetCapabilities operation provides metadata including the identifier, provider, operation metadata, filter capabilities, and content. The DescribeSensor operation delivers a detailed description of the sensor encoded using SensorML. The GetObservation operation supplies the observation data encoded by the O&M information model.

3.2.3. Transformer

The transformer component is built to generate the XML schema match between the two different schemas and then creates a corresponding transform template. A generic match system, COMA (Doan, Domingos, and Halevy 2001), is applied to perform the matching test. COMA is a system for creating flexible combinations of match algorithms and represents a generic match system that supports different applications and multiple schema types. It makes available an extensible library of match algorithms and supports different approaches to combine match results. New match algorithms can be included in the library and used in combination with other matchers. Thus, COMA enables the tailoring of match strategies by selecting the match algorithms and their combinations for a given match problem. A variety of matching strategies and dozens of different matchers are adopted to identify the corresponding items between the two schema files. The mapping result can output the Extensible Stylesheet Language Transformations (XSLT) (Clark 1999) templates.

The transform template of XML schema includes: mapping between SOS and WFS, O&M schema and GML schema, and SensorML schema and ebRIM schema. For the mapping between SOS and WFS, we take the example of schema matching between the WFS XML schema (version 1.1.0) and the SOS GetCapabilities XML schema (version 1.0.0), the WFS XML schema (version 1.1.0), and the SOS GetObservation XML schema (version 1.0.0). Shown in Figure 2 is the workflow of the schema transformation including schema import, fragment identification, fragment matching, and mapping combination.

Figure 2. Schema transformation between an SOS and WFS.

The OWS 1.1.0 is the same information model and the basis for WFS XML schema (version 1.1.0), the SOS GetCapabilities XML schema (version 1.0.0), and the SOS GetObservation XML schema (version 1.0.0). Hence, we apply COMA to perform the matching task. All context strategies and CONTEXTS matchers in COMA are used to generate the similarity cube. There are 19 correspondences between the WFS XML schema (version 1.1.0) and the SOS GetCapabilities XML schema (version 1.0.0). There are seven correspondences between the WFS XML schema (version 1.1.0) and the SOS GetObservation XML schema (version 1.0.0). The following statements detail the specifics for schema matching between the WFS XML schema (version 1.1.0) and the SOS GetObservation XML schema (version 1.0.0). The main contents of the SOS GetObservation XML schema are the elements: ‘service,’ ‘version,’ ‘result,’ ‘responseFormat,’ ‘resultMode,’ ‘responseMode,’ ‘srsName,’ ‘offering,’ ‘eventTime,’ ‘procedure,’ ‘observedProperty,’ and ‘featureOfInterest.’ Comprehensive information about these elements from the SOS XML schema is available on the website (http://schemas.opengis.net/sos/1.0.0/). For example, the ‘service’ element is the service type identifier; the ‘version’ element is the specification version for SOS version and operation, and so on. The main contents of the WFS XML schema are elements such as ‘service,’ ‘version,’ ‘handle,’ ‘outputFormat,’ and ‘Query.’ There are seven mappings between the two schemas: ‘service,’ ‘version,’ ‘comparisonOps,’ ‘responseFormat,’ ‘srsName,’ ‘spatialOps,’ and ‘ObjectID.’ The detailed information about these elements is also available from the WFS XML schema, found on the website at http://schemas.opengis.net/wfs/1.1.0/.

The generated correspondent and mapping information are shown in Figure 3. In the top part of Figure 3, the lines represent the mapping between the two schemas and in the lower part of Figure 3, the mapping result returns a similarity matrix SimMatrix used for storing similar nodes and similarity coefficients.

Figure 3. Schema-matching results between sosGetObservation.xsd and wfs.xsd.

For the mapping between O&M schema and GML schema, we take the example of schema matching between observation.xsd (O&M version 1.0.0) and feature.xsd (GML version 3.1.1). GML is used to describe vector geographic data; O&M is used to encode sensor observations and measurements. GML provides all kinds of objects for describing geography including feature, coordinate reference systems, geometry, time, units of measure, and so on. The O&M standard is based on GML, such as the element ‘location’ in an observation.xsd (O&M version 1.0.0). We apply COMA to perform the matching task as well. There are 217 correspondences between observation.xsd (O&M version 1.0.0) and feature.xsd (GML version 3.1.1) (http://swe.whu.edu.cn/ SOSWFS/SOSWFS.aspx). For example, the ‘ObservationCollection’ element in observation.xsd is mapped to ‘FeatureCollection’ in feature.xsd.

For the observation data extractor, the access component enables the direct conversion of an SOS response document in SWE O&M into GML Simple Features profile as necessary. The convert operation uses an XSLT template and an XSLT processor. The transformer component generates the XSLT template while the XSLT processor functions in the same manner as in the conversion of an XML document from an SOS response when producing an output document.

3.2.4. Access

The access component offers an automatic extract function to obtain in situ SOS observation data via WFS. It consists of a WFS component and an extractor component.

The WFS component provides access to in situ observation data from an SOS ‘GetObservation’ response, supporting the interchange of geospatial data as a ‘feature.’ The WFS component supports the use of filters to query a set of feature instances. The operating set can be comprised of one or more enumerated features or a set of features defined by specifying spatial and non-spatial constraints on the geometric and scalar properties of a feature type.

The extractor component converts the XML document from an SOS response into a FeatureCollection in GML or a WFS request into an SOS request to satisfy the specified requirements using an XSLT template and an XSLT processor. The XSLT template is generated by the above-mentioned transformer component. The new document is serialized by the processor in standard OGC SOS or WFS XML syntax. The extraction is executed dynamically by the service middleware. The XSLT processor ordinarily takes two input documents – an XML source document and an XSLT style sheet – and produces an output document.

The WFS ‘GetCapabilities’ extraction is intended to generate a response to the WFS ‘GetCapabilities’ request from the response of the SOS ‘GetCapabilities’ request. The XSLT processor transforms the response of the SOS ‘GetCapabilities’ request to the corresponding response of the WFS ‘GetCapabilities’ request according to the style sheet file generated from the transformer component.

3.2.5. Registry

The registry component registers sensor and sensor service to CSW.

The SIR component provides an interface for automatically registering sensor metadata into OGC CSW and discovering sensors form the CSW. The SIR interface consists of three parts: sensor discovery, sensor status handling, and catalog connection. The discovery part of the SIR interface deals with sensor metadata and metadata of the services that encapsulate the sensors. The discovery part of the SIR interface includes six operations: SearchSensors, DescribeSensor, HarvestService, InsertSensorInfo, DeleteSensorInfo, and UpdateSensorDescription. The SearchSensors operation searches sensor instants by specifying search criteria. The DescribeSensor operation is used to retrieve sensor metadata. The HarvestService operation allows a client to initiate the harvesting process of sensor metadata from a certain SWE service instance. The InsertSensorInfo, DeleteSensorInfo, and UpdateSensorDescription operations are used for inserting, deleting, and updating sensor information. The sensor status handling part provides functionality for handling the status of sensors. The sensor status handling part of the SIR interface includes five operations: GetSensorStatus, SubscribeSensorStatus, RenewStatusSubscription, CancelStatusSubscription, and InsertSensorStatus. The GetSensorStatus operation allows to select sensors and to filter certain status properties when querying for the status of sensors. The SubscribeSensorStatus, RenewStatusSubscription, and CancelStatusSubscription operations support event-based notifications to clients about sensor status changes. The InsertSensorStatus operation allows inserting status information for individual sensors into the SIR. The catalog connection component is an interface to work with CSW. The catalog connection component of the SIR interface includes two operations: ConnectToCatalog and DisconnectFromCatalog. The ConnectToCatalog operation allows SIR clients initiate the transfer of sensor metadata from an SIR instance into an OGC Catalog. The DisconnectFromCatalog operation allows SIR clients to stop continuous push processes of sensor metadata into OGC Catalogs.

3.3. Interaction

3.3.1. External interactions between WFS and SOS

The responses of the WFS are generated based on the SOS responses. The WFS service information in ‘GetCapabilities’ is generated from the ‘ServiceIdentification,’ ‘ServiceProvider,’ and ‘OperationsMetadata’ elements in the SOS ‘GetCapabilities’ response through the schema transformer and information extractor. WFS feature description information – name, title, abstract, bounding box, and DefaultSRS of the result in the ‘FeatureType’ are generated from the ‘ObservationOfferingList’ element in the SOS ‘GetCapabilities’ response. The WFS feature information containing boundedByName, PlatformName, validTime, latitude, and longitude is generated from the SOS ‘GetObservation’ response.

3.3.2. External interactions between SOS and CSW

The SOS interacts with the CSW via the registry component. The SIR HarvestService operation automatically generates sensor information through the DescribeSensor operation. The URL of DescribeSensor operation can be obtained from the SOS Capabilities document. The SIR is also able to use InsertSensorInfo operation, DeleteSensorInfo operation, and UpdateSensorDescription operation to insert, delete, and update sensor information from an SOS instance. Then the SIR can publish the data to CSW. The extractor component can get SOS observation data through the GetObservation operation and can be registered to the CSW as an ebRIM model. The capability content and data can be discovered by a CSW GetRecords operation.

3.3.3. Internal interactions between the transformer and extractor

The extractor component invokes the transformer component to generate ‘GetCapabilities,’ ‘DescribeFeatureType,’ and ‘GetFeature’ XSLT templates between an SOS and WFS. The XSLT processor in the extractor component transforms the response of SOS to the corresponding response of WFS according to the specified XSLT template. A template can contain elements that specify the literal result element structure and also contains elements from the XSLT namespace that serve as instructions for creating result tree fragments.

4. A case study in Jinsha River

4.1. Jinsha River study area

Jinsha River is the major headwater stream of the Yangtze River. Its headwaters rise in the Kekexili ranges in western of Qinghai province, flow via 4 provinces: Qinghai, Xizang, Yunnan, and Sichuan. Geographically, it is located between latitude 24°40’ and 34°50'N and longitude 90°50’ and 104°38'E, the length spans 2308 km, and the area covers approximately 473,200 km². It flows through the famous Hengduan Mountains area, and drops 3300 m. Hydraulic energy sources are abundant on the Jinsha River, accounting for 40% of Yangtze River hydraulic energy resources.

A number of hydrometric stations were built to ensure the appropriate development and utilization of Jinsha River hydraulic resources. Various sensors and sensor networks are used to obtain real-time or near real-time hydrological data. For example, at the Pingshan hydrometric station, the H-ADCP uses the Channel Master 300 developed by Teledyne RD Instruments; the water level gage uses typical bubble pressure water level gage sensors including a 5600-0131-5 Accubar Bubble gage made by Sutron Corporation, and the rain gage uses model JDZ05 (02)-1 tipping bucket rainfall sensor. Such sensors commonly used in hydrology monitoring can automatically acquire observation data (Wang and Xiong 2009).

4.2. Jinsha River hydrological observation SOS

The Jinsha River hydrological observation SOS uses the multipurpose SOS (Chen, Di, and Yu 2009) to serve the observation data, SensorML describes the sensor, and the hydrological observation data is stored in PostGIS database and encoded in O&M. The basic service information ‘offering’ capability can be acquired through the SOS ‘GetCapabilities’ operation, and the observation data can be obtained through the SOS ‘GetObservation’ operation. The Jinsha River hydrological observation SOS contains eight hydrometric stations, namely, Shigu, Jinjiangjie, Panzhihua, Wudongde, Sanduizi, Huatan, Pingshan, and Xiangjiaba. The Jinsha River SOS has three observation offerings: gage height, water flow, and precipitation. At present, there are 261,648 records.

SensorML is the basis for building the H-ADCP, the water level gage, and rain gage models. The SensorModel tool was used to create the sensor models, and uses C# language and.NET Framework 3.5 design and implementation. The main function of the tool is to provide a visual sensor modeling method with SensorML. The SensorML document describes the information for the sensors, including sensor position, sensor status information, input and output phenomena, sensor parameters information etc.

The hydrological observation data are encoded in O&M. The hydrological observation data include gage height, water flow, and precipitation. The observation results have three items including SamplingTime, FeatureOfInterest, and value of the phenomenon, with tokens separated by commas and blocks separated by semicolons.

4.3. Use case data flow

The detailed experimental information for the use case data flow is shown in Figure 4 as follows:

1. The deployed 52°North SIR in LIESMARS uses the HarvestService operation to harvest sensor information from an SOS;

2. The 52°North SIR publishes the metadata to the GeoNetwork CSW Server;

3. The GeoServer WFS registers the metadata record in GeoNetwork, the metadata information directly from the service metadata in GeoServer;

4. The user sends a ‘GetRecord’ request to the GeoNetwork CSW;

5. The GeoNetwork CSW Server returns a WFS server instance;

6. The client uses the address of the WFS server instance and sends a ‘GetFeature’ request to the WFS server instance. The ‘GetFeature’ request includes typeName, outputFormat, and filter. The filter includes time-space, feature ID, sensor ID, and offering ID;

7. The service middleware send transform request to Extractor;

8. The Extractor use sensor ID to search the SOS service in the 52°North SIR;

9. The 52°North SIR returns an SOS server instance;

10. The Extractor sends a ‘GetObservation’ request to the SOS server instance. The ‘GetObservation’ request parameters are generated from the ‘GetFeature’ request;

11. The SOS server instance returns the observation data in O&M;

12. The Extractor transforms the observation data from O&M to GML;

13. The GeoServer WFS server uses transaction operation to update the observation data;

14. The GeoServer WFS server instance returns the observation data in GML.

Figure 4. The Jinsha River case study illustration of the proposed method.

4.4. Sensor registry for JSJ SOS using 52°North SIR

In this paper, we chose the existing implementation of the Sensor Registry framework from the 52°North Open Source Initiative. The SIR deployed in the ‘SIRURL’ (SIRURL=‘http://swe.whu.edu.cn:9002/sir’) to serve and discover the sensor registry. The SIR harvests sensor information within the JSJ SOS service. The SIR can send a GetCapabilites request to the JSJ SOS and parse the response for specific identifiers of all the contained sensors from the capabilities document. These identifiers are used for collecting SensorML descriptions by the ‘DescribeSensor’ operation. The harvested sensor information includes sensor, sensor's position, service, phenomenon, status information, and so on.

4.5. Transformation between JSJ SOS and WFS

The transformation between JSJ SOS and WFS includes the WFS GetCapabilities request to SOS GetCapabilities request, SOS GetCapabilities response to WFS GetCapabilities response, WFS GetFeature request to SOS GetObservation request, and the WFS GetFeature response to SOS GetObservation response. As an illustration, we take the example of SOS GetCapabilities response to WFS GetCapabilities response and WFS GetFeature response to SOS GetObservation response.

The JSJ SOS ‘GetCapabilities’ response contains five elements: ‘ServiceIdentification,’ ‘ServiceProvider,’ ‘OperationsMetadata,’ ‘Contents,’ and ‘Filter capabilities.’ The generated WFS ‘GetCapabilities’ response also contains the above five elements. The ‘ServiceIdentification’ element in the WFS ‘GetCapabilities’ response contains ‘title,’ ‘abstract,’ ‘keywords,’ ‘ServiceTypeVersion,’ ‘Fees,’ ‘ServiceType,’ and ‘AccessConstraints.’ For example, the value of the ‘keywords’ element is ‘<ows:Keyword>water level</ows:Keyword> <ows:Keyword>gage height </ows:Keyword><ows:Keyword>water speed </ows:Keyword>’ and generated from the ‘keywords’ element in JSJ is the SOS ‘GetCapabilities’ response. The ‘FeatureTypeList’ element in WFS ‘GetCapabilities’ response contains one or many ‘FeatureType’ elements. One ‘FeatureType’ contains ‘Name,’ ‘Title,’ ‘Abstract,’ ‘BoundingBox,’ and ‘DefaultSRS’ elements. However, some aspects in SOS are not directly relevant mapping information in the WFS structure. For these elements, some elements can be transformed by logical judgment; the value of ‘DefaultSRS’ element is generated from the ‘boundedBy’ element in the SOS ‘GetCapabilities’ response. Some elements cannot be transformed since the WFS structure does not include these elements, for example the ‘procedure’ elements, ‘observedProperty’ elements, ‘featureOfInterest’ elements, and so on. For more detailed information on transformation, please see the website (http://swe.whu.edu.cn/SOSWFS/SOSWFS.aspx).

The O&M document for the Gage Height measurements from the JSJ ShiGU platform are retrieved using the SOS ‘GetObservation’ request. For example, by using the links shown in the above website, users can directly obtain observation data.

The observation results consist of SamplingTime, water level, and FeatureOfInterest. For instance, the observation has one record ‘2008-01-01T00:00:00.000+08:00, 1001, 1818.24,’ the SamplingTime is ‘2008-01-01T00:00:00.000+08:00,’ the FeatureOfInterest is foi_1001, and the water level is 1818.24m. A ‘FeatureCollection’ object can be generated from the ‘result’ element. The ‘FeatureCollection’ object contains ‘boundedBy,’ ‘name,’ ‘PlatformName,’ ‘validTime,’ ‘latitude,’ ‘longitude,’ ‘depth,’ and ‘observedProperty1’ elements. Then, ‘FeatureCollection’ data can be added using the WFS-T operation and served by the ‘GetFeature’ operation through the specified WFS server.

5. Results and discussion

5.1. The Proposed Method Response Time

Five groups of experiments were conducted for the SOS chaining WFS method. Each group refers to different records in an observation, provided by the ‘1001’ offering: 100, 500, 1000, 5000, and 10,000. In the SOS chaining WFS method, users send ‘GetFeature’ requests to the service middleware, which then sends the ‘GetObservation’ request to the SOS server and obtains the O&M data. The data is then changed to GML in the service middleware. The WFS and SOS servers are deployed in a 1000 Mbps local area network, while a 10 Mbps wide area network connects the client and server. The response time of the methods were measured. Table 1 shows the results. The T (transfer time) and E (extraction time) items represent transfer time and extraction time in the SOS chaining WFS method.

Table 1. Response times of the SOS chaining WFS method.

	Results
Methods	100	500	1000	5000	10,000
SOS chaining WFS
O&M size (KB)	7.81	9.28	45.51	215.64	424.73
GML size (KB)	50.34	249.45	493.48	2467.8	4989.6
Transfer time (s)	0.14	0.172	0.578	2.494	4.953
Extraction time (s)	0.015	0.073	0.138	0.325	0.724

Table 1 shows that the transfer time is much larger than the other durations. Transfer time was the dominant influence on total time. The transfer time is typically affected by transfer net and data size. Although the size of the data in GML is bigger than the data in O&M, the results indicate that the response time can satisfy the demand. The proposed SOS chaining WFS method is feasible for dynamical real-time integration of hydrological observation data into a WFS compatible virtual globe in SDI.

5.2. Easy to Query Hydrological Observations

The prototype system has complete information query functions. The user can use the visual information query module to build query conditions, including spatial and temporal conditions, among others. The prototype system can automatically translate query conditions to a WFS ‘GetFeature’ request. The visual information query module is shown in Figure 5.

Figure 5. Visual query for hydrological observation data in virtual globe.

5.3. Diverse Visualization for Hydrological Observations

The prototype system also supports multiple visual representations, such as tables, charts, 2D maps, and 3D virtual Earth maps. As shown in Figure 6, the observation data are represented by tables and charts.

Figure 6. Diverse visualization for hydrological observation data in virtual globe. (A) Property of hydrometric station, including the name, subordinate river basin, administrative unit, longitude, latitude etc; (B) Stage hydrograph to represent the water level observation data; and (C) Tables to represent the water level observation data.

5.4. Discussion

We successfully integrated the Jinsha River hydrological observations into an SDI and now offer them through the SOS chaining WFS method in a Sensor Web environment. This method is a data service system based on SOA. The system is implemented by service middleware components and packaged into Web services; it is a loosely coupled system and easy to deploy.

Under a Sensor Web environment, the SOS publishes the observation data in the O&M. For GML, the O&M is still a quite new standard. In contrast with the GML, O&M has an advantage at present for time series observation data, but lacks visualization tools. But GML is well accepted and wide applied. The GML allows easy integration and processing. For example, the OGC Web Processing Service (WPS) interface permits GML encoded data to be directly input for subsequent processing. Using the SOS chaining WFS method, the O&M is transformed to GML. This provides a method with which to display and process the O&M data. Although this method could reuse the existing client, interoperability is reduced. Because mapping between SOS and WFS is incomplete, the sensor-specific characteristics are lost in the transform. The other disadvantage of this method is that the observation data size in GML is bigger than O&M and therefore the speed of transmission is longer. According to the experiment results, however, the response time seems perfectly acceptable.

6. Conclusions

This paper proposes a method for using SOS chaining WFS on the basis of service middleware to develop a system for the distribution of Sensor Web data. The methodology is a good approach to enhance existing OGC components (i.e., OGC WFS) and integrate relatively new interfaces such as the OGC SOS. The method uses standardized data collection, dissemination, and exchange mechanisms to seamlessly integrate hydrological observation data sources into virtual globe–based SDI. The system also easily reuses rich querying and visualization functions in the WFS compatible virtual globe for real-time dynamic hydrological observation data. Methods to manage huge heterogeneous hydrological sensors and achieve high-performance information extraction under the Sensor Web environment are directions for future research.

Acknowledgements

This work has been supported in part by the National Basic Research Program of China (973 Program) under Grant 2011CB707101; by the National Natural Science Foundation of China under Grant 41023001, 41171315, and 41021061; by the program for New Century Excellent Talents in University under Grant NCET-11-0394; and by National High Technology Research and Development Program of China (863 Program) under Grant 2012AA121401. We sincerely thank Mr. Steve Mcclure for the language polishing. The authors would like to thank the editors and anonymous reviewers for their valuable comments and insightful ideas.