An Observation Capability Metadata Model for EO Sensor Discovery in Sensor Web Enablement Environments

Abstract

Accurate and fine-grained discovery by diverse Earth observation (EO) sensors ensures a comprehensive response to collaborative observation-required emergency tasks. This discovery remains a challenge in an EO sensor web environment. In this study, we propose an EO sensor observation capability metadata model that reuses and extends the existing sensor observation-related metadata standards to enable the accurate and fine-grained discovery of EO sensors. The proposed model is composed of five sub-modules, namely, ObservationBreadth, ObservationDepth, ObservationFrequency, ObservationQuality and ObservationData. The model is applied to different types of EO sensors and is formalized by the Open Geospatial Consortium Sensor Model Language 1.0. The GeosensorQuery prototype retrieves the qualified EO sensors based on the provided geo-event. An actual application to flood emergency observation in the Yangtze River Basin in China is conducted, and the results indicate that sensor inquiry can accurately achieve fine-grained discovery of qualified EO sensors and obtain enriched observation capability information. In summary, the proposed model enables an efficient encoding system that ensures minimum unification to represent the observation capabilities of EO sensors. The model functions as a foundation for the efficient discovery of EO sensors. In addition, the definition and development of this proposed EO sensor observation capability metadata model is a helpful step in extending the Sensor Model Language (SensorML) 2.0 Profile for the description of the observation capabilities of EO sensors.

1. Introduction

Gross [1] predicted that in the 21st century, the Earth will be covered by an electronic skin in which trillions of remote-sensing and in situ sensors will be networked to create an extensive monitoring system. The types of Earth observation (EO) data include the following: (1) numerical measurements collected by ground-based thermometers, wind gauges, barometers and anemometers; and (2) photos and radar images captured by remote-sensing satellites or unmanned aerial vehicles. Therefore, this study broadly defines the term “EO” as a spaceborne-airborne-ground integrated system used to collect various physical observation data from Earth. Ubiquitous EO sensors are available in the EO field [2]. Such circumstances have compelled a search for the correct sensor or sensor combination that can perform a given observation task efficiently and effectively [3]. Observation capability information (which specifies during which period, on which observation area, with what observed phenomenon and with what observation quality the observation should take place) provides an important index for understanding the observational nature of the sensor and for qualifying the performance of sensor observation. Although observation capability information is inherent in all EO sensors, they still lack effective analysis and summarization. In the current World Wide Web environment, observation capability elements are collected from various sensor sources by different individuals in diverse formats. In particular, heterogeneous and uncertain observation capability elements have become unmanageable with the increasing number of EO sensor resources, which impedes the accurate and comprehensive discovery of these resources.

The sensor web describes an infrastructure [4] in which sensor data and metadata can be published and made accessible to anyone [5]. One of the basic functions of the sensor web is to discover sensors that enable users to find the sensor resources of interest. The Sensor Web Enablement (SWE) initiative of the Open Geospatial Consortium (OGC) defines a standard framework that aims to enable interoperable use of sensor resources and their observations [6,7]. In 2009, a study [8] addressed the discovery mechanism of sensors within the OGC SWE framework. In 2013, Liang [9] noted that sensor discovery for the sensor web remains a challenge and stated that the full potential of the sensor web has not yet been realized.

Metadata provides background information on how, by whom, when and with what quality datasets are created, how they are structured and what information they contain. Simonis and Echterhoff [10] reported that the metadata of sensors, platforms and observation data are critical components of the sensor web infrastructure. Metadata-embedded standard descriptions of sensors are necessary to address the problem of sensor system heterogeneity [11]. Moreover, metadata management is considered as a key to successful heterogeneous data governance [12]. Di et al. [13] analyzed the metadata requirements for the emerging sensor web and noted that no metadata standard can completely cover all metadata elements to enable sharing and interoperability among sensors. Chen et al. [14] analyzed the nine-tuple metadata description framework of the heterogeneous nodes of the sensor web in which the capability of the sensing node was included. Moreover, this group noted that the different capabilities of metadata should be extended according to the specific type of sensing node.

The Sensor Model Language (SensorML) is a part of the SWE framework information model that can provide a flexible and general framework to describe any type of sensor metadata. The SensorML 1.0 [15], which was adopted as the OGC official standard in 2007, is the current widely accepted format for describing sensors in various applications [6,16]. The SensorML 2.0 [17] has been adopted as the OGC official standard in 2014 and is a revision of SensorML 1.0, but contains new features beyond the SensorML 1.0, such as better support for inheritance, configuration of the sensor description and the definition of the positions for both static and dynamic states. Both SensorML 1.0 and 2.0 adopt the concept of “soft-typing” and allow metadata properties to be defined outside of the SensorML schema, rather than attempting to pre-define all possible metadata properties that might be used to describe the particular sensor [18]. In 2008, Simonis and Echterhoff [10] noted that just providing the unified description format could not fully render the SensorML instances interoperable. In 2011, Jirka et al. [19] stated that the flexibility of SensorML in modeling sensors drives the interoperability issue at the encoding level, because multiple methods exist with which to encode sensor characteristics. For example, even the same sensor might be described using different metadata properties and structured methods. To address this issue, the SensorML 1.0-based discovery profile [20] was released in 2011, which defines a minimum set of metadata elements together with their structure to ensure that metadata are described in a consistent manner. Although SensorML 2.0 defined the related Schematron patterns to constrain the minimal and necessary description structure, such as the “gml:identifier”, required for any PhysicalComponent, and the “xlink:href” attribute, required for the “component” property, the need still exists for an unambiguous approach to encode the observation capabilities of a certain EO sensor; the result is that both new and experienced users struggle with building sensor observation capability description instances. Moreover, the newly approved SensorML 2.0 notes that the restriction of generic information models by defining the application-specific metadata profiles of specialized sensors should be included in future works. Therefore, together with the future wide application of the SensorML 2.0-based sensor description framework and the strong need for the accurate and fine-grained discovery for EO sensors, we believe that extending the SensorML 2.0 metadata profile for describing observation capabilities to aid in accurate and fine-grained discovery applications for EO sensors is a significant issue.

The Sensor Observation Service (SOS) [21] is one of the web service interfaces operating under the OGC SWE framework. The SOS relies on a SensorML-encoded sensor description model to provide sensor metadata, such as the position of the sensor, calibration information and the inputs and outputs of the sensing process [22]. From the geo-observation perspective, the SensorML 1.0 information model, which is currently supported by the majority of OGC SWE implementations, primarily focuses on describing: (1) general sensor information (such as the sensor unique ID, long name, short name and sensor type); and (2) coarse-grained sensor observation characteristics (such as the valid sensor observation life, location and spectrum). Therefore, existing sensor observation web services cannot efficiently support accurate sensor queries, because they lack the fine-grained observation capability information.

From a technical perspective, the SensorML editor tool [23] allows a user to describe sensor metadata via a human-friendly interface. A wizard-based modeling method was developed to rapidly and uniformly construct the metadata-filled SensorML information model [24]. The Catalogue Service for the Web (CSW) was developed by OGC and defines a standard interface for discovering geospatial resources by querying their metadata [25]. The CSW is applied to the sensor web resource registry. Chen et al. [26] addressed the registry of the sensor metadata information model using the OGC CSW. In [27], an incremental harvesting approach was proposed that could efficiently harvest the updated metadata. In addition, the Sensor Instance Registry (SIR) can address the sensor web resource discovery issue [28] and supports the transfer of sensor metadata into a specific catalogue, which makes sensors available to users worldwide [29]. The SIR catalog service adopts a SensorML 1.0-based discovery profile to restrict the basic information model [20]. However, this service still lacks restrictions on the observation capability metadata elements. Previous research has also investigated metadata semantic matchmaking [30] and explored sensor metadata discovery and visualization on a 3D virtual globe [31]. However, these technologies do not consider the well-defined observation capability metadata.

From the standard specification perspective, several related metadata standards for sensors and observations have been established, i.e., the International Organization for Standardization (ISO) 19130 series [32,33], the National Geospatial-Intelligence Agency (NGA), the Community Sensor Model (CSM) [34], the Starfish Fungus Language (StarFL) [35] and the Semantic Sensor Network Ontology (SSNO) [36]. These standards offer different aspects, focuses and encoding schema modes. In addition, none of these related standards have comprehensively addressed the observation capability metadata. The details of this comparison are illustrated in a later section.

In summary, from the EO collaborative observation perspective (which requires the accurate and fine-grained discovery for EO sensors), the current sensor observation description model (which only describes the general sensor information based on the SensorML 1.0-based discovery profile or the random and coarse-grained sensor observation characteristics based on the highly flexible SensorML structure) cannot efficiently satisfy the requirement for the retrieval of accurate and fine-grained sensor results. In other words, the lack of an observation capability metadata model hinders the effective discovery of sensor resources in Sensor Web Enablement environments. Hence, this study focuses on EO sensor observation capability metadata as the research object and contributes a metadata model to ensure minimum unification for representing EO sensor observation capability information. In particular, this study aims to: (1) enable sensor providers to present a description (which is as unified as possible) of EO sensor observation capability information in the geospatial sensor web environment; (2) facilitate the accurate discovery for EO sensors in the fastest time possible for common emergency responders; and (3) provide emergency managers with an accurate observation information foundation to answer questions for which sensors have the same Earth observation area for the same or different applications acquired within a given period and with extra properties for observation capabilities to facilitate collaborative observation solutions in a complex observation task.

The remainder of this paper is organized as follows. Section 2 explains the observation capability metadata requirements of EO sensors in the sensor web. Section 3 presents our view of the metadata model architecture. Section 4 demonstrates the instances and applications of the proposed metadata model. Section 5 lists the advantages of the metadata model based on the discussion. Section 6 presents the conclusions and the directions for future work.

2. Observation Capability Information Description Requirements

2.1. Satisfying the Collaborative Planning Scenarios

The entire process of the collaborative planning scenario for EO sensors can be divided into three steps: sensor filtration, sensor optimization and sensor dispatch (Table 1). From the observation perspective, sensor filtration is the basic step used to select a suitable sensor for the observation task. This step requires such observation capability information as the observation principle, observation range and observation cycle. After selection of the basic suitable sensors, these sensors should be optimally combined to realize the collaborative observation in a complementary or enhanced mode. In this step, observation quality, observation coverage and observation application are used to determine the collaboration type for different sensors. The last step is to dispatch the sensors after the first two steps. Sensor dispatch should consider complex capability factors, such as the means of accessing data, data storage and data communication and transmission. Given that our focus is on the observation capability perspective, we primarily investigate which observation capability elements can affect actual sensor dispatch, i.e., observation adjustment.

Table 1. Steps for sensor collaborative planning scenarios. IFOV, instantaneous FOV.

	Steps
	Sensor Filtration			Sensor Optimization			Sensor Dispatch
Observation Capability sets	Observation principle	Observation range	Observation cycle	Observation quality	Observation coverage	Observation application	Observation adjustment
Observation Capability elements	Measures; Band types; isActive; isMobile;	Temporal/ Spectral/ GroundResolutionRange; Swath; FOV	Sample interval; revisit period	Temporal/ ground/ spectral/ Radiation accuracy	Coverage rates;	Sensor designed Application; band Main Application	CanSide Swing; SideSwing Angle; IFOV
Examples	Existing DB: SrawCollection Query Operation: Measures = “Remote Sensing”; isActive = “Yes”; SpectralResolutionRange = “0.1 µm–0.8 µm”… Output1: Soutput1			Input DB: Soutput1 Query Operation: Radiationaccuracy = “”; bandMainApplication = “Multipurpose imaging | water surface”… Output1: Soutput2			Input DB: Soutput2 Query Operation: CanSideSwing = “Yes”; SideSwingAngle = “15”…Output1: Slastoutput

Table 1. Steps for sensor collaborative planning scenarios. IFOV, instantaneous FOV.

	Steps
	Sensor Filtration			Sensor Optimization			Sensor Dispatch
Observation Capability sets	Observation principle	Observation range	Observation cycle	Observation quality	Observation coverage	Observation application	Observation adjustment
Observation Capability elements	Measures; Band types; isActive; isMobile;	Temporal/ Spectral/ GroundResolutionRange; Swath; FOV	Sample interval; revisit period	Temporal/ ground/ spectral/ Radiation accuracy	Coverage rates;	Sensor designed Application; band Main Application	CanSide Swing; SideSwing Angle; IFOV
Examples	Existing DB: SrawCollection Query Operation: Measures = “Remote Sensing”; isActive = “Yes”; SpectralResolutionRange = “0.1 µm–0.8 µm”… Output1: Soutput1			Input DB: Soutput1 Query Operation: Radiationaccuracy = “”; bandMainApplication = “Multipurpose imaging | water surface”… Output1: Soutput2			Input DB: Soutput2 Query Operation: CanSideSwing = “Yes”; SideSwingAngle = “15”…Output1: Slastoutput

The above analysis presents the process for determining the observation capability information that should be required in EO sensor collaboration scenarios.

2.2. Based on Existing Related Metadata

This section compares the capabilities of existing sensor metadata sets. An overview is given in Table 2.

Table 2. Comparisons among existing observation capability-related metadata sets. NGA, National Geospatial-Intelligence Agency; CSM, National Geospatial-Intelligence Agency; SSNO, Semantic Sensor Network Ontology; SensorML, Sensor Model Language; StarFL, Starfish Fungus Language; UML, Unified Modeling Language.

Features	Types
	ISO 19130	NGA CSM	SSNO	SensorML 1.0 Discovery Profile	StarFL
Main aspects
Observation principle	✕	✕	○	○	○
Observation range	○	○	√	○	○
Observation cycle	✕	✕	✕	✕	✕
Observation quality	○	○	√	✕	○
Observation application	✕	✕	○	✕	○
Observation adjustment	√	√	✕	✕	✕
Focus	Imagery Sensor Model	Community Sensor Model	Semantic Sensor Web	Restricting the sensor description	Restricting the sensor description
Usage	Geopostioning of imagery data	Implementation of each imagery sensor geopositioning	Linked sensor data	Sensor discovery	Sensor discovery
Encoding Schema	N/A	N/A	OWL	Xml	UML

Notes: √: Supported; ○: Partially Supported; ✕: Unsupported.

Table 2. Comparisons among existing observation capability-related metadata sets. NGA, National Geospatial-Intelligence Agency; CSM, National Geospatial-Intelligence Agency; SSNO, Semantic Sensor Network Ontology; SensorML, Sensor Model Language; StarFL, Starfish Fungus Language; UML, Unified Modeling Language.

Features	Types
	ISO 19130	NGA CSM	SSNO	SensorML 1.0 Discovery Profile	StarFL
Main aspects
Observation principle	✕	✕	○	○	○
Observation range	○	○	√	○	○
Observation cycle	✕	✕	✕	✕	✕
Observation quality	○	○	√	✕	○
Observation application	✕	✕	○	✕	○
Observation adjustment	√	√	✕	✕	✕
Focus	Imagery Sensor Model	Community Sensor Model	Semantic Sensor Web	Restricting the sensor description	Restricting the sensor description
Usage	Geopostioning of imagery data	Implementation of each imagery sensor geopositioning	Linked sensor data	Sensor discovery	Sensor discovery
Encoding Schema	N/A	N/A	OWL	Xml	UML

Notes: √: Supported; ○: Partially Supported; ✕: Unsupported.

The detailed overview covers the following information: (1) The ISO 19130 series [33,34] and NGA CSM [35] provide the metadata aspects for geo-positioning of the remote-sensing sensor from the perspectives of concept and implementation, respectively. Therefore, these standards include geo-positioning metadata, i.e., swath, field of view (FOV), instantaneous FOV (IFOV) and accuracy. (2) The SSNO [36] establishes a large ontology database on the concepts of and relationships between sensors and observations and displays the properties of measurement capabilities and survival or operating ranges, i.e., accuracy, precision and resolution. However, the core design pattern of SSNO is structured to enable the linked sensor data applications [37,38]. Moreover, defined properties are not differentiated and refined according to different sensor types. (3) The SensorML profile for discovery [20] defines the described structure, which ensures that metadata are described consistently. This profile restricts the observation capabilities and only includes observation position and observation status (isActive and isMobile). (4) StarFL [35], which defines a restricted vocabulary and model for sensor metadata, is based on SensorML and SSNO. StarFL only demonstrates measurement capability (accuracy, resolution and range) when applied to most sensor cases.

2.3. Use of EO Sensor Observation Discovery

Analysis of the requirements for sensor observation discovery within the SWE framework involves two essential conditions:

• Sensor observation information representation elements
• Sensor observation information description model

The first condition refers to the information applied by a user to search an individual sensor observation, and the second is a carrier used by (1) the sensor modeler to express its sensors and (2) a sensor inquirer to search the required sensor observation. Sensor observation information representation elements generally present heterogeneous and uncertain situations. Currently, the SensorML included in the OGC SWE framework is used as a description standard for the interoperability of sensor resources and their related properties. The SensorML-based description model is at a stage that primarily describes general sensor metadata, including sensor ID, sensor name, sensor type, sensor valid time, sensor publication and other general coarse-grained sensor properties. This type of description model enables the primary level of sensor discovery rather than fine-grained sensor observation discovery. The sensor inquirer cannot efficiently explore and maximize the use of observation capability information, because of the randomness and uncertainty of the sensor observation information representation elements. For example, the inquirer cannot grasp such information, such as which sensors can cover certain observation phenomenon at the required response speed and precision. Hence, accurate and fine-grained discovery for sensor observation is restricted.

3. Metadata Model Framework

3.1. Architecture and Sub-Modules

Given that the aforementioned metadata standards (Section 2.2) do not solely and fully satisfy the requirements of the mission of accurate and fine-grained discovery for EO sensors, the appropriate metadata are always purpose dependent [39]. The solutions offered in this study are designed to build on the existing OGC standards and expand new metadata elements. The proposed metadata model considers the following principles:

(1)

Comprehensive and non-redundant representation: This principle aims to describe the observation capability information of EO sensors with the least complexity. This representation does not intend to consider every detail of the observation capability information of EO sensors, but only covers the common and important facets required in accurate discovery and collaborative observation.

(2)

Geo-event-centric reflection: This principle indicates that the observation-related temporal, spatial and thematic facets should be contained; these facets are the key elements used to reflect the observation requirements of a geo-event.

(3)

Extensibility: This principle maintains maximum reusability, but allows extension to satisfy the higher requirements of individual communities.

The proposed metadata model and sensor capability description model function as an intermediary broker between sensor inquirers and EO sensors. Sensor inquirers can precisely discover the diverse EO sensors using the sensor capability description model-based engine.

As shown in Figure 1 (from the bottom up), the disordered and not-well-defined EO sensor observation capability elements can be described by various metadata (descriptive and structural metadata) defined in the Dublin Core (DC) Metadata Element Set. The sensor observation capability metadata can be classified as those types of metadata. Next, the proposed metadata model can be formalized using the OGC SensorML 1.0 standard into the sensor capability description model. The formalization process is referenced in our previous work [24]. The foundation of the EO sensor discovery architecture is its metadata model, which is composed of the ObservationBreadth, ObservationDepth, ObservationFrequency, ObservationQuality and ObservationData modules.

Figure 1. Architecture of the EO sensor discovery system.

Figure 1. Architecture of the EO sensor discovery system.

Figure 2 shows the design pattern of our proposed metadata model. The included sub-modules can be interpreted as follows.

(1)

ObservationBreadth is derived from the scope dimension, which starts from the horizontal scales of observation. This module should contain observation range parameters in geospatial and thematic fields (e.g., ground resolution range, band categories and spectral range), i.e., the included elements in this module determine the observation range.

(2)

ObservationDepth is derived from the degree dimension, which starts from the vertical scales of sensor observation. All elements that represent the depth of observation can be included in the ObservationDepth module. Unlike the elements in ObservationBreadth, which present the observation range, the elements in ObservationDepth reflect the fine granularity of spatial- and thematic-related observation aspects (e.g., ground resolution, specific band type and band-associated application) and determine the observation degree.

(3)

ObservationFrequency is derived from the timescale dimension, because evaluation of the time efficiency of sensor observation is vital. The ObservationFrequency module focuses on observation time.

(4)

ObservationQuality is derived from the accuracy dimension. The elements that represent the quality of observation can be considered in this module, which determines the quality of sensor observation.

(5)

ObservationData: The EO sensors are used to perform a particular observation task. The accessed observation data are used in subsequent observation warning, emergency analysis or decision-making. Therefore, ObservationData is an essential module derived from the observation result dimension.

Figure 2. Design pattern of the proposed metadata model framework.

Figure 2. Design pattern of the proposed metadata model framework.

3.2. Contents of the Proposed Metadata Model

Sensor classification improves the storage and discovery of sensors [8]. The EO sensors can be classified according to such sensor measures as remote and in situ sensing and according to such mounting platforms as satellite, airborne and ground [15]. The sensors of a remote-sensing satellite can be divided into imagery and non-imagery. In the ISO 19130 series, the imagery sensors are classified according to types based on the observation mechanism of the sensor, which include frame, scanner and radar. From the spectral perspective, imagery sensors can be divided into optical and microwave fields. From the energy-sensing perspective, the current classification mode for in situ sensors is COMETMAN [40,41] (chemical, optical, mechanical, electrical, thermal, magnetic, acoustic and nuclear energy). From the observation application view angle, in situ sensors are primarily scalar-based acquisition devices, i.e., temperature, pressure and water level sensors. Figure 3 illustrates the proposed EO sensor classification scheme. Notably, (1) an airborne sensor can be categorized as a satellite remote-sensing sensor or a ground-based in situ sensor, and (2) a non-imagery sensor carried by a satellite is a special EO sensor with complex and different observation principles. Hence, the proposed EO sensor observation capability metadata model is determined based on frame, scanner and radar remote-sensing sensor type, as well as the general in situ sensor type.

Figure 3. Classification scheme of EO sensor resources.

Figure 3. Classification scheme of EO sensor resources.

This section aims to identify the detailed contents of the proposed metadata model. As shown in Figure 4, the EO sensor observation capability metadata (EOSM_ObservationCapability) uniformly presents the necessary contents of the metadata model in the Unified Modeling Language (UML). The EOSM_ObservationCapability can be divided into two classes, namely:

• EOSM_RSObservationCapability,
• EOSM_in-situObservationCapability.

EOSM_RSObservationCapability can be specialized as follows:

• EOSM_RSObservationBreadth,
• EOSM_RSObservationDepth,
• EOSM_RSObservationFrequency,
• EOSM_RSObservationQuality,
• EOSM_RSObservationData.

Similarly, EOSM_in-situObservationCapability can be specialized as follows:

• EOSM_in-situObservationBreadth,
• EOSM_in-situObservationDepth,
• EOSM_in-situObservationFrequency,
• EOSM_in-situObservationQuality,
• EOSM_in-situObservationData.

In addition to the five proposed metadata sub-modules, all EO sensors contain a set of common observation capability elements that will not be categorized into the proposed five modules. As shown in Figure 4, the common observation capability elements of EOSM_ObservationCapability include sensor type, sensor observation height, sensor measure type, sensor movability, sensor operating status, sensor position, sensor platform, sensor designed applications, sensor observation validity time and sensor observation planning service. Given that the definitions of the five modules have been analyzed in Section 3.1, Figure 4 illustrates the detailed observation capability metadata fields of the five sub-modules related to remote-sensing and in situ sensors.

Figure 4. UML diagram of EO sensor observation capability metadata model contents.

Figure 4. UML diagram of EO sensor observation capability metadata model contents.

The existing metadata standards (i.e., ISO 19130, NGA CSM, SensorML discovery profile, StarFL and ISO 19156) contain metadata fields related to sensor observation capability aspects (analyzed in Section 2.3).

As shown in Table 3, taking these existing metadata standards into account, the fields “SwathRange” inside EOSM_RSObservationBreadth, “IFOV” inside EOSM_RSObservationDepth and “GeolocationAccuracy” and “RadiometricAccuracy” inside EOSM_RSObservationQuality can be reused from ISO 19130 [32,33]. The fields “SensorIsMobile” and “SensorIsActive” inside the common observation capability of EOSM_ObservationCapability and “ObservedBBox” inside EOSM_RSObservationBreadth can be reused from the SensorML profile for discovery [20]. The field “NadirResolution” inside EOSM_ScannerRSObservationDepth, “GroundResolution” and “RadiationResolution” inside EOSM_OpticalBandCharateristic, “ObservationResolution” inside EOSM_in-situObservationBreadth and “ObservationRange” inside EOSM_in-situObservationDepth can be reused from StarFL [35]. The fields “ObservedProcedure”, “ObservedFeature” and “ObservedProperty” of EOSM_AllObservData can be reused from ISO 19156 [42]. The other metadata fields are extended according to the fine-grained discovery requirements. For example, “ObservableHeight”, “RevisitTime”, “SampleInterval” and “GrayLevel” are the newly defined fields that can be categorized as descriptive metadata in the DC Metadata Element Set. At the same time, the others (such as “ObservationData”, “ObservationQuality”, “BandsCharacteristics” and “ModeCharacteristics”) are the newly defined fields categorized as the structural metadata in DC.

Table 3. The proposed observation capability metadata reusing the existing metadata standards.

Metadata Sub-Modules	Metadata Fields	Existing Metadata Standards Reused
EOSM_RSObservationBreadth	SwathRange	ISO 19130
EOSM_RSObservationDepth	IFOV
EOSM_RSObservationQuality	GeolocationAccuracy, RadiometricAccuracy
common observation capability of EOSM_ObservationCapability	SensorIsMobile, SensorIsActive	SensorML profile for discovery
EOSM_RSObservationBreadth	ObservedBBox
EOSM_ScannerRSObservationDepth	NadirResolution	StarFL
EOSM_OpticalBandCharateristic	GroundResolution, RadiationResolution
EOSM_in-situObservationBreadth	ObservationResolution
EOSM_in-situObservationDepth	ObservationRange
EOSM_AllObservData	ObservedProcedure, ObservedFeature, ObservedProperty	ISO 19156

Table 3. The proposed observation capability metadata reusing the existing metadata standards.

Metadata Sub-Modules	Metadata Fields	Existing Metadata Standards Reused
EOSM_RSObservationBreadth	SwathRange	ISO 19130
EOSM_RSObservationDepth	IFOV
EOSM_RSObservationQuality	GeolocationAccuracy, RadiometricAccuracy
common observation capability of EOSM_ObservationCapability	SensorIsMobile, SensorIsActive	SensorML profile for discovery
EOSM_RSObservationBreadth	ObservedBBox
EOSM_ScannerRSObservationDepth	NadirResolution	StarFL
EOSM_OpticalBandCharateristic	GroundResolution, RadiationResolution
EOSM_in-situObservationBreadth	ObservationResolution
EOSM_in-situObservationDepth	ObservationRange
EOSM_AllObservData	ObservedProcedure, ObservedFeature, ObservedProperty	ISO 19156

The proposed metadata model complies with the EO sensor classification (Figure 3). Using the EOSM_RSObservationDepth as an example, this class can be specialized as follows:

• EOSM_FrameRSObservationDepth,
• EOSM_ScannerRSObservationDepth,
• EOSM_RadarRSObservationDepth.

The different fields of these classes are demonstrated in Section 4. In developing these fields for the proposed metadata model, we adopt a “hybrid” approach to reuse and extend existing standards. The class of EOSM_ObservationInfoExtension is retained for extension to satisfy future individual and higher requirements.

4. Instances and Applications

4.1. Metadata Instances for Diverse EO Sensors

This section presents an EO sensor observation capability metadata model of three different types: remote-sensing scanner, radar and in situ sensors.

As shown in Figure 5, Figure 6 and Figure 7, EOSM_ObservationCapability are inherited by the following:

• EOSM_ScannerRSObservationCapability,
• EOSM_RadarRSObservationCapability,
• EOSM_in-situObservationCapability.

That is, the three metadata models contain the common observation capability fields included in EOSM_ObservationCapability. Given different observation characteristics and observation discovery requirements, these classes contain diverse observation capability metadata fields.

In Figure 5, EOSM_ScannerRSObservationBreadth includes such metadata fields as “BandsNumber”, “BandsWidthRange”, “FOV” and “ObservedBBox”. These fields are related to the spatial, thematic and, specifically, the scalar-based range. EOSM_ScannerRSObservationDepth develops the fields that reflect the fine granularity of spatial- and thematic-related observation aspects, such as “IFOV”, “BandCharateristics”, “NadirResolution” and “QuantizationLevel”. The radar-based sensor is an “active sensor” with a sensor-answer mode that is different from that of the scanner-based passive sensor. Therefore, compared with EOSM_ScannerRSObservationBreadth, EOSM_RadarRS ObservationBreadth (Figure 6) uniquely contains “IncidenceAngleRange”, “PolarizationBandsCategory”, “PolarizationFrequencyRange”, “PolarizationType” and “RadarType”. The EOSM_RadarRSObservation Depth includes “ModeCharacteristics”, but not “BandsCharacteristics”. However, given the different observation principles between remote-sensing and in situ sensors, metadata fields inside EOSM_in-situObservationBreadth and EOSM_in-situObservationDepth (Figure 7) present considerable differences with those inside EOSM_RSObservationBreadth and EOSM_RSObservationDepth.

In addition, Figure 5 and Figure 6 show that remote-sensing scanner and radar sensors have the same metadata fields related to ObservationFrequency and ObservationQuality. In other words, “RevisitTime” is the common field inside ObservationFrequency. The common fields inside the ObservationQuality of the two sensors can be generalized into the structural metadata class EOSM_RSObservQuality (Figure 4). However, EOSM_in-situObservationFrequency shows different metadata fields from EOSM_ScannerRSObservationFrequency and EOSM_RadarRSObservation Frequency. In addition, EOSM_in-situObservationQuality shows different metadata fields from EOSM_ScannerRSObservationQuality and EOSM_RadarRSObservationQuality (Figure 7).

In any type of sensor observation data, the observed procedure, feature and observable property should be included. All observations should also contain their corresponding data type and access level. If possible, sensors and observations should offer distributed web access service in the sensor web environment. Therefore, Figure 5, Figure 6 and Figure 7 show that the three metadata models have the same metadata fields related to the ObservationData module.

Figure 5. Remote-sensing scanner sensor observation capability metadata model.

Figure 5. Remote-sensing scanner sensor observation capability metadata model.

Figure 6. Remote-sensing radar sensor observation capability metadata model.

Figure 6. Remote-sensing radar sensor observation capability metadata model.

Figure 7. In situ sensor observation capability metadata model.

Figure 7. In situ sensor observation capability metadata model.

4.2. Applications in Discovery

The proposed metadata model defined in Section 3 can be formalized using the SensorML 1.0 description standard. By adopting our previous wizard-based modeling method [24], the current research constructs the capability description model of nearly 100 sensors. These sensors are encoded within the proposed observation capability properties and include the currently available flood observation, supporting satellite sensors and ground-based in situ sensors (hydrology, meteorology and soil monitoring) around the Yangtze River in China. For the “value” sources of the proposed observation capability metadata elements, we conducted extensive investigations and primarily referenced the following databases: the Committee on Earth Observation Satellites (CEOS) database (http://database.eohandbook.com/ database/instrumenttable.aspx), the CEOS system database for satellite observation of floods (http://ceos-sysdb.com/CEOS/db_includes/sp_flood.php), the World Meteorological Organization (WMO) Observing Systems Capability Analysis and Review Tool (http://www.wmo-sat.info/oscar/) and the NASA Global Change Master Directory (GCMD) (http://gcmd.gsfc.nasa.gov/KeywordSearch/Keywords.do?Portal=GCMD&MetadataType=0&Columns=0&KeywordPath=Instruments).

The Yangtze River is located within the latitude range of 24°27′N to 35°54′N and longitude range of 90°13′E to 122°19′E and covers an area of approximately 180 km². The Chinese terrain is highly elevated in the west and low in the east, which creates a ladder-level distribution. Annual precipitation in the upper reaches of the Yangtze River exceeds 1600 mm to 2000 mm. Thus, the middle reaches of the river (latitude: 28°9′36″N to 32°3′36″N, longitude: 111°16′48″E to 116°13′12″E) are the most vulnerable to flooding, because of heavy rainfall in the upper reaches. The flow of the Yangtze River is variable and exhibits seasonal behavior. Flow is low during winter months, and peak flow occurs during May and October.

The GeosensorQuery prototype (http://gsw.whu.edu.cn:8080/GeosensorQuery) was developed by the research team to provide the following functions: integrated discovery of EO sensors and representation of their observation capability information.

The integrated discovery module follows a wizard user interface pattern and consists of three request methods for matching qualified EO sensors (Figure 8), namely: By Geo-Event Observation Information (Mandatory), Further By Sensor Basic Information (Optional), and Further By Sensor Observation Capability Information (Optional). In the “By Geo-Event Observation Information (Mandatory)” menu bar, the listed value of “thematic_of_geo-event” is collected from the metadata elements: (1) “Sensor_designed_applications” designed in all sensors; (2) “BandAssociated Application” in optical remote-sensing sensors; (3) “ModeApplication” in radar remote-sensing sensors; and (4) “ObservationApplication” in in situ sensors. “ObservationStartingTime”, “ObservationEndingTime” and “ObservedBoundingBox” are used to build the spatiotemporal observation request for a particular geo-event. In “Further By Sensor Basic Information (Optional)”, the sensor inquirer can further constrain the search criteria using “text fragment”, “keywords”, “sensorLongName”, “sensorShortName”, “sensorType”, “sensorPlatform”, “SensorObservation PlanningService” and “SensorObservationService”. “Further By Sensor Observation Capability Information (Optional)” clarifies the search criteria by specifying such observation capability properties as observation breadth, observation depth, observation frequency, observation quality and observation data.

As shown in Figure 8, our prototype prompts sensor inquirers (who might be common emergency responders or emergency managers) to build their own search criteria by combining metadata items according to actual geo-event observation requirement.

Figure 8. Search request by combining observation capability items.

Figure 8. Search request by combining observation capability items.

The proposed metadata model is applied in the sensor discovery for the geo-event case of a flooding emergency that occurred in the middle reaches of the Yangtze River. The application of sensor technology in flood emergency observation involves measurement of water level, precipitation, water flow, geographical location of flooding water and water capacity. In this study, we aim to retrieve all EO sensors, including remote-sensing and in situ sensors, and, subsequently, select water level, precipitation and water surface as the parameters that require monitoring. Therefore, a concrete sensor query is conducted where “sensor_measure_type = integration”, “thematic_of_geo-event = (water level, precipitation, water surface)”, “ObservationStartingTime = 2014-05-11T17:30:47”, “Observation EndingTime = 2014-05-11T18:30:47”, “MaxLatitude(decimal) = 31.186” and “MaxLongitude(decimal) = 116.061”, “MinLatitude(decimal) = 28.677” and “MinLongitude(decimal) = 110.798”.

Figure 8 shows the result of the search request. Five satisfied EO sensors tagged with serial numbers, namely, “WZH soil temperature and humidity sensor1”, “Tipping bucket rainfall sensor JDZ05(02)-1”, “C band Synthetic Aperture Radar”, “Very High Resolution Radiometer” and “New infrared scanning technology instrument” are targeted from the constructed sensor library. Although five sensors cover the experimental area in the given hour, the period and the coverage rate that intersects the specific experiment area are different. Figure 9 presents how each sensor can complete an observation thematic application. For example, the RADARSAT-2_C band Synthetic Aperture Radar can be used for water-surface observation applications.

Figure 9. Discovery results of a given geo-event application.

Figure 9. Discovery results of a given geo-event application.

The observation capability information representation module can provide support in (1) browsing each SensorML 1.0-based sensor information model embedded within the proposed observation capability metadata (Figure 10) and (2) viewing the enriched observation capability properties of all retrieved EO sensors in a metadata table (Figure 11).

This prototype can conduct other fine-grained queries due to the clear hierarchal metadata of our proposed model. For example, we can reset the query of Figure 8, where “sensor_measure_type = remote sensing” and the others remain the same. Next, in the “Further By Sensor Observation Capability Information (Optional)” menu bar, we provide further constrained query criteria, i.e., those in Figure 12.

Figure 10. SensorML 1.0-based information model.

Figure 10. SensorML 1.0-based information model.

Figure 11. Sample of the overall representation of the observation capability information of all retrieved sensors.

Figure 11. Sample of the overall representation of the observation capability information of all retrieved sensors.

Figure 12. Further search request via fine-grained observation capability items.

Figure 12. Further search request via fine-grained observation capability items.

Accurate and fine-grained remote-sensing satellite sensors are retrieved by integrating the altered search criteria in Figure 8 and the new search criteria in Figure 12 as the new search request. Similarly, we can reset fine-grained queries to find the accurate in situ sensors.

5. Discussions

5.1. Comprehensive and Extensible Metadata Model

This research draws on the experience of the EO metadata profile [43], which describes the metadata model structured to follow different EO products (optical, radar, etc.). The proposed metadata model is structured to follow different EO sensors (frame, scanner, radar imagery and in situ) and contains five sub-modules, namely ObservationBreadth, ObservationDepth, ObservationFrequency, ObservationQuality and ObservationData. The model also considers existing related standards (Table 2). In particular, the proposed model includes metadata elements, such as geo-location parameters (swath, FOV, IFOV, GeolocationAccuracy) in ISO 19130 and NGA CSM, measurement capabilities and operating ranges in SSNO, observed bounding box and observation status (isActive and isMobile) in the SensorML profile for discovery and measurement capability (accuracy, resolution and range) in StarFL. In addition, the proposed model combines the observation data metadata (observed procedure, observed feature, observable property and data type) of ISO 19156 [42], which are not considered in the aforementioned sensor-related standards. Provided that the concrete metadata elements have been defined from the object-oriented design pattern (e.g., even if the current maximum reusable metadata elements may be unsuitable for the individual requirements), it allows the extension of adding or revising the metadata element (Figure 4). However, the proposed metadata model framework is maintained.

5.2. Support for the Current Sensor Registry/Discovery Service

Given that the proposed metadata model can be expressed or formalized by the SensorML, the sensor information models based on the observation capability metadata can be applied to existing sensor registry/discovery services, i.e., SIR, SOS and CSW. Taking our deployed service implementations (SIR and SOS) that rely on the 52° North open source software (http://52north.org /downloads/sensor-web) as examples, the SIR (http://gsw.whu.edu.cn:8080/SIR) allows a sensor inquirer to search for sensor instances based on search criteria, such as observed phenomenon, observed data, temporal criteria, text fragments, units of measure, sensor ID and SWE service. The SOS (http://gsw.whu.edu.cn:8080/SOSv3.5.0) only supports searching for a sensor of interest using sensor ID. The CSW (http://gsw.whu.edu.cn:9004/WuhanCsw/jsps/login.jsp) allows sensor inquiry, but is generally limited to such search criteria as sensor ID, static temporal criteria and spatial combination. The proposed metadata model consists of a suite of clear hierarchical metadata and can support the search criteria within a detailed and fine-grained hierarchy. The search can be accurately located by comparing it with the current sensor discovery service, in which sensor searches primarily rely on a simple mode by combining the search criteria of sensor ID, temporal criteria and text fragments. The possibility of integrating the metadata model with existing sensor registry/discovery services can facilitate accurate and targeted EO sensor results.

5.3. Satisfaction of Efficient Discovery and Collaborative Planning Scenarios

In addition to existing sensor discovery services (SIR, SOS and CSW) that can be deployed openly, website-based search engines, such as Google, NASA’s GCMD retrieval portal (http://gcmd.nasa.gov/index.html) and remote-sensing planning tools (http://ww2.rshgs.sc.edu/), are also available. Google facilitates sensor inquiries to determine suitable sensors using fuzzy modes, such as the text fragments of the emergency request. The GCMD refines the desired sensor resources according to the given free text. In the application described in Section 4, the GeosensorQuery prototype supports the combined query of the observation capability metadata items, which fully reflects the observation request of the complex geo-event. Consequently, fine-grained and accurate sensor results can be obtained (Figure 8). In addition to briefly listing the related observation capability information with respect to observation time, the observation coverage rate and associated observation theme are satisfied for the given geo-event, as shown in Figure 9, and Figure 11 presents all of the proposed observation capability information in which sensor inquirers can further obtain other detailed observation capability information (such as “RadiometricAccuracy”, “GroundResolution” and “ObservationResolution”), which aid them in determining which sensor is superior after comprehensive comparison is performed. Moreover, emergency managers can clearly grasp information, such as which particular sensors in a specific period contain related observation applications with extra properties (observation resolution, accuracy and observation access service). This information enables users to determine which sensor combinations can work together to complete the given geo-event observation task. All of the aforementioned advantages are attributed to the proposed metadata model.

5.4. Support for the Formulation of the SensorML 2.0 Profile for Describing Observation Capabilities

The future wide application of the SensorML 2.0 can enable sensor providers or modelers to construct a unified and more powerful sensor description format with better support for defining the inheritance, configuration, modes, feature of interest (FOI), static and dynamic position, data interface and data stream of a sensor or sensor process. The SensorML 2.0 notes that defining the application-specific metadata profiles of specialized sensors should be included in future works. Therefore, we believe that our metadata model with well-defined observation capability properties can aid in formulating the SensorML 2.0 profile for describing observation capabilities.

The rest of this section presents the process of formalizing our metadata model using the SensorML 2.0 framework. In our metadata model, the described object is the sensor observation capability metadata, not the data nor the observation process. The SensorPosition and ObservedBBox properties involve a position that can be either static (e.g., fixed camera) or dynamic (e.g., movable satellite sensors). Therefore, our proposed metadata model can be described by SensorML 2.0 as the physical processes, but without emphasizing the information required for the execution of the process. In other words, our metadata model can be modeled as the physical component or physical system, in which the observation capability metadata can be primarily described by the sml:characteristics or sml:capabilities structures, but the elements (i.e., sml:inputs, sml:outputs, sml:parameters, sml:components and sml:connections) directly related to the process execution can be omitted or optionally described. In addition, the “observedFeature” property designed in the ObservedData sub-module can be described using sml:featuresOfInterest. In SensorML 2.0 (also in SensorML 1.0), the sml:capabilities provides information that further clarifies the input or output of the process, whereas sml:characteristics provides useful properties that primarily aid in identification, discovery and qualification of the sensor or sensor process without affecting the execution of the process itself.

With the above analysis, we take a concrete SensorML 2.0-based description of our proposed observation capability metadata model as an example. The process model type can be selected as the physical component; the “SensorType”, “SensorMeasures” and “Sensor_designed_applications” properties can be encoded in the sml:classification metadata set; the “observedFeature” property can be described in the sml:featuresOfInterest; and the “SensorPosition” can be described in the sml:Position structure with different means, such as byDescription, byPoint, byLocation or byTrajetory. Because the observation capability properties are primarily used for understanding the observational nature of the sensor and for qualifying the performance of sensor observation, they can be described by the sml:characteristics structure in which those well-defined properties can be listed as individual data components (e.g., scalar data types including Boolean, text, count, quantity, category and time; and their range equivalents defined in the SWE Common Data Model) or grouped with related properties using DataRecord, DataArray, Vector, etc. [18].

It is envisioned that our proposed observation capability metadata will be encoded in SensorML 2.0 from the sensor manufacturer. The sensor users can then reference the sensor manufacturer’s description of the model and provide additional characteristic information that is specific to the given spatio-temporal conditions. For example, an observation capability metadata description model encoded in SensorML 2.0 for the Moderate Resolution Imaging Spectroradiometer (MODIS) can be found at http://gsw.whu.edu.cn:8080/MODIS-SensorML2.0.xml. Combined with the new features of SensorML 2.0, the observation capabilities of MODIS deployed on the AUQA satellite at certain temporal conditions (e.g., time period (2014-09-23T14:36:15Z, 2014-09-23T15:36:15Z)) can be further described. As shown in http://gsw.whu.edu.cn:8080/MODIS_AQUA-SensorML2.0.xml, we can use the sml:typeOf property to reference the abovementioned base observation capability description through a resolvable link and add the new observation capability properties that are specific to this particular sensor, as well as the actual sensor dynamic trajectory in the given temporal condition.

Therefore, based on the well-defined observation capability metadata properties, our proposed metadata model can contribute to the extension of the SensorML 2.0 profile for describing observation capabilities, which has the following advantages: (1) from the perspective of the uncertainty of the metadata properties, it provides well-defined rules for determining which observation capabilities need to be described in a particular structure; and (2) from the description framework perspective, the inheritance and configuration features of SensorML 2.0 enable more effective applications of the proposed metadata model, i.e., avoiding a verbose and repetitive modeling process, enabling the most compact description of a particular sensor and providing the fine-grained observation capabilities for deepened observation discovery.

6. Conclusions and Future Work

This study introduces a metadata model that represents the well-defined observation capability information of EO sensors. Five sub-modules of observation capability metadata are illustrated and developed based on different EO sensor types. The proposed metadata model is applied in sensor discovery during an actual observation task. The results confirm that the proposed metadata model can function as a standard and minimum uniform observation capability information descriptor for accurate sensor discovery. Furthermore, the proposed model can serve as an indicator that represents the most relevant observation capability information to assist emergency managers in planning collaborative observation solutions. In addition, the proposed model can aid in the extension of the SensorML 2.0 profile for the description of the observation capabilities of EO sensors.

From the perspective of technology, future works related to this study include development of an EO non-imagery sensor observation capability metadata model based on this research and integration with semantic sensor discovery. From the perspective of standardizing and extending the application of our proposed model, our next steps include creation of standard online dictionaries or ontologies of the proposed observation capability terminology, formulation of the implementation schema for the proposed EO sensor observation capability metadata model in SensorML 2.0 and submission of this proposed metadata model to the relevant standardization communities.