An Object Model for Integrating Diverse Remote Sensing Satellite Sensors: A Case Study of Union Operation

Abstract

In the Earth Observation sensor web environment, the rapid, accurate, and unified discovery of diverse remote sensing satellite sensors, and their association to yield an integrated solution for a comprehensive response to specific emergency tasks pose considerable challenges. In this study, we propose a remote sensing satellite sensor object model, based on the object-oriented paradigm and the Open Geospatial Consortium Sensor Model Language. The proposed model comprises a set of sensor resource objects. Each object consists of identification, state of resource attribute, and resource method. We implement the proposed attribute state description by applying it to different remote sensors. A real application, involving the observation of floods at the Yangtze River in China, is undertaken. Results indicate that the sensor inquirer can accurately discover qualified satellite sensors in an accurate and unified manner. By implementing the proposed union operation among the retrieved sensors, the inquirer can further determine how the selected sensors can collaboratively complete a specific observation requirement. Therefore, the proposed model provides a reliable foundation for sharing and integrating multiple remote sensing satellite sensors and their observations.

1. Introduction

According to the US National Aeronautics and Space Administration (NASA), approximately 3,000 satellites, equipped with various heterogeneous sensors, are operating in Earth’s orbit [36]. With the increasing complexity of Earth Observation (EO) missions, a single sensor cannot effectively conform to these observation requirements, thereby necessitating the collaboration of a number of other sensors to yield a meaningful output [1]. The challenge of advanced EO systems is not to launch as many satellite sensors as possible, but the rational and comprehensive use of available sensors to provide efficient application support to certain complex observation tasks. Considering the heterogeneity of remote sensing satellite sensors, obtaining an integrated solution for accomplishing specific emergency tasks is difficult by the rapid, accurate, and uniform discovery of satisfactory sensors that can be reliably associated. The integration of remote sensing satellite sensors [2], which can be defined as the unified sharing of observation information provided by satellite sensors, and the synergistic use of multiple sensors for assistance in task accomplishments, is necessary [3].

With regard to sensor network environments, considerable attention has been paid in managing heterogeneous sensors [4–6]. However, these achievements primarily emphasize the bottom-level access, control, and planning of distributed and standalone sensors rather than the integration of mutually isolated sensors via the World Wide Web. Several studies [7,8] have encompassed different aspects of data integration from remote sensing satellite sensors; however, the integration of remote sensors has not been investigated. The Sensor Web Enablement (SWE) initiative developed by the Open Geospatial Consortium (OGC) defines a standard framework that aims to enable the interoperable use of sensor resources [9]. Di [10] demonstrates that all distributed or traditional standalone EO sensors will be converted to web-accessible sensors by complying with SWE interfaces and information standards. Blaschke et al. [11] conclude that the adoption of OGC sensor web technology can holistically integrate urban sensors. Sensor Model Language (SensorML) [12] is an SWE information standard that provides a flexible and general framework for describing sensor information. Sensor information [13] is the representation of an actual sensor and describes the physical characteristics of a sensor, the limitations posed by the environment on a sensor, and the performance of a sensor. The study [37] introduces a framework for web-based sensor discovery, wherein SensorML is adopted as the model for describing sensor information. SensorML-based information description frameworks have been used in various applications [3], such as the EU directive INSPIRE ( http://www.ec-gis.org/inspire/), EU-funded projects SANY ( http://sany-ip.eu) and OSIRIS ( http://www.osiris-fp6.eu), South Africa AFIS project [38], and US OOSTethys community project ( http://www.oostethys.org). Foerster et al. [14] state that integrating the sensor information into sensor web environments assists in accessing deployed sensors. Di [15] explains that the “availability of metadata for the Sensor Web can be very useful in discovery of the right sensor at right time and location with the right quality, and to achieve sensor interoperation.” However, current SensorML-based sensor information description frameworks do not consider unified metadata elements; therefore, such frameworks cannot completely satisfy the requirement for sharing and interoperating sensors and their observations [16,35]. Simply defining the sensor information description framework is insufficient in facilitating the unified discovery and integration of multiple sensors [17]. Our recent study [16] preliminarily analyzes the metadata requirements for sharing atmospheric satellite sensors and their observations and defines an eight-tuple metadata composition. However, the classification of satellite sensors is not considered.

Process and object-oriented programming techniques are two distinct programming paradigms for establishing a computer-readable model of the real world. These two programming paradigms have been studied extensively with regard to software architecture and computer programming [18,19]. Process-oriented programming emphasizes function-centric applications, whereas object-oriented programming focuses on object-centric modeling [20]. In sensor system modeling, available sensor description standards [29], such as IEEE 1451, ECHONET, Device Description Language (DDL), and Device Kit, tend to be applied in function-centric scenarios. IEEE 1451 is mainly used to define communication and network interfaces. ECHONET acts as an adapter for the networking and configuration of home devices. DDL follows a cross-layer design and focuses only on device interfacing. Device Kit provides a common interface for application codes to promote interaction with RFID readers and other device sensors and actuators. The above-mentioned standards provide certain functional representations for sensor systems; however, the reusability of these standards is poor as such standards are intended for function-specific applications. Compared with the process-oriented approach, the object-oriented approach chiefly relies on its closeness to the natural view of the real world. Object-oriented analysis uses properties and methods that are present in an object as the basic unit of the object-oriented model. In addition to saving the local state of information, the object-oriented approach can also perform operations on different objects. The properties and methods or the operations of an object are defined by a class [21]. The essential characteristics of the object-oriented approach include information hiding, encapsulation, and inheritance. By increasing the level of abstraction from the function level to the object level, the object-oriented model focuses on the real-world aspects and linkages of a system, thereby, providing a mapping relationship from real-world objects to model objects [22]. The object-oriented approach views the real world as a system with mutually cooperating objects. Bordogna et al. [23] state that the object-oriented paradigm for modeling applications has emerged in several fields such as computer-aided design, water catchment management, and geographic information systems. It is noteworthy that the object-oriented approach has also been applied to sensor systems, limited to sensor data integration [1], sensor process descriptions [12], sensor failure modes [25], sensor geolocation [26], and home-appliance-specific sensor networking [24,27]. However, studies implementing the object-oriented approaches in sensor modeling that are capable of integrating multiple remote sensors cannot be found in literature.

Satellite sensors differ in several aspects, such as sensor observation principle, intended application, and sensor information representation. The current problems involved in satellite sensors are as follows [9,28]: (1) the resources of a remote sensing satellite sensor are abundant but few resources are available or can be appropriately planned for a specific task; and (2) the effective integration of these diverse satellite sensors for collaborated observation is absent. In the current study, we propose an object model for the integration of diverse remote sensing satellite sensors, based on the object-oriented paradigm and the SWE standard information description framework. This paper begins with the Unified Modeling Language class diagram to show the object-oriented aspect of the proposed object model. Next, we analyze the meta-attribute description of different satellite sensors. Thereafter, the operations of sensor resource objects have been illustrated. Then, we illustrate the union operation, including its definition and algorithm design. Finally, the different information instances of resource attribute states are demonstrated. The union operation among satellite sensor resource objects is implemented. The proposed model has the following contributions: (1) performs as a standard descriptor for the logical unification of isolated satellite sensors, thus, enabling sensor discovery; and (2) acts as an indicator that assists the decision maker to formulate a sensor collaboration solution for a specific observation task.

2. Object Model of Remote Sensing Satellite Sensors

2.1. Conceptual Level of the Proposed Object Model

In this study, the proposed model considers each remote sensing satellite sensor as an independent object acting as a source that can collaborate with other sensor resource objects.

Figure 1 illustrates the conceptual level of the model by the basic notions of the object-oriented approach [31], which includes associations, compositions, and specializations. The sensor Object Models (OM_s) is a set of Sensor Resource Objects (SRO). We can express OM_s by using the following mathematical expression:

$${\text{OM}}_{\text{s}}=\{{\text{SRO}}_1,\hspace{0.17em}{\text{SRO}}_2,\dots ,{\text{SRO}}_{\text{n}}\}$$

(1)

Each SRO represents a specialized sensor type. On the basis of the sensor characteristics [12], a sensor system can either perform the measurement in situ or remotely. We define In situ Sensor and Remote Sensor as two subclasses of the SRO class to ensure the comprehensiveness and versatility of the model (Figure 1). Our study mainly focuses on the Remote Sensor subclass. According to the classification of sources that enable the remote sensing of images in ISO 19130 [26] and 19130-2 standards [32], a Remote Sensor type can be specialized into the following classes: frame camera, film camera, pushbroom sensor, whiskbroom sensor, Synthetic Aperture Radar (SAR), and Light Detection and Ranging (LiDAR). These remote sensors can be further classified into three categories, namely, camera sensor, scanner sensor, and radar sensor.

Each concrete SRO instance encapsulates three basic elements: Sensor Identification (SensorID), Resource Attribute (RA), and Resource Method (RM), which can be expressed as that in Equation (2):

$$\text{SRO}=\{\text{SensorID},\hspace{0.17em}\text{RA},\hspace{0.17em}\text{RM}\}$$

(2)

where SensorID denotes the unique identification of the SRO, RA is a set of attribute state descriptions of the SRO, and RM is a set of methods of the SRO, wherein, the object relation operations are encapsulated.

Each concrete SRO instance has a unique RA. By using the SensorML framework as the reference [28], the RA equation can be expressed as follows:

$${\text{RA}}_{\text{i}}=\{{\text{MD}}_{\text{i}}\}\hspace{0.17em}\hspace{0.17em}(\text{i}=1,\hspace{0.17em}2,\hspace{0.17em}\dots \text{n})$$

(3)

where MD_i is the metadata set of the concrete SRO. To assist integrators and analysts in obtaining a better understanding of the EO sensor system [13], our previous study [16] preliminarily analyzes the metadata requirements for sharing atmospheric satellite sensors and their observations, and MD_i is defined as an eight-tuple composition:

$${\text{MD}}_{\text{i}}=\{{\text{MD}}_{\text{i}}^{\text{G}},\hspace{0.17em}{\text{MD}}_{\text{i}}^{\text{C}},\hspace{0.17em}{\text{MD}}_{\text{i}}^{\text{CT}},\hspace{0.17em}{\text{MD}}_{\text{i}}^{\text{CP}},\hspace{0.17em}{\text{MD}}_{\text{i}}^{\text{R}},\hspace{0.17em}{\text{MD}}_{\text{i}}^{\text{ST}},\hspace{0.17em}{\text{MD}}_{\text{i}}^{\text{GP}},\hspace{0.17em}{\text{MD}}_{\text{i}}^{\text{I}}\}\hspace{0.17em}\hspace{0.17em}(\text{i}=1,\hspace{0.17em}2,\hspace{0.17em}\dots \text{n})$$

(4)

where ${\text{MD}}_{\text{i}}^{\text{G}}$ is the general metadata group, ${\text{MD}}_{\text{i}}^{\text{C}}$ is the constraint metadata group, ${\text{MD}}_{\text{i}}^{\text{CT}}$ is the characteristic metadata group, ${\text{MD}}_{\text{i}}^{\text{CP}}$ is the capability metadata group, ${\text{MD}}_{\text{i}}^{\text{R}}$ is the reference metadata group, ${\text{MD}}_{\text{i}}^{\text{ST}}$ is the spatial-temporal metadata group, ${\text{MD}}_{\text{i}}^{\text{GP}}$ is the geoposition metadata group, and ${\text{MD}}_{\text{i}}^{\text{I}}$ is the interface metadata group. Each metadata group belongs to the enumerated type, and the detailed elements are described in Section 2.2.

The associated operations refer to relations between two or more external Sensor Resource Objects (SROs), including union, intersection, difference, product, and join. The metadata elements of the RA act as independent variables in these operations.

By referring to the above illustration, the remote sensing satellite sensor Object Model (OM_rs) can be defined as a set of remote sensing SROs (SROs_rs). The SRO_rs can be expressed as follows:

$$\text{SRO}\_\text{rs}=\{\text{SensorID},\hspace{0.17em}\text{RA}\_\text{rs},\hspace{0.17em}\text{RM}\_\text{rs}\}$$

(5)

The remote sensor Resource Attribute (RA_rs) and remote sensor Resource Method (RM_rs) are described in detail in Sections 2.2 and 2.3, respectively.

2.2. Remote Sensor Resource Attribute of SRO_rs

In this section, we determine the elements of the RA_rs of SRO_rs. We adopt SensorML as the carrier to describe the attribute information of SRO_rs. SensorML provides only the description framework rather than the explicit and unified metadata elements for sharing and interoperating sensors. On the basis of SensorML, we [16] further analyze and define the metadata elements of atmospheric satellite sensors, where ${\text{MD}}_{\text{i}}^{\text{G}}$ includes attributes such as keyword, sensor type, sensor name, sensor_associated_platform, platform type, platformID, and platform name. ${\text{MD}}_{\text{i}}^{\text{C}}$ includes the sensor observation validity time and sharing levels of sensor and responsible centers. ${\text{MD}}_{\text{i}}^{\text{CT}}$ includes mobility, measures, height, mass, power, and dimension. ${\text{MD}}_{\text{i}}^{\text{R}}$ includes the URLs of the sensor’s online resources. ${\text{MD}}_{\text{i}}^{\text{I}}$ mainly includes the web service interface used to access the sensors and related observations. ${\text{MD}}_{\text{i}}^{\text{ST}}$ and ${\text{MD}}_{\text{i}}^{\text{GP}}$ mainly contain the parameters used to determine the satellites’ dynamic trajectory. ${\text{MD}}_{\text{i}}^{\text{CP}}$ considers the coarse-grained aspects of spatial, temporal, and spectral resolutions. All these elements have been reused from existing geospatial and sensor-related metadata standards [15,30] or have been newly extended to enable the sharing and interoperation of satellite sensors. However, we have not distinguished the fine-grained observation capabilities of each type of remote sensing satellite sensor.

The above analysis show that the description of the RA_rs of SRO_rs complies with the description of MD_i (Section 2.1), and the fine-grained attribute elements of the seven metadata groups, namely, ${\text{MD}}_{\text{i}}^{\text{G}}$, ${\text{MD}}_{\text{i}}^{\text{C}}$, ${\text{MD}}_{\text{i}}^{\text{CT}}$, ${\text{MD}}_{\text{i}}^{\text{R}}$, ${\text{MD}}_{\text{i}}^{\text{I}}$, ${\text{MD}}_{\text{i}}^{\text{ST}}$, and ${\text{MD}}_{\text{i}}^{\text{GP}}$, can be completely obtained from the above (

Table 1. Seven metadata groups’ attributes of remote sensing satellite sensors.

Metadata Group	Main attribute State Elements
${\text{MD}}_{\text{i}}^{\text{G}}$	keyword, sensor ID, sensor type, sensor name, sensor_associated_platform, platform type, platformID, platform name, Sensor_associated_application
${\text{MD}}_{\text{i}}^{\text{C}}$	sensor observation valid time, sharing level of sensor, responsible center,
${\text{MD}}_{\text{i}}^{\text{CT}}$	mobility, measures, height, mass, power, dimension,
${\text{MD}}_{\text{i}}^{\text{R}}$	Sensor online resources’ URL
${\text{MD}}_{\text{i}}^{\text{I}}$	Web service interface
${\text{MD}}_{\text{i}}^{\text{ST}}$	PlatformCRS, SensorCRS
${\text{MD}}_{\text{i}}^{\text{GP}}$	PlatformOribt, platformDynamics

). However, ${\text{MD}}_{\text{i}}^{\text{CP}}$ needs to be thoroughly refined depending on the specified type of remote sensor. Each type of remote sensor has its basic observation capabilities: band name, band_associated_application, spectral range, ground resolution, and so on. With regard to the remote imagery sensors, the geographic location of the dynamic sensor observations is a fundamental processing step before the acquired data become useful. Therefore, on the basis of the elements used to determine the satellites’ dynamic trajectory in ${\text{MD}}_{\text{i}}^{\text{ST}}$ and ${\text{MD}}_{\text{i}}^{\text{GP}}$, the attributes used for geolocation, such as field of view (FOV), swath width, and side swing angle, are important capability indices in ${\text{MD}}_{\text{i}}^{\text{CP}}$. The ISO 19130 series describes a physical sensor model that enables users to determine the geographical location of dynamic sensor observations, that is, the attributes for geolocation can be extracted from the “SD_Geolocation Information” in the ISO 19130 series [26,32]. For example, the ${\text{MD}}_{\text{i}}^{\text{CP}}$ of the whiskbroom sensor includes row spacing, focal length, and FOV, which can be obtained from the whiskbroom sensor metadata profile of the ISO 19130 standard [39]. On the contrary, the SAR contains a unique collection: polarization mode and operating frequency, which is referenced from the SAR metadata profile of the ISO 19130-2 standard [40].

Table 2. ${\text{MD}}_{\text{i}}^{\text{CP}}$ for a specific type of remote sensing satellite sensors.

		Sensor Capabilities	Basic Observation	Observation Geolocation (from ISO 19130 Series)
Sensor Type		MD Group
Camera Sensor	frame	${\text{MD}}_{\text{i}}^{\text{CP}}$	Band(s)Name, Band(s)Width, GroundResolution, Band(s)AssociatedApplication, NumberOfSpectralBand, GroundResolutionRange, SpectralRange, TemporalResolution RadiometricAccuracy	Sensor Rotation About X/Y/Z-axis, Sensor Focal Length, Column Spacing, Row Spacing, Various distortions
	film			NO developing in 19130 series
Scanner Sensor	Pushbroom	${\text{MD}}_{\text{i}}^{\text{CP}}$	Band(s)Name, Band(s)Width, GroundResolution, Band(s)AssociatedApplication, NumberOfSpectralBand, GroundResolutionRange, SpectralRange, TemporalResolution RadiometricAccuracy	Row Spacing, Collection Start/Stop Time, Sensor Focal Length, FOV, IFOV, Maximum Scan Angle, Pushbroom scan duration, Whiskbroom scan duration, Whiskbroom pixel scan duration, SwathWidth, CanSideSwing, SideSwingAngle, platform Roll, Pitch, yaw
	whiskbroom
Radar Sensor	SAR	${\text{MD}}_{\text{i}}^{\text{CP}}$	Mode(s)Name, IncidentAngle, RangeResolution, AzimuthResolution, NumberOfMode, MicrowaveFrequency, PolarizationBand, GroundResolutionRange, TemporalResolution RadiometricAccuracy	SwathWidthRange Line spacing, Sample spacing, Output plane unit vectors, Scene center point (SCP), Scene center point line/sample, Antenna Reference Point (ARP), Position-Velocity Correlation Coefficient, Position-Velocity Decorrelation Rate
	LiDAR			NO developing in 19130 series

shows the details of ${\text{MD}}_{\text{i}}^{\text{CP}}$ for a specific type of remote sensor.

2.3. Remote Sensor Resource Operations

The different SRO_rs instances can exhibit homogeneity and heterogeneity.

Table 3. Logical structure of remote sensing sensor resource object.

SRO_rs
SensorID	RA_rs					RM_rs
SensorID	MDi					Union (MDi)	Intersection (MDi)	Difference (MDi)	Product (MDi)	Join (MDi)
UniqueIDi	A_1	A_2	A_3	…	A_n

A_1 is the first attribute of the metadata node MD_i. A_n represents the N^th meta-attribute. Every SRO_rs has a unique ID and has five operations associated with other SRO_rs instances.

lists the logical structure of the proposed SRO_rs.

Table 4. Earth Observation (EO) sensor classification and analysis of different meta-attribute elements.

Types	Classification perspective	Classification Value		Instructions about the difference of the meta-attribute
Traditional EO	PlatformHeight	Space		The orbit, dynamic observed boundingbox attributes of space/aviation sensor do not exist in ground sensor And so on
		Aviation
		ground
OGC Sensor Model Language	Mobility	Fixed		Velocity of mobile platform does not exist in fixed platform The polarization mode and operating frequency attribute of active sensors does not exist in passive sensors And so on
		Mobile
	Measures	In-situ
		Remote	active
			passive

shows two types of classifications of EO sensors: traditional and OGC SensorML-recognized classifications. Different sensor objects may have different meta-attributes, whereas all types of SRO_rs instances maintain five associated operations. Therefore, the logical structure of SRO_rs (Table 3) varies depending on the differing collections of MD_i.

As mentioned above, this study reveals that satellite sensors that have the same meta-attribute node collections {A_1, A_2, …, A_n} satisfy the following mathematical proposition: {“Is_Same_PlatformHeightType” = Yes ∧ “Is_Same_Mobility” = Yes ∧ “Is_Same_Measures” = Yes}; such satellite sensors are considered homogenous. Otherwise, sensors that do not have the same meta-attribute nodes are classified as heterogeneous.

We assume that the proposed OM_rs contains two SRO_rs instances: SRO₁_rs and SRO₂_rs. SRO′_rs represents the new virtual sensor object [33,34] obtained after performing certain types of relation algebraic operations, such as union, intersection, difference, product, and join. Similar to the metadata attribute set illustrated in the preceding section, homogeneous sensors are described to have the same meta-attribute collections {A_1, A_2, …, A_n}, and the number of meta-attribute columns is n. However, the description of heterogeneous sensor RAs differs in terms of the elements or columns of the meta-attributes. Tang et al. [29] state that union, intersection, and difference operations can only be undertaken within the homogeneous sets of two object spaces, i.e., these operations can only be applied in homogeneous SRO_rs instances. By contrast, the product and join operations can be performed between heterogeneous SRO_rs instances with differing meta-attribute columns.

For homogeneous SRO_rs instances, the included operations can be expressed as follows:

• SRO'_rs = SRO₁_rs ∪ SRO₂_rs ≡ {t | t ∈ SRO₁_rs ∨ t ∈ SRO₂_rs}, where t is the meta-attribute variable of SRO′_rs. This operation is the union between two SRO_rs instances. SRO′_rs is the new SRO_rs that contains the comprehensive sensor observing capacity of SRO₁_rs and SRO₂_rs.
• SRO'_rs = SRO₁_rs ∩ SRO₂_rs ≡ {t | t ∈ SRO₁_rs ∧ t ∈ SRO₂_rs}, where t is the meta-attribute variable of SRO'_rs. This operation is the intersection between the two SRO_rs instances. SRO'_rs is the current new SRO_rs having commonality between SRO₁_rs and SRO₂_rs.
• SRO'_rs = SRO₁_rs − SRO₂_rs ≡ {t | t ∈ SRO₁_rs ∧ t ∉ SRO₂_rs}, where t is the meta-attribute variable of SRO'_rs. This operation is the difference between the two SRO_rs instances. SRO'_rs is the current new SRO_rs having sensor observation system meta-attributes that are present in SRO₁_rs but not in SRO₂_rs.

For heterogeneous SRO_rs instances, the included operations are as follows:

• SRO'_rs = SRO₁_rs × SRO₂_rs ≡ {t | t = <t1, t2> ∧ t1 ∈ SRO₁_rs ∧ t2 ∈ SRO₂_rs}, where t1 and t2 are the meta-attribute variables of SRO'_rs. We assume that SRO₁_rs has n-ary meta-attribute columns, and SRO₂_rs has m-ary meta-attribute columns. This operation is the product of the two SRO_rs instances. SRO'_rs is the new SRO_rs wherein the first n-ary meta-attribute columns are the meta-attributes of SRO₁_rs, and the succeeding m-ary meta-attribute columns are the meta-attributes of SRO₂_rs.
• SRO'_rs = SRO₁_rs ⋈ SRO₂_rs ≡ {t | t = <t₁, t₂> ∧ t₁ ∈ SRO₁_rs ∧ t₂ ∈ SRO₂_rs ∧ t₁ [B] = t₂[B]}, where t1 and t2 are the meta-attribute variables of SRO'_rs. SRO₁_rs and SRO₂_rs have the same meta-attribute column $\text{B}=M{\text{D}}_1^{A\text{i}}=M{\text{D}}_2^{Ak}$, i.e., B is the common meta-attribute of these two SRO_rs instances and denotes the natural join operation derived from the product operation. SRO'_rs is the current new sensor resource object wherein the common/repeated meta-attribute column has been deleted. If the repeated meta-attributes have s (integer) columns, the first n-ary meta-attribute columns in SRO'_rs are the meta-meta-attributes of SRO₁_rs. The succeeding (m-s)-ary meta-attribute columns are the meta-attributes of SRO₂_rs.

2.4. Union Operation Algorithm Design

Although five operations (union, intersection, difference, product, and join) have been designed in the proposed model, this study mainly investigates and illustrates the union operation because this operation plays the most basic and important role in determining whether one SRO can collaborate with other SROs under a specific observation task.

When the physical sensor observation system is encapsulated into the proposed RA, the on-demand selection of the related operations inside the RM can be achieved, which can be applied between different SROs. For two homogeneous SRO_rs instances (i.e., SRO₁_rs and SRO₂_rs), SRO'_rs represents the new virtual sensor object produced after the union operation is performed. SRO'_rs possesses a more comprehensive sensor observing capacity than SRO₁_rs and SRO₂_rs. The following algorithms enumerate the union operation performed between SRO₁_rs and SRO₂_rs.

In the second line of Algorithm 1, Algorithm 2 is initiated to compare whether the two SRO_rs instances are homogeneous. Algorithm 2 comprises three steps.

The first step determines whether the two SRO_rs instances have an equal number of unrepeated meta-attribute nodes. The mentioned Compare() function has nine overloading types divided into three categories.

Compare(s1,s2) is the first category (entire Algorithm 2). Compare( ${\mathit{MD}}_1^x$.Instance, ${\mathit{MD}}_2^x$.Instance) (lines 5 to 16 of Algorithm 2), where ${\text{MD}}_{\text{i}}^{\text{x}}$ is either { ${\text{MD}}_{\text{i}}^{\text{G}}$, ${\text{MD}}_{\text{i}}^{\text{C}}$, ${\text{MD}}_{\text{i}}^{\text{CP}}$, ${\text{MD}}_{\text{i}}^{\text{R}}$, ${\text{MD}}_{\text{i}}^{\text{ST}}$, ${\text{MD}}_{\text{i}}^{\text{GP}}$, or ${\text{MD}}_{\text{i}}^{\text{I}}$}, is the second category that returns a “true” value if the struct members of the nodes in ${\text{MD}}_1^{\text{x}}$. Instance and ${\text{MD}}_2^{\text{x}}$.Instance are equal. The third category is Compare( ${\mathit{MD}}_1^{CT}$.Instance, ${\mathit{MD}}_2^{CT}$.Instance) ( ${\text{MD}}_{\text{i}}^{\text{x}}$ is ${\text{MD}}_{\text{i}}^{\text{CT}}$) (lines 17 to 20 of Algorithm 2), which is based on the second category, and additionally determines whether the specified three values are equal in two objects.

In this context, the second step executes the Compare() function of the second category. The final step is to perform the third type of Compare() function. If a “true” value is obtained, the two SRO_rs instances are homogeneous. Thereafter, the union process begins from the third line of Algorithm 1, where lines 5 to 11 are the core function of the union operation.

Algorithm 1:. Union algorithm of two remote sensor resource objects SRO_rs instances

Input: remote sensor attribute state description s1 (RA1_rs) of SRO1_rs       remote sensor attribute state description s2 (RA2_rs) of SROs_rs   Output: new sensor description s' (RA'_rs) of remote sensor resource object SRO'_rs   Use: compare(s1,s2) returns true if SRO'_rs and SRO'_rs are homogenous sensor type     addAttr(s1.MDx Instance, s2.MDx Instance) performs the combination of two equal meta-attribute nodes     reassign (ID) returns the new unique ID to s'   Declare: SensorObjectInFormsOfSensorAttributeStateDescription s1, s2, s';    MDx struct MDx Instance;   Begin: Union 1: If (s1!= empty && s2!= empty) do 2: Judge whether two sensors are the homogenous type using compare algorithm 3: If compare(s1,s2) then 4: { reassign (ID); 5: Foreach (MDx in {MDG, MDC, MDCT, MDCP, MDR, MDST, MDGP, MDI}) do 6: Logically merge the equal meta-attribute node and its value of two raw SRO_rs instances into s'; 7: i.e., s'. MDCT Instance = addAttr(s1. MDCT Instance, s2. MDCT Instance) do 8: {s'. MDCT Instance.Band(s)Resolution = s1. MDCT Instance.Band(s)Resolution + s2. MDCT Instance.Band(s)Resolution;       s'. MDCT Instance.Band(s) MainApplication = s1. MDCT Instance.Band(s) MainApplication +       s2. MDCT Instance.Band(s)MainApplication ; 9: {then, the same way to combine the other elements inside MDx Instance}} 10: In all, {s'. MDx Instance = addAttr(s1. MDx Instance, s2. MDx Instance)}; 11: } 12: End If 13: Return s' 14: End If End Union

Algorithm 1:. Union algorithm of two remote sensor resource objects SRO_rs instances

Input: remote sensor attribute state description s1 (RA1_rs) of SRO1_rs       remote sensor attribute state description s2 (RA2_rs) of SROs_rs   Output: new sensor description s' (RA'_rs) of remote sensor resource object SRO'_rs   Use: compare(s1,s2) returns true if SRO'_rs and SRO'_rs are homogenous sensor type     addAttr(s1.MDx Instance, s2.MDx Instance) performs the combination of two equal meta-attribute nodes     reassign (ID) returns the new unique ID to s'   Declare: SensorObjectInFormsOfSensorAttributeStateDescription s1, s2, s';    MDx struct MDx Instance;   Begin: Union 1: If (s1!= empty && s2!= empty) do 2: Judge whether two sensors are the homogenous type using compare algorithm 3: If compare(s1,s2) then 4: { reassign (ID); 5: Foreach (MDx in {MDG, MDC, MDCT, MDCP, MDR, MDST, MDGP, MDI}) do 6: Logically merge the equal meta-attribute node and its value of two raw SRO_rs instances into s'; 7: i.e., s'. MDCT Instance = addAttr(s1. MDCT Instance, s2. MDCT Instance) do 8: {s'. MDCT Instance.Band(s)Resolution = s1. MDCT Instance.Band(s)Resolution + s2. MDCT Instance.Band(s)Resolution;       s'. MDCT Instance.Band(s) MainApplication = s1. MDCT Instance.Band(s) MainApplication +       s2. MDCT Instance.Band(s)MainApplication ; 9: {then, the same way to combine the other elements inside MDx Instance}} 10: In all, {s'. MDx Instance = addAttr(s1. MDx Instance, s2. MDx Instance)}; 11: } 12: End If 13: Return s' 14: End If End Union

Algorithm 2:. Compare algorithm of two remote sensor resource objects SRO_rs instances

Input: the same with Union algorithm   Output: the Boolean value returned by Compare(s1,s2) function   Use: StatisticAttributeCount(s) returns the count of unrepeated meta-attribute nodes   StatisticAttributeValue(s) returns the values of meta-attribute nodes   Compare(MDx struct${\mathit{MD}}_1^x$.Instance MDx struct${\mathit{MD}}_2^x$.Instance) is elaborated in the later   Declare: static int N= 0; int M=0;   Struct MDx struct; MDG struct MDG Instance;       MDG Instance.UniqueID = “NAN”; MDG Instance.SensorType = “NAN”; …   Begin: Compare 1: Initialize two remote sensor objects in forms of RA_rs, including account the number of unrepeated meta-attribute nodes and read the value of each node. Do 2: N= StatisticAttributeCount(s1) ; M=StatisticAttributeCount(s2); 3: StatisticAttributeValue(s1) ; StatisticAttributeValue(s1) ; 4: If (N=M) then 5: {{Foreach (MDx in {MDG, MDC, MDCP, MDR, MDST, MDGP, MDI}) do 6: Compare whether each meta-attribute node of s1 has the equal node in s2. 7: i.e., Compare(s1.MDG Instance, s2.MDG Instance) do 8: { bool flag1, flag2; 9: flag1 = (s1.MDG Instance. UniqueID == “NAN”); 10: flag2 = (s2.MDG Instance. UniqueID == “NAN”); 11: if (!(flag1 && flag2)) return false; 12: flag1 = (s1.MDG Instance. SensorType == “NAN”); 13: flag2 = (s2.MDG Instance. SensorType == “NAN”); 14: if (!(flag1 && flag2)) return false; 15: {the determination of the other elements inside MDG Instance is the same way as above} 16: Return true;}     } 17: When MDx ==MDCT, the Compare(s1.MDCT Instance, s2.MDCT Instance) function, in addition to perform the similar       steps of above compare() function, it has the following determination: 18: {If((s1. MDCT Instance.PlatformHeight == s2.MDCT Instance.PlatformHeight) &&         (s1. MDCT Instance.Ismobile == s2.MDCT Instance. Ismobile) &&          (s1. MDCT Instance. Measures == s2.MDCT Instance. Measures)), Return true; 19: Else { s1 and s2 are the heterogeneous sensor type, compare(s1,s2)==false }, Return false;; 20: End if} 21: In all, foreach(MDx in {MDG, MDC, MDCT, MDCP, MDR, MDST, MDGP, MDI}) do     If (Compare(s1.MDx Instance, s2.MDx Instance)) Return true; 22: Else { s1 and s2 are the heterogeneous sensor type, compare(s1,s2)==false }, Return false;; 23: End If 24: } 25: Else { s1 and s2 are the heterogeneous sensor type, compare(s1,s2)==false }, Return false; 26: End If End Compare

Algorithm 2:. Compare algorithm of two remote sensor resource objects SRO_rs instances

Input: the same with Union algorithm   Output: the Boolean value returned by Compare(s1,s2) function   Use: StatisticAttributeCount(s) returns the count of unrepeated meta-attribute nodes   StatisticAttributeValue(s) returns the values of meta-attribute nodes   Compare(MDx struct${\mathit{MD}}_1^x$.Instance MDx struct${\mathit{MD}}_2^x$.Instance) is elaborated in the later   Declare: static int N= 0; int M=0;   Struct MDx struct; MDG struct MDG Instance;       MDG Instance.UniqueID = “NAN”; MDG Instance.SensorType = “NAN”; …   Begin: Compare 1: Initialize two remote sensor objects in forms of RA_rs, including account the number of unrepeated meta-attribute nodes and read the value of each node. Do 2: N= StatisticAttributeCount(s1) ; M=StatisticAttributeCount(s2); 3: StatisticAttributeValue(s1) ; StatisticAttributeValue(s1) ; 4: If (N=M) then 5: {{Foreach (MDx in {MDG, MDC, MDCP, MDR, MDST, MDGP, MDI}) do 6: Compare whether each meta-attribute node of s1 has the equal node in s2. 7: i.e., Compare(s1.MDG Instance, s2.MDG Instance) do 8: { bool flag1, flag2; 9: flag1 = (s1.MDG Instance. UniqueID == “NAN”); 10: flag2 = (s2.MDG Instance. UniqueID == “NAN”); 11: if (!(flag1 && flag2)) return false; 12: flag1 = (s1.MDG Instance. SensorType == “NAN”); 13: flag2 = (s2.MDG Instance. SensorType == “NAN”); 14: if (!(flag1 && flag2)) return false; 15: {the determination of the other elements inside MDG Instance is the same way as above} 16: Return true;}     } 17: When MDx ==MDCT, the Compare(s1.MDCT Instance, s2.MDCT Instance) function, in addition to perform the similar       steps of above compare() function, it has the following determination: 18: {If((s1. MDCT Instance.PlatformHeight == s2.MDCT Instance.PlatformHeight) &&         (s1. MDCT Instance.Ismobile == s2.MDCT Instance. Ismobile) &&          (s1. MDCT Instance. Measures == s2.MDCT Instance. Measures)), Return true; 19: Else { s1 and s2 are the heterogeneous sensor type, compare(s1,s2)==false }, Return false;; 20: End if} 21: In all, foreach(MDx in {MDG, MDC, MDCT, MDCP, MDR, MDST, MDGP, MDI}) do     If (Compare(s1.MDx Instance, s2.MDx Instance)) Return true; 22: Else { s1 and s2 are the heterogeneous sensor type, compare(s1,s2)==false }, Return false;; 23: End If 24: } 25: Else { s1 and s2 are the heterogeneous sensor type, compare(s1,s2)==false }, Return false; 26: End If End Compare

3. Instances and Applications

3.1. Scanner SRO_rs Attribute State Information Instance

The Moderate Resolution Imaging Spectroradiometer (MODIS) onboard the AQUA satellite is a pushbroom-type scanner sensor, which plays an important role in EO missions. The object “SensorID” has the meta-attribute “UniqueID” with the value urn:ogc:feature:remotesensor:MODIS_Aqua (Figure 2). In conformity with the attribute description of SRO_rs analyzed in Section 2, AQUA_MODIS SRO_rs should contain the following attribute elements: sensor name, sensor type, resolution, physical quality, application, contact, coordinate reference system, and so on. Each object inside the eight-tuple metadata group enumerates the meta-attributes. For example, the meta-attributes of ${\text{MD}}_{\text{i}}^{\text{CP}}$ have the following enumerated list.

• Object subclass Capability ( ${\mathit{MD}}_i^{\mathit{CP}}$)
• Instance Variables:

  • Spectral band (set of ordered pairs of “string-integer”)
  • Spectral range (double)
  • Ground resolution (integer)
  • Temporal resolution (integer)
  • Band_associated_application (set of ordered pairs of “string-string”)
  • ………

We adopt SensorML as the carrier to represent the above meta-attributes of the AQUA_MODIS SRO_rs. Figure 3 shows the RA_rs fragment of the AQUA_MODIS SRO_rs.

3.2. Radar SRO_rs Attribute State Information Instance

SAR is a microwave instrument that sends pulsed signals to Earth and processes the received reflected pulses. This type of sensor is referred to as a radar sensor. In this study, we consider “RADARSAT-2_SAR” as an example. The SAR onboard RADARSAT-2 is an advanced EO satellite project developed by the Canadian Space Agency and MacDonald, Dettwiler, and Associates Ltd. to monitor environmental changes and support resource sustainability. The platform height of the “RADARSAT-2_SAR” observing system is 798 km; this system is a type of space-borne movable remote sensing system that has a measurement principle of active remote sensing. Compared to “RADARSAT-2_SAR” and “AQUA_MODIS,” the mathematical proposition {“Is_Same_PlatformHeightType” = Yes ∧ “Is_Same_Mobility” = Yes ∧ “Is_Same_Measures” = Yes} returns a “false” value. As shown in Figure 4, the main difference between the two heterogeneous remote SRO_rs instances is that their ${\text{MD}}_{\text{i}}^{\text{CP}}$ has different attribute variables, whereas the other seven-tuple metadata objects have the same meta-attributes as those of the above scanner SRO_rs but with different meta-attribute values. That is, the “RADARSAT-2_SAR” and the above “AQUA_MODIS” SRO_rs are heterogeneous. The RA of “RADARSAT-2_SAR” is available at the online sensor view module ( http://swe.whu.edu.cn/sensormodel/SensorView.aspx).

3.3. Object Model Application

SensorModel is an online prototype ( http://swe.whu.edu.cn/SensorModel) developed by our team to provide the rapid construction of the uniform representation of RA_rs for different types of SRO_rs instances and to implement the union operation among different homogeneous satellite SRO_rs instances. The experimental flow to demonstrate the functionality of the proposed model is as follows. First, modelers can rapidly and efficiently build the RA_rs description model by using the online modeling module ( http://swe.whu.edu.cn/SensorModel/SensorModelScanner.aspx); then, the RA_rs libraries are formed. Next, depending on the actual emergency situation, the sensor inquirer inputs the search criteria in the form of “time–space–measurement_parameters_of_required_data” to determine the qualified sensor ( http://swe.whu.edu.cn/SensorModel/SensorOperation.aspx). Thereafter, we select the SRO_rs instances from the searched results to perform the selected operation, where the relations between these sensors should be determined to ascertain whether they are homogeneous or heterogeneous. If they are homogeneous, the selected homogenous operation needs to be executed. Figure 5 shows the four stages of our proposed object model involved in the integration of satellite imagery observation, including the occurrence of imagery observation tasks, requirement analysis of imagery observation tasks, discovery of satellite sensors, and operation execution among SROs_rs. The new virtual SRO_rs generated from selected operation in the last stage has more powerful imagery observation capability which can assist in the integration of satellite observations for the specific emergency task.

In this study, approximately 30 remote sensing satellite sensors, including MODIS_AQUA and HRG_SPOT 5, are described in the experimental library ( http://swe.whu.edu.cn/SensorModel/SensorView.aspx). A hypothetical flood observation in the Yangtze River (24°27′ N to 35°54′ N, 90°13′ E to 122°19′ E) in China is used as the actual application. This location requires an appropriate and timely observation response from the EO satellite sensors. The application of remote sensing technology in flood observation involves the identification of the geographical location of flood water, flood inundation areas, water capacity, and so on. In this study, we select “water surface extraction,” “water storage capacity,” and “multipurpose imagery (land)” as the measurement parameters. On the basis of the proposed model, we conduct a concrete sensor query with the following parametric values: “beginTime = 2012-09-19T11:00:00,” “endTime = 2012-09-19T18:00:00,” “MinLongitude (decimal) = 90.2166,” “MinLatitude (decimal) = 24.45,” “MaxLongitude (decimal) = 122.3166,” “MaxLatitude (decimal) = 35.9,” and “measurement_parameters_of_required_data = {multipurpose imagery (land), water surface, water storage capacity}.”

The proposed model can support the acquisition of suitable sensors by the sensor inquirer. The search results (Figure 6) show the available sensors that meet the specific observation requirements (i.e., “ALI_EO-1,” “MODIS_AQUA,” “HRG_SPOT-5,” “SAR_RADARSAT-2,” and “TM_Landsat-5”) such that selective measurements can be obtained under the given spatial and temporal conditions.

We then select the sensor collection such as “{HRG_SPOT-5, MODIS_AQUA},” “{MODIS_AQUA, TM_Landsat-5},” “{HRG_SPOT-5, MODIS_AQUA, TM_Landsat-5},” and “{SAR_RADARSAT-2, HRG_SPOT-5}” to conduct the union operation. By initially executing “Check Union,” we find that the other three collections are homogeneous, except for “{SAR_RADARSAT-2, HRG_SPOT-5}.” Three new virtual SRO_rs instances are produced by implementing “Execute Union.” Each new RA_rs of the SRO_rs can be viewed by clicking the “ViewResultSensorObject” option. Figures 7a to c show the useful observation capabilities and characteristics extracted from the corresponding new RA_rs.

The sensor inquirer can determine that Band 03, the panchromatic of “HRG_SPOT 5,” and Band 01 of “MODIS_AQUA” can complete the measurements of “multipurpose imagery (land)” and “water surface” (Figure 7a). Band 01 of “MODIS_AQUA” and Band 3 of “TM_Landsat-5” are suitable for the “water surface” measurement (Figure 7b). Band 01 of “MODIS_AQUA” and Band 3 of “TM_Landsat-5” can be used for the “water surface” measurement, whereas Band 3 and the panchromatic of “HRG_SPOT 5” can complete the measurement of “multipurpose imagery (land) (Figure 7c).

4. Discussions

4.1. Feasibility and Versatility of Proposed Object Model

In the proposed model, each remote sensor can be specialized into a concrete SRO_rs according to the sensor type. Each concrete SRO_rs is viewed as an object that has stable modeling units, including SensorID, RA_rs, and RM_rs. The adoption of SensorML as the description framework of RA_rs carefully considers the elements needed in the accessibility and sharing of remote sensing satellite sensors, particularly the observation capabilities. As described in Section 3, different types of remote sensing satellite sensors are encapsulated into the SRO_rs state description instance. In particular, the concept of sensor objects with pertinent operations can be applied to any remote sensor. In this study, each physical remote sensor is viewed as an entity with its own objective attributes and operations. The proposed sensor object model is used for sharing and integrating remote sensing satellite sensors, whereas that of the object-oriented modeling approach is to realize the object management, mutual cooperation, and collaboration of the object system. Therefore, the object-oriented approach is more feasible for building a sensor model for the integration multiple remote sensors than the function-specific sensor modeling standard introduced in Section 1.

4.2. Conducive to Uniform Management and Integration of Multiple Remote Sensing Satellite Sensors and their Observations

The existing tools or applications such as REmote Sensing Planning Tool (RESPT: http://ww2.rshgs.sc.edu/pg_Predict.aspx) and NASA Global Change Master Directory (GCMD) retrieval portal ( http://gcmd.gsfc.nasa.gov/KeywordSearch/Freetext.do?KeywordPath=&Portal=GCMD&Freetext=hyperion&MetadataType=0), which can be used for managing satellite sensors for emergency management, have their own proprietary information descriptions for sensor attribute states. Such tools use different sensor description standards to express the random attributes of sensor objects. Therefore, achieving the uniform sharing and discovery of heterogeneous satellite sensors, particularly the observations, is difficult. RESPT can be used only for the planning of satellite sensors provided by the user. The GCMD retrieval portal is used to discover satellite sensors by using the fuzzy mode of entering “free text” and “filter list” as the query criteria. In this study, we consider the comprehensive state information of fine-grained satellite sensors, including basic sensor identification, physical characteristics, sensor geoposition, and observation capability attributes. By adopting the SensorML as the description framework to encapsulate the defined attributes of remote sensing satellite sensors, the proposed SensorML-based RA_rs can satisfy the scenario wherein the user can uniformly and accurately discover qualified multiple sensors. Furthermore, the sensor inquirer can clearly obtain a sensor integration solution, namely, resolving the question of “sensor-collaborate-with-sensor,” by executing the operation among different SRO_rs instances. For example, the sensor inquirer can determine sensors with the same applications under the same temporal and spatial conditions (Figures 7a to c). Band 3 and the panchromatic of “HRG_SPOT 5” have the same applications. The inquirer considers other additional attributes regarding the capabilities and characteristics of the sensors, such as “RadiometricAccuracy,” to determine further the superior band. On the basis of unique measurements from different sensors, the inquirer can solve the integration solution to determine the bands that can collaborate in completing a specific task (Figure 7a). Band 3 or the panchromatic of “HRG_SPOT 5” can collaborate with Band 01 of “MODIS_AQUA” to complete the measurements of “multipurpose imagery (land)” and “water surface” needed in the flood observations. With regard to an emergency observation task, a lag during decision making can often result in significant losses. Therefore, such tasks usually require accurate and comprehensive responses by immediately discovering and planning a sensor for the observation. Instead of getting confused or ignoring earlier mass satellite sensor information, the sensor inquirer can employ the new SRO_rs for the continuous acquisition of data by leveraging the observation information extracted from the RA_rs of the new virtual SRO_rs.

5. Conclusions

This study introduces a remote sensing satellite sensor object model that comprises SensorID, meta-attribute state, and associated operation method. We exemplify and illustrate the union operation and examine it by using homogeneous remote sensors retrieved within a real-life situation. The results confirm that the model performs as a uniform attribute state information descriptor for sensor discovery. Furthermore, the model can serve as a computable model that uses the union operation, and assist in the integration of multiple satellite sensors during an emergency task.

The future directions of this study are as follows: evolve the mode of the current syntactic matchmaking between specific remote sensing tasks and the database of remote sensor metadata into the semantic mode [41,42]; develop other proposed operations that are suitable for heterogeneous SRO_rs instances to provide a complete information foundation for the integration of different satellite sensors; further improve the proposed prototype SensorModel with the characterization of providing a preliminary status on the quality of discovered sensors.