Remote Sensing an Object Model for Integrating Diverse Remote Sensing Satellite Sensors: a Case Study of Union Operation Om S : Sensor Object Model Sro: Sensor Resource Object Sensorid: Sensor Identification Ra: Resource Attribute Rm: Resource Method Md: Metadata Sro_rs: Remote Sensing Sensor Resour

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. 678 List of Abbreviations The following symbols and abbreviated terms are used in this paper.


List of Abbreviations
The following symbols and abbreviated terms are used in this paper.

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][5][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 SensorMLbased 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 objectoriented 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.

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: 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 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: 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: where MD is the general metadata group, MD is the constraint metadata group, MD is the characteristic metadata group, MD is the capability metadata group, MD is the reference metadata group, MD is the spatial-temporal metadata group, MD is the geoposition metadata group, and MD 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: SRO_rs= {SensorID, RA_rs, RM_rs} 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.

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 MD includes attributes such as keyword, sensor type, sensor name, sensor_associated_platform, platform type, platformID, and platform name.MD includes the sensor observation validity time and sharing levels of sensor and responsible centers.MD includes mobility, measures, height, mass, power, and dimension.MD includes the URLs of the sensor's online resources.MD mainly includes the web service interface used to access the sensors and related observations.MD and MD mainly contain the parameters used to determine the satellites' dynamic trajectory.MD 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, MD , MD , MD , MD , MD , MD , and MD , can be completely obtained from the above (Table 1).However, MD 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 MD and MD , the attributes used for geolocation, such as field of view (FOV), swath width, and side swing angle, are important capability indices in MD .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 MD 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 shows the details of MD for a specific type of remote sensor.

Remote Sensor Resource Operations
The different SRO_rs instances can exhibit homogeneity and heterogeneity.Table 4 shows two types of classifications of EO sensors: traditional and OGC SensorMLrecognized 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 1 _rs and SRO 2 _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 1 _rs ∪ SRO 2 _rs ≡ {t | t ∈ SRO 1 _rs ∨ t ∈ SRO 2 _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 1 _rs and SRO 2 _rs. SRO'_rs = SRO 1 _rs ∩ SRO 2 _rs ≡ {t | t ∈ SRO 1 _rs ∧ t ∈ SRO 2 _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 1 _rs and SRO 2 _rs. SRO′_rs = SRO 1 _rs -SRO 2 _rs ≡ {t | t ∈ SRO 1 _rs ∧ t ∉ SRO 2 _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 1 _rs but not in SRO 2 _rs.
For heterogeneous SRO_rs instances, the included operations are as follows: , where t1 and t2 are the meta-attribute variables of SRO′_rs.We assume that SRO 1 _rs has n-ary meta-attribute columns, and SRO 2 _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 1 _rs, and the succeeding m-ary meta-attribute columns are the meta-attributes of SRO 2 _rs.
where t1 and t2 are the meta-attribute variables of SRO′_rs.SRO 1 _rs and SRO 2 _rs have the same meta-attribute column B = D = D , 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 nary meta-attribute columns in SRO′_rs are the meta-meta-attributes of SRO 1 _rs.The succeeding (m-s)-ary meta-attribute columns are the meta-attributes of SRO 2 _rs.

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 1 _rs and SRO 2 _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 1 _rs and SRO 2 _rs.The following algorithms enumerate the union operation performed between SRO 1 _rs and SRO 2 _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( .Instance, .Instance) (lines 5 to 16 of Algorithm 2), where MD is either {MD , MD , MD , MD , MD , MD , or MD }, is the second category that returns a "true" value if the struct members of the nodes in MD .Instance and MD .Instance are equal.The third category is Compare( .Instance, .Instance) (MD is MD ) (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.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.

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 MD 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).

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.

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 functionspecific sensor modeling standard introduced in Section 1.

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-withsensor," 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.

Conclusions
This study introduces a remote sensing satellite sensor object model that comprises SensorID, metaattribute 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.

Figure 1 .
Figure 1.Conceptual level of the sensor object model (blue font are the corresponding instructions).

Figure 5 .
Figure 5.The stages of our proposed object model involved in the integration of satellite imagery observation (the marked numbers represent the detailed experimental flows).

Figure 6 .
Figure 6.Sensor application based on the proposed model.

Figure 7 .
Figure 7. Useful observation information extracted from the corresponding new RS_rs of SRO_rs.

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

Table 2 .
MD for a specific type of remote sensing satellite sensors.

Table 3
lists the logical structure of the proposed SRO_rs.

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

SensorID RA_rs RM_rs SensorID MD i Union (MD i ) Intersection (MD i ) Difference (MD i ) Product (MD i ) Join (MD i )
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.

Table 4 .
Earth Observation (EO) sensor classification and analysis of different metaattribute elements.