Toward a Standardized Encoding of Remote Sensing Geo-Positioning Sensor Models

: Geolocation information is an important feature of remote sensing image data that is captured through a variety of passive or active observation sensors, such as push-broom electro-optical sensor, synthetic aperture radar (SAR), light detection and ranging (LIDAR) and sound navigation and ranging (SONAR). As a fundamental processing step to locate an image, geo-positioning is used to determine the ground coordinates of an object from image coordinates. A variety of sensor models have been created to describe geo-positioning process. In particular, Open Geospatial Consortium (OGC) has deﬁned the Sensor Model Language (SensorML) speciﬁcation in its Sensor Web Enablement (SWE) initiative to describe sensors including the geo-positioning process. It has been realized using syntax from the extensible markup language (XML). Besides, two standards deﬁned by the International Organization for Standardization (ISO), ISO 19130-1 and ISO 19130-2, introduced a physical sensor model, a true replacement model, and a correspondence model for the geo-positioning process. However, a standardized encoding for geo-positioning sensor models is still missing for the remote sensing community. Thus, the interoperability of remote sensing data between application systems cannot be ensured. In this paper, a standardized encoding of remote sensing geo-positioning sensor models is introduced. It is semantically based on ISO 19130-1 and ISO 19130-2, and syntactically based on OGC SensorML. It deﬁnes a cross mapping of the sensor models deﬁned in ISO 19130-1 and ISO 19130-2 to the SensorML, and then proposes a detailed encoding method to ﬁnalize the XML schema (an XML schema here is the structure to deﬁne an XML document), which will become a proﬁle of OGC SensorML. It seamlessly uniﬁes the sensor models deﬁned in ISO 19130-1, ISO 19130-2, and OGC SensorML. By enabling a standardized description of sensor models used to produce remote sensing data, this standard is very promising in promoting data interoperability, mobility, and integration in the remote sensing domain.


Introduction
Remote sensing has been widely used to monitor Earth's surface environment and its changes over time that are associated with reflectance and other surface properties of Earth. One of the key characteristics of remote sensing data is that it conveys ground location information, which is retrieved through geo-positioning processes [1].
According to the World Meteorological Organization (WMO) [2], approximately 950 types of remote sensors (including both Earth observation instruments and solar/space environment monitors)

Sensor Models for Geo-Positioning Process and Related International Standards
A geo-positioning process is a type of location model to geo-register or co-register observations from a sensor (particularly remote sensors) [4]. It determines the relationship between the image coordinates and its geo-position along with other auxiliary information (the performance and quality of measurement characteristics, an explicit description of the process, and physical characteristics). The geo-positioning process is part of a sensor model [1]. Among these processes, the geo-positioning process serves as one of the most fundamental and indispensable links to locate an image. It can help provide a coherent framework for data processing.
To confront the above-mentioned issues, two major international standards organizations are currently making efforts to devise standards for geo-positioning sensor models, namely ISO/TC 211 (the International Organization for Standardization/Technical Committee 211) which is about standardization in the field of digital geographic information [5] and OGC (the Open Geospatial Consortium) which provides geospatial location information and services [6]. Both OGC and ISO standards are international standards. However, OGC standards are developed by concerned parties interested in the standard while ISO standards are developed by experts contributed by and approved by the member nations. OGC is an official external liaison organization of ISO TC 211 [7].
As a work item of the ISO/TC 211 and the ISO 19100 series, ISO 19130 is a standard series that specifies the geolocation information that an imagery data provider shall supply for users to estimate the Earth location of image data using a physical sensor model (PSM, the mathematical representation of the physics and geometry of the image sensing system [1]), a true replacement model (TRM, produced using a PSM whose formulae directly describing the relationship between image coordinates and Earth coordinates [1]), or a correspondence model (CM, using image information and ground control points only for georeferencing [1]). The ISO 19130 series has published two standards: ISO 19130-1 and ISO 19130-2. The first part (ISO 19130-1) defines sensor models for passive electro-optical visible/infrared (IR) sensors (namely frame, pushbroom, and whiskbroom sensors) and for an active sensing system [Synthetic Aperture Radar (SAR)], and metadata for ground control points (GCPs). The second part of the standard (ISO 19130-2) [8] further defines sensor models for SAR, InSAR, light detection and ranging (lidar), and sound navigation and ranging (sonar), along with the metadata needed for the aerial triangulation of airborne and spaceborne images. ISO 19130-1 and ISO 19130-2 rigorously define the physical and geometric information of a sensor and the functions (a function here is a clearly defined expression that can

Sensor Models for Geo-Positioning Process and Related International Standards
A geo-positioning process is a type of location model to geo-register or co-register observations from a sensor (particularly remote sensors) [4]. It determines the relationship between the image coordinates and its geo-position along with other auxiliary information (the performance and quality of measurement characteristics, an explicit description of the process, and physical characteristics). The geo-positioning process is part of a sensor model [1]. Among these processes, the geo-positioning process serves as one of the most fundamental and indispensable links to locate an image. It can help provide a coherent framework for data processing.
To confront the above-mentioned issues, two major international standards organizations are currently making efforts to devise standards for geo-positioning sensor models, namely ISO/TC 211 (the International Organization for Standardization/Technical Committee 211) which is about standardization in the field of digital geographic information [5] and OGC (the Open Geospatial Consortium) which provides geospatial location information and services [6]. Both OGC and ISO standards are international standards. However, OGC standards are developed by concerned parties interested in the standard while ISO standards are developed by experts contributed by and approved by the member nations. OGC is an official external liaison organization of ISO TC 211 [7].
As a work item of the ISO/TC 211 and the ISO 19100 series, ISO 19130 is a standard series that specifies the geolocation information that an imagery data provider shall supply for users to estimate the Earth location of image data using a physical sensor model (PSM, the mathematical representation of the physics and geometry of the image sensing system [1]), a true replacement model (TRM, produced using a PSM whose formulae directly describing the relationship between image coordinates and Earth coordinates [1]), or a correspondence model (CM, using image information and ground control points only for georeferencing [1]). The ISO 19130 series has published two standards: ISO 19130-1 and ISO 19130-2. The first part (ISO 19130-1) defines sensor models for passive electro-optical visible/infrared (IR) sensors (namely frame, pushbroom, and whiskbroom sensors) and for an active sensing system [Synthetic Aperture Radar (SAR)], and metadata for ground control points (GCPs). The second part of the standard (ISO 19130-2) [8] further defines sensor models for SAR, InSAR, light detection and ranging (lidar), and sound navigation and ranging (sonar), along with the metadata needed for the aerial triangulation of airborne and spaceborne images. ISO 19130-1 and ISO 19130-2 rigorously define the physical and geometric information of a sensor and the functions (a function here is a clearly defined expression that can receive inputs and produce outputs) and parameters for describing a PSM, TRM, and CM, along with GCPs. They work together to determine the geographic position of images from sensors.
The other standard organization, OGC, not only fosters and supports a global conversation to create free and publicly available geospatial standards, but collaborates with other standard development organizations including ISO/TC 211 [9]. OGC defines interfaces and encodings for sensor devices and data through Sensor Web Enablement (SWE) [10] to enable sharing sensor data over the Web. Tremendous amounts of sensor data around the world are generated from the World-Wide Sensor Web [11,12]. For example, Durbha [13] developed a standards-based approach to remotely configure sensors deployed in marine observation platforms through the SWE framework.
Sensor Model Language 2.0 (SensorML; here, SensorML represents SensorML 2.0.) [4] is a very important standard in SWE. It provides a well-defined and robust way of describing the process of measurement and observation, along with the associated processing components. SensorML uses the process concept to describe components including sensors, sensor systems, observations and measurement. A process receives an input through algorithm and sets parameter values, and generates outputs [4]. Geo-positioning plays an important role in SensorML as a process. The aims of SensorML include one clause that it supports the geolocation of observed values.
SensorML has been widely adopted and implemented in the remote sensing society [14][15][16]. Some researchers used SensorML to strengthen the connection between sensors. For example, Chen constructs a geoprocessing e-Science workflow model for sensor observations in the form of observation processes based on SensorML [17]. Some researchers built their sensor systems or sensor webs based on SensorML. For example, Poland launched an air quality monitoring network in Nowy Sacz using SensorML and Observations & Measurements (O&M) to describe the sensor [18]. Sorribas [19] used a SensorML profile and O&M profile to express research vessels and fixed stations to enable the discovery and exchange of marine observations and improve the descriptions of complex instrumentation and data structures. AFIS (The Advanced Fire Information System) in South Africa [12] used SensorML to describe their satellite sensor models in a sensor web application for regional vegetation fire detection. SensorML is also used to improve interoperability of unattended ground sensors from different manufacturers [20]. Besides, lots of SensorML profiles are developed and bring more semantics to SensorML. The Starfish Fungus Language (StarFL) is a profile to further constrain the use and expressiveness of SensorML to improve interoperability [21].

Implementable Sensor Model for Geo-Positioning
Although both SensorML and ISO 19130 series standards describe sensor models for geo-positioning, many differences between them have been observed (see Table 1). ISO 19130-1 and ISO 19130-2 present detailed characteristics of passive observation and active observation sensor models directly, and they only provide unified modeling language (UML) descriptions along with the data dictionaries. It is highly expected to have an implementable schema to ensure interoperable encoding results. The SensorML specification defines a comprehensive and concrete conceptual model along with encoding methods using the extensible mark language (XML) Schema, but it is a relatively soft-typing (which takes advantages of both static and dynamic typing where typing means defining the data type). The SensorML data model aims at covering almost all types of sensors. Therefore, it is designed to be general-purpose, which makes it difficult to be directly applied to rigorous sensor geo-positioning models. Moreover, SensorML does not have a specific metadata description and definition of the geo-positioning process. Reconceptualization, redefinition, or some extension of SensorML are needed to support the encodings of geo-positioning sensor models.

Focus
"To provide a framework for defining processes and processing components associated with the measurement and post-measurement transformation of observations." [4] "To define the metadata to be distributed with the image to enable user determination of geographic position from the observations." [1] Aims To bridge this gap, a SensorML profile for the imagery sensor geo-positioning process is put forward in this paper as a semantic mediation between ISO 19130-1, ISO 19130-2, and OGC SensorML standards to enable a standardized encoding of geo-positioning sensor models. This effort helps to ensure a truly interoperable description of a variety of remote sensing geo-positioning sensor models for the remote sensing community. It will benefit various parties, including academia, business, industries, governments, and consumers.

Goals
This paper describes a solution to bridge the two aforementioned standards. From OGC side, the result will become a profile of SensorML and from ISO/TC 211 side, it will form into a technical specification of ISO (named as ISO 19130-3). Specifically, it has the following goals: This profile requires underlying alignment between OGC and ISO terminology and semantics for image geo-positioning. Normally, ISO/TC 211 has the ability to automatically interpret UML models into XML schemas. This paper, instead of introducing an XML schema just based on the ISO 19130 UML models, leverages OGC SensorML by first introducing a semantic mapping from the ISO sensor model elements to OGC SensorML, and then defining a SensorML profile to fully support encoding of the imagery sensor models for geo-positioning process for remote sensors.

Analysis of Sensor Models and the Two Standards
As mentioned in the Introduction, SensorML and ISO 19130-1 and ISO 19130-2 are built for different purposes, thus resulting in different specifications ( Figure 1).
In ISO 19130-1 and ISO 19130-2, sensor models are classified as geolocating models including PSM, TRM, and georeferencing models including CM according to their various mathematical principles in different applicable scenarios ( Table 2). Some common elements (GCPs, calibration data, and code lists) are declared to support these models. The selection of sensor models is determined by sensor types (namely, frame sensor, pushbroom sensor, whiskbroom sensor, SAR, InSAR, lidar, sonar) and by mounting platforms such as airborne or spaceborne. A PSM needs description of classes for describing metadata, model approaches, quality information, sensor parameters, location, and orientation. A TRM needs description of fitting functions, model approaches, and quality information. A CM needs a description of GCPs for geo-positioning along with fitting functions. All components in SensorML are modeled as processes: physical processes (e.g., sensors, detectors, and systems) and non-physical processes (e.g., observations, measurement, and mathematical operations or functions). A process takes inputs and produces outputs through well-defined methods and parameters. All these basic elements can therefore be interconnected to form aggregate processes (like sensor workflows, chains, and networks).
The root class of SensorML is DescribedObject, which functions as the basis for most classes. DescribedObject defines a specific set of metadata (including language, security constraints, legal constraints, identification information etc.,) for all process classes in SensorML. AbstractProcess is a derived class from DescribedObject along with additional properties of typeOf, configuration, featuresOfInterest, inputs, outputs, parameters, and modes. The four derived classes (SimpleProcess, PhysicalComponent, PhysicalSystem, AggregateProcess) list relatively comprehensive and extendible properties to describe a sensor and related processes. However, the flexibility of SensorML cannot ensure a clear and rigorous definition for a geo-positioning process. Further, it cannot specify the minimum requirements and other constraints for elements of a sensor model.
Although SensorML does not rigorously specify any semantic model for geo-positioning, it enables users to define sensor models using SensorML's processes model. Botts [22] gives an example of how to describe a frame sensor model using SensorML 1.0. The encoding implementation of this example frame sensor model is shown in Figure 2. The full XML code of this example can be found in Annex B of OGC 08-071 document [22].  Figure 2 shows that the information needed for a frame sensor model includes the value of inputs, outputs, and parameters. The name of each property might vary from case to case. For example, the distortion information in this case is defined by parameters of affine distortion coefficients, radial distortion coefficients, and decentering coefficients. In other cases, distortion information may be a distortion table or a distortion polynomial. This kind of difference reduces interoperability between different sensor systems. Furthermore, SensorML does not give instructions on how to align with geo-positioning models, which may cause confusion for users.
As indicated in ISO 19130-1 and ISO 19130-2, every element has an applicable semantic meaning. Compared with SensorML, the geolocation information for a sensor model is constrained to specific data types or formats, relatively narrow value ranges, strict dependencies, or the number of occurrence. In ISO 19130-1, for instance, the SD_Dynamics (all classes defined in ISO 19130-1 have a prefix "SD") and its derived classes provide the motion information of a body. All dynamic-related attributes are put under these classes. Because of SensorML's high flexibility, SD_Dynamics may be encoded as a ParameterList (an element from SensorML, composed of a group of anyData value) or a SimpleProcess (an indivisible process). Users might face with multiple choices to encode SD_Dynamics. The related properties like attitude, velocity, acceleration, yaw, and heading will be in various forms as well. Therefore, the description of SD_Dynamics will differ from user to user, which is contrary to the aim of improving interoperability. Thus, an extension of SensorML classes to rigorously define data semantics and constraint for ISO sensor model elements is necessary. It avoids ambiguous definitions and provides users with clearer instructions when they encode geopositioning models for sensors.

Design Principles
In order to map these sensor geo-positioning models in ISO 19130-1 and ISO 19130-2 to SensorML elements, the following principles are designed. Principle 1. For ISO sensor model elements that can perfectly match the context and content of SensorML classes, they can be directly implemented using the existing correspondence SensorML classes ( Figure 3).  Figure 2 shows that the information needed for a frame sensor model includes the value of inputs, outputs, and parameters. The name of each property might vary from case to case. For example, the distortion information in this case is defined by parameters of affine distortion coefficients, radial distortion coefficients, and decentering coefficients. In other cases, distortion information may be a distortion table or a distortion polynomial. This kind of difference reduces interoperability between different sensor systems. Furthermore, SensorML does not give instructions on how to align with geo-positioning models, which may cause confusion for users.
As indicated in ISO 19130-1 and ISO 19130-2, every element has an applicable semantic meaning. Compared with SensorML, the geolocation information for a sensor model is constrained to specific data types or formats, relatively narrow value ranges, strict dependencies, or the number of occurrence. In ISO 19130-1, for instance, the SD_Dynamics (all classes defined in ISO 19130-1 have a prefix "SD") and its derived classes provide the motion information of a body. All dynamic-related attributes are put under these classes. Because of SensorML's high flexibility, SD_Dynamics may be encoded as a ParameterList (an element from SensorML, composed of a group of anyData value) or a SimpleProcess (an indivisible process). Users might face with multiple choices to encode SD_Dynamics. The related properties like attitude, velocity, acceleration, yaw, and heading will be in various forms as well. Therefore, the description of SD_Dynamics will differ from user to user, which is contrary to the aim of improving interoperability. Thus, an extension of SensorML classes to rigorously define data semantics and constraint for ISO sensor model elements is necessary. It avoids ambiguous definitions and provides users with clearer instructions when they encode geo-positioning models for sensors.

Design Principles
In order to map these sensor geo-positioning models in ISO 19130-1 and ISO 19130-2 to SensorML elements, the following principles are designed. Principle 1. For ISO sensor model elements that can perfectly match the context and content of SensorML classes, they can be directly implemented using the existing correspondence SensorML classes ( Figure 3). Principle 2. ISO sensor model elements that share a similar context but differ in properties with SensorML classes will inherit the shared properties from SensorML classes and form into subclasses along with their unique properties. The inherited properties must meet other constraints, such as occurrence times or data type ( Figure 4).

Principle 3.
For ISO sensor model elements that neither share a similar meaning nor the properties with SensorML classes, they cannot find a mapping to SensorML. Therefore, new classes are introduced to SensorML to meet these new requirements ( Figure 5). For example, the SD_AzimuthMeasure is a class to describe the measurement of azimuth properties. SensorML does not have a similar element to azimuth information. Therefore, a new class is defined in ISO 19130-3 to fill this gap. Referring to the aforementioned three principles, all classes of ISO 19130 series can be mapped, extended from SensorML or newly defined.

Semantic-Level Mapping
The three principles instruct how to rewrite a class from syntactic side. They do not tell us how to map classes from semantic side. An understanding of SensorML classes is important for the mapping. Table 3 lists all main classes of SensorML and their definitions. Main classes mean they are root or near root classes to derive other classes. Except for the Core class, which is a group of abstract classes serving as the root of the other five classes, the other five main classes are not abstract and can be used directly to describe these ISO sensor models.
The SimpleProcess, PhysicalComponent, PhysicalSystem, and AggregateProcess describe a process from dimensions that whether it is physical or non-physical, and atomic or composite (atomic or composite means indivisible or not). The PhysicalComponent and PhysicalSystem are both Principle 2. ISO sensor model elements that share a similar context but differ in properties with SensorML classes will inherit the shared properties from SensorML classes and form into subclasses along with their unique properties. The inherited properties must meet other constraints, such as occurrence times or data type ( Figure 4). Principle 2. ISO sensor model elements that share a similar context but differ in properties with SensorML classes will inherit the shared properties from SensorML classes and form into subclasses along with their unique properties. The inherited properties must meet other constraints, such as occurrence times or data type ( Figure 4).

Principle 3.
For ISO sensor model elements that neither share a similar meaning nor the properties with SensorML classes, they cannot find a mapping to SensorML. Therefore, new classes are introduced to SensorML to meet these new requirements ( Figure 5). For example, the SD_AzimuthMeasure is a class to describe the measurement of azimuth properties. SensorML does not have a similar element to azimuth information. Therefore, a new class is defined in ISO 19130-3 to fill this gap. Referring to the aforementioned three principles, all classes of ISO 19130 series can be mapped, extended from SensorML or newly defined.

Semantic-Level Mapping
The three principles instruct how to rewrite a class from syntactic side. They do not tell us how to map classes from semantic side. An understanding of SensorML classes is important for the mapping. Table 3 lists all main classes of SensorML and their definitions. Main classes mean they are root or near root classes to derive other classes. Except for the Core class, which is a group of abstract classes serving as the root of the other five classes, the other five main classes are not abstract and can be used directly to describe these ISO sensor models.
The SimpleProcess, PhysicalComponent, PhysicalSystem, and AggregateProcess describe a process from dimensions that whether it is physical or non-physical, and atomic or composite (atomic or composite means indivisible or not). The PhysicalComponent and PhysicalSystem are both   Principle 2. ISO sensor model elements that share a similar context but differ in properties with SensorML classes will inherit the shared properties from SensorML classes and form into subclasses along with their unique properties. The inherited properties must meet other constraints, such as occurrence times or data type (Figure 4).

Principle 3.
For ISO sensor model elements that neither share a similar meaning nor the properties with SensorML classes, they cannot find a mapping to SensorML. Therefore, new classes are introduced to SensorML to meet these new requirements ( Figure 5). For example, the SD_AzimuthMeasure is a class to describe the measurement of azimuth properties. SensorML does not have a similar element to azimuth information. Therefore, a new class is defined in ISO 19130-3 to fill this gap. Referring to the aforementioned three principles, all classes of ISO 19130 series can be mapped, extended from SensorML or newly defined.

Semantic-Level Mapping
The three principles instruct how to rewrite a class from syntactic side. They do not tell us how to map classes from semantic side. An understanding of SensorML classes is important for the mapping. Table 3 lists all main classes of SensorML and their definitions. Main classes mean they are root or near root classes to derive other classes. Except for the Core class, which is a group of abstract classes serving as the root of the other five classes, the other five main classes are not abstract and can be used directly to describe these ISO sensor models.
The SimpleProcess, PhysicalComponent, PhysicalSystem, and AggregateProcess describe a process from dimensions that whether it is physical or non-physical, and atomic or composite (atomic or composite means indivisible or not). The PhysicalComponent and PhysicalSystem are both Referring to the aforementioned three principles, all classes of ISO 19130 series can be mapped, extended from SensorML or newly defined.

Semantic-Level Mapping
The three principles instruct how to rewrite a class from syntactic side. They do not tell us how to map classes from semantic side. An understanding of SensorML classes is important for the mapping. Table 3 lists all main classes of SensorML and their definitions. Main classes mean they are root or near root classes to derive other classes. Except for the Core class, which is a group of abstract classes serving as the root of the other five classes, the other five main classes are not abstract and can be used directly to describe these ISO sensor models.
The SimpleProcess, PhysicalComponent, PhysicalSystem, and AggregateProcess describe a process from dimensions that whether it is physical or non-physical, and atomic or composite (atomic or composite means indivisible or not). The PhysicalComponent and PhysicalSystem are both physical processes with real devices, while SimpleProcess and AggregateProcess (as well as configurableProcess) consist of one or more well-defined functions. In terms of atomic or composite side, the SimpleProcess and PhysicalComponent are indivisible processes, while AggregateProcess and PhysicalSystem are composites of several indivisible or composite processes. By classifying these classes, we are able to map corresponding ISO 19130-1 and ISO 19130-2 concepts and classes to SensorML. Semantically, SD_Sensor describes a physical sensor's information. The PhysicalComponent in SensorML is similar with SD_Sensor. The PhysicalComponent class represents real devices with spatio-temporal information. Besides, they not only share semantical similarity, but also some property similarities.
It defines calibration, mode, and operationalBand properties. The concept of PhysicalComponent is consistent with SD_Sensor, but properties of PhysicalComponent cannot perfectly match those of SD_Sensor (Principle 3). Therefore, a new class, sml19130:SD_Sensor is defined under the namespace sml19130 as a subclass of sml: PhysicalComponent. Among three properties of SD_Sensor, mode has a similar meaning as the modes property inherited from sml: PhysicalComponent. The operationalBand specifies the wavelengths information, inheriting the parameters property. The calibration matches the method property in SensorML, but its datatype (SD_Calibration) is a semantically tied process that needs further definition. Therefore, extended from PhysicalComponent, sml19130:SD_Sensor has the following schema design (found Figure 6).

Mapping Examples of ISO 19130 Three Main Sensor Models
The ISO 19130 three sensor models (PSM, TRM, CM) are derived from the root class SD_SensorModel. It provides sensor descriptions and geo-positioning model information as a subclass of MI_GeolocationInformation defined in ISO 19115-1 [23].
Three sensor models consist of different inputs and functions, which determine their related SensorML processes ( Table 2).
The PSM, as the most precise model based on accurate physical data and GCP information, consists of two component classes: SD_SensorParameters and MI_GCPCollection (if ground point details are provided) or SD_GCPRepository (if ground point collection repository URL is provided). This comprises an aggregated class and essentially a non-physical process because of its mathematical representation.
The TRM is an alternative model based on PSMs when PSM requirements cannot be met or users do not want to bother with a PSM model. It has the same properties as PSMs of ground-to-image and image-to-ground functions, complete and rigorous error propagation, and adjustability. To construct a TRM, a series of processes like coordinate normalization, direct linear transform, grid interpolation, rigorous error propagation, and adjustability are involved [1]. Any of these components can be simple processes or aggregate processes. Therefore, a TRM is an aggregate process due to its aforementioned component processes.
The CM is a less precise model compared with PSMs and TRMs since it does not consider sensor systematic errors. Basically, the CM takes GCPs as inputs and completes the geo-positioning process by two groups of fitting functions. One is for three-dimensional-to-two-dimensional (3D-to-2D) models and the other is for 2D-to-2D models (similar to "registration"). Fitting functions of CMs are one or more polynomials (simple processes). Thus, CM is also an aggregate process.

Mapping Results
In the preceding section, a general design principle for mapping between ISO 19130 and SensorML components and some examples are given. These principles guide the schema design of ISO 19130-3. The main classes of SensorML (Table 3) fall into four categories, namely physical, nonphysical, atomic, and composite (See Figure 7 (a)). A physical class usually has physical location representation, while a non-physical one does not. Based on the design principles proposed in section 2.2., some classes of ISO 19130-1 and ISO 19130-2 fit into this four-category diagram. Figure 7 gives an overview of how these classes correlate with SensorML.

Mapping Examples of ISO 19130 Three Main Sensor Models
The ISO 19130 three sensor models (PSM, TRM, CM) are derived from the root class SD_SensorModel. It provides sensor descriptions and geo-positioning model information as a subclass of MI_GeolocationInformation defined in ISO 19115-1 [23].
Three sensor models consist of different inputs and functions, which determine their related SensorML processes ( Table 2).
The PSM, as the most precise model based on accurate physical data and GCP information, consists of two component classes: SD_SensorParameters and MI_GCPCollection (if ground point details are provided) or SD_GCPRepository (if ground point collection repository URL is provided). This comprises an aggregated class and essentially a non-physical process because of its mathematical representation.
The TRM is an alternative model based on PSMs when PSM requirements cannot be met or users do not want to bother with a PSM model. It has the same properties as PSMs of ground-to-image and image-to-ground functions, complete and rigorous error propagation, and adjustability. To construct a TRM, a series of processes like coordinate normalization, direct linear transform, grid interpolation, rigorous error propagation, and adjustability are involved [1]. Any of these components can be simple processes or aggregate processes. Therefore, a TRM is an aggregate process due to its aforementioned component processes.
The CM is a less precise model compared with PSMs and TRMs since it does not consider sensor systematic errors. Basically, the CM takes GCPs as inputs and completes the geo-positioning process by two groups of fitting functions. One is for three-dimensional-to-two-dimensional (3D-to-2D) models and the other is for 2D-to-2D models (similar to "registration"). Fitting functions of CMs are one or more polynomials (simple processes). Thus, CM is also an aggregate process.

Mapping Results
In the preceding section, a general design principle for mapping between ISO 19130 and SensorML components and some examples are given. These principles guide the schema design of ISO 19130-3. The main classes of SensorML (Table 3) fall into four categories, namely physical, non-physical, atomic, and composite (See Figure 7a). A physical class usually has physical location representation, while a non-physical one does not. Based on the design principles proposed in Section 2.2., some classes of ISO 19130-1 and ISO 19130-2 fit into this four-category diagram. Figure 7 gives an overview of how these classes correlate with SensorML. Apart from the classes shown in Figure 7, some ISO 19130 classes cannot match the SensorML concepts. Their definitions and properties are beyond SensorML's scope, but are aligned with other international standards. For example, SD_GriddedGCPCollection, a class from ISO 19130-1 to describe a collection of gridded ground control points [1], is derived from ISO 19115-2 [24].

Overview of the Result
The mapping results form into a new schema. Figure 8 and Figure 9 illustrate the resulting proposed specification of ISO 19130-3. They also show how schemas are organized and defined. It is a profile of SensorML named as ISO 19130-3 under ISO 19130-1 and ISO 19130-2 semantics. Classes with similar functions and same prefix are put together in one package (a package is a group of semantically related elements [25]). The general SD_SensorModel class describing the basic sensor model is in the sensorModel package. The physicalSensorModel (PSM) and nonPhysicalSensorModel (including TRM and CM) are put in two separated packages. The groundControlPoints is a package containing GCP-related classes. The two most informative packages are spatialElements and sensorParameters. The sensorParameters is a group of parameters to define or set for a component or system. It consists of sensor parameters, distortion, detector array, sensor, sensor operations, microwave, calibration, transducer, receiver, and transmitter. The elements in spatialElements package describe spatial information, including position, attitude, dynamics, orientation, and aerial triangulation information. In Figure 8 and Figure 9, all classes in yellow are inherited from SensorML classes and classes in blue are their child classes. Classes in light orange are newly defined because of their unique properties or definitions. Finally, classes in light green are imported and extended from other standards, such as ISO 19115 Geographic Information -Metadata -Part 2: Extensions for Acquisition and Processing [24] and OGC SWE Common Data Model Encoding Standard [26]. Apart from the classes shown in Figure 7, some ISO 19130 classes cannot match the SensorML concepts. Their definitions and properties are beyond SensorML's scope, but are aligned with other international standards. For example, SD_GriddedGCPCollection, a class from ISO 19130-1 to describe a collection of gridded ground control points [1], is derived from ISO 19115-2 [24].

Overview of the Result
The mapping results form into a new schema. Figures 8 and 9 illustrate the resulting proposed specification of ISO 19130-3. They also show how schemas are organized and defined. It is a profile of SensorML named as ISO 19130-3 under ISO 19130-1 and ISO 19130-2 semantics. Classes with similar functions and same prefix are put together in one package (a package is a group of semantically related elements [25]). The general SD_SensorModel class describing the basic sensor model is in the sensorModel package. The physicalSensorModel (PSM) and nonPhysicalSensorModel (including TRM and CM) are put in two separated packages. The groundControlPoints is a package containing GCP-related classes. The two most informative packages are spatialElements and sensorParameters. The sensorParameters is a group of parameters to define or set for a component or system. It consists of sensor parameters, distortion, detector array, sensor, sensor operations, microwave, calibration, transducer, receiver, and transmitter. The elements in spatialElements package describe spatial information, including position, attitude, dynamics, orientation, and aerial triangulation information. In Figures 8 and 9, all classes in yellow are inherited from SensorML classes and classes in blue are their child classes. Classes in light orange are newly defined because of their unique properties or definitions. Finally, classes in light green are imported and extended from other standards, such as ISO 19115 Geographic Information -Metadata -Part 2: Extensions for Acquisition and Processing [24] and OGC SWE Common Data Model Encoding Standard [26].

3.3.A Sensor Model Encoding Example
To directly show how to implement the schemas on an actual remote-sensing image for a geopositioning process, a level-1 image (downloaded from Copernicus Sentinel data 2019, processed by ESA.) from Sentinel-1 satellite is given as an example [27]. The example image was acquired on 30 July, 2019 of path 5, frame 64 ( Figure 10, path and frame denote the image position in Sentinel-1's reference system).
Sentinel-1 comprises a constellation of two polar-orbiting satellites. Each satellite carries a single C-band SAR radar instrument that supports operation in dual polarization (HH+HV, VV+VH). The acquisition modes of Sentinel-1 include stripmap (SM), interferometric wide swath (IW), extra-wide swath (EW), and wave mode (WV). Because of the three acquisition modes and two polarization methods, every level-1 image product consists of six component images. The example image is one of level-1 six images. It is from Sentinel-1B satellite on IW mode and VH polarization method. Besides, the level-1 image has been geographically calibrated [28], which is suitable to illustrate the geopositioning metadata.

A Sensor Model Encoding Example
To directly show how to implement the schemas on an actual remote-sensing image for a geo-positioning process, a level-1 image (downloaded from Copernicus Sentinel data 2019, processed by ESA.) from Sentinel-1 satellite is given as an example [27]. The example image was acquired on 30 July, 2019 of path 5, frame 64 ( Figure 10, path and frame denote the image position in Sentinel-1's reference system).
Sentinel-1 comprises a constellation of two polar-orbiting satellites. Each satellite carries a single C-band SAR radar instrument that supports operation in dual polarization (HH+HV, VV+VH). The acquisition modes of Sentinel-1 include stripmap (SM), interferometric wide swath (IW), extra-wide swath (EW), and wave mode (WV). Because of the three acquisition modes and two polarization methods, every level-1 image product consists of six component images. The example image is one of level-1 six images. It is from Sentinel-1B satellite on IW mode and VH polarization method.
Besides, the level-1 image has been geographically calibrated [28], which is suitable to illustrate the geo-positioning metadata. Because this image was taken by a SAR sensor, the SE_SensorModel defined for active sensors in ISO 19130-2 is more suitable to describe the SAR geo-positioning information. The full code of the image's sensor model metadata is given in the GitHub repository: https://github.com/THU-EarthInformationScienceLab/ISO-19130-3.
All of three sensor models, PSM, TRM, and CM, can describe its geo-positioning process. This paper only provides the PSM implementation example. More examples will be updated.
In general, it is necessary for a PSM to have sensor parameters and ground control points information. Sensor parameters include parameters of identification, offset and orientation, operational mode, detector information, ground sample distance properties, system and operation. Figure 11 gives the structure of these classes. The left-side image illustrates the main components to describe a sensor model and the right-side image shows the corresponding class structure and properties.
From Table 4 to Table 9, using the proposed new schema from section 3.2, we list the data type and value of every element, which are illustrated here to show how to implement the PSM of this image based on the result in section 3.2. Because this image was taken by a SAR sensor, the SE_SensorModel defined for active sensors in ISO 19130-2 is more suitable to describe the SAR geo-positioning information. The full code of the image's sensor model metadata is given in the GitHub repository: https://github.com/THU-EarthInformationScienceLab/ISO-19130-3.
All of three sensor models, PSM, TRM, and CM, can describe its geo-positioning process. This paper only provides the PSM implementation example. More examples will be updated.
In general, it is necessary for a PSM to have sensor parameters and ground control points information. Sensor parameters include parameters of identification, offset and orientation, operational mode, detector information, ground sample distance properties, system and operation. Figure 11 gives the structure of these classes. The left-side image illustrates the main components to describe a sensor model and the right-side image shows the corresponding class structure and properties. Tables 4-9, using the proposed new schema from Section 3.2, we list the data type and value of every element, which are illustrated here to show how to implement the PSM of this image based on the result in Section 3.2. According to the above paragraphs, SE_SensorModel is the root element of this instance, which is described in detail in Table 4. From Table 5 to Table 9, instances of physicalSensorModel, sensor Information, offsetAndOrientation, systemAndOrientation, and detector are given respectively. Their relationships are given in Figure 11. Every table corresponds to an xml instance file which can be found in the GitHub repository. The first column of each table lists all elements to describe this instance. The second column is the data type of the element and the last column provides an example value. Some of the values are from the real case while some are set manually to make it easier to understand (denoted within the bracket).
We name the instance of SE_SensorModel as S1_SensorModel (Table 4). Since SE_SensorModel is derived from MI_GeolocationInformation, it also inherits the properties. In this case, it is the ID property. However, the other three properties, physicalSensorModel, sensorDataModeling, and sensorManufacturer, are the newly defined properties of SE_SensorModel. The sensorDataModeling is a codelist of sensor data modeling methods, such as absolute value, basic sequential modeling, and collection plane. The sensor manufacturer is the manufacturer of this sensor. Table 4 The SE_SensorModel instance of the given image 1 (S1_SensorModel).

The elements to define an SE_SensorModel
Type Value ID (M) 2 Msr 3 : AbstractMI_GeolocationInformation Identifier.Term.label forImageID Figure 11. The components of the SE_SensorModel instance in a real scenario (left) and the corresponding schema elements in a structured form (right).
According to the above paragraphs, SE_SensorModel is the root element of this instance, which is described in detail in Table 4. Tables 5-9, instances of physicalSensorModel, sensor Information, offsetAndOrientation, systemAndOrientation, and detector are given respectively. Their relationships are given in Figure 11. Every table corresponds to an xml instance file which can be found in the GitHub repository. The first column of each table lists all elements to describe this instance. The second column is the data type of the element and the last column provides an example value. Some of the values are from the real case while some are set manually to make it easier to understand (denoted within the bracket).
We name the instance of SE_SensorModel as S1_SensorModel (Table 4). Since SE_SensorModel is derived from MI_GeolocationInformation, it also inherits the properties. In this case, it is the ID property. However, the other three properties, physicalSensorModel, sensorDataModeling, and sensorManufacturer, are the newly defined properties of SE_SensorModel. The sensorDataModeling is a codelist of sensor data modeling methods, such as absolute value, basic sequential modeling, and collection plane. The sensor manufacturer is the manufacturer of this sensor.  2 If the property is mandatory, a "(M)" will be indicated here. 3 If the element is under the different namespace from the root element, it will be indicated here. 4 The value here reflects the real value of the example. However, if a value is shown within the bracket, it is a manual-set value, which is not provided with the example image product. All the above notes from 1 to 4 are applicable to Tables 4-9.
The physicalSensorModel is a basic element of SE_SensorModel, which is composed of a set of properties (See Table 5).
In Table 5, regionOfValidity, sensorInformation, and controlPointRepository are defined for a physical sensor model, where regionOfValidity and sensorInformation are compulsory. The regionOfValidity property defines the geographical boundary of this image. The example image is rectangular, so three corner coordinates are enough to map image coverage. The sensorInformation contains most of the important parameters to describe the geo-positioning process of this image. The data type of sensorInformation is SD_SensorInformation which is further introduced in Table 6. Another element, controlPointRepository, is an URL linking to a group of ground control points to check and refine physicalSensorModel by correcting the geographic location of the image. The value of URL is given in accessInformation property. The type of sensorInformation is SD_SensorParameters, which is an extension class from sml: physicalComponent (Table 6). It includes the sensor's offset and orientation information (offsetAndOrientation), ground sampling distance properties (gsdProperties), identification (identification), detector (detector), operational mode (operationalMode), and the sensor's operation information (systemAndOperation). The offsetAndOrientation provides detailed information of offset and orientation relative to the object on which the sensor is mounted. The operationalModes is implemented as sml: modes inherited from the base class (sml: physicalComponent).
The identification includes information about calibration, mode, and operationalBand properties of a sensor or, furthermore, information of an instrument. The systemAndOperation contains specific operational information of the sensor. In addition to collection start and end time, it must indicate whether the sensor is passive or active. The example image was taken by Sentinel-1 is a SAR sensor. Therefore, a SE_SAROperation class was chosen.
The operationalMode property is similar to the modes concept in SensorML. In this case, the operationalMode property shares the modes property from SensorML and is implemented by a string type. Here, the value is assigned to "Interferometric wide swath." Table 6. The sensorInformation instance of the given image (S1_SensorParameters).

The Elements to Define An SD_PhysicalSensorModel
Type Value
The SD_PositionAndOrientation class is used to describe the offsetAndOrientation property. The offset is a vector indicating displacement between the origin of two coordinate systems and is a kind of value to restrict image geolocation, which is similar to the concept of the configuration property inherited from SensorML. Thus, it inherits the configuration property from SensorML directly.

Discussion
In this paper, a standardized encoding of remote sensing geo-positioning sensor models is put forward. It facilitates the integration of sensor model-related standards independently defined by OGC and ISO.
However, there are still lots of potential challenges for this standard. First, although the crosswalk between ISO sensor model and SensorML follows three principles in Section 2, some mapping results are not the best solution. Classes derived from SensorML do not have restrictions on the appearance of optional properties defined in SensorML. Therefore, inheriting those optional properties in the instance of this schema is technically valid but not logically correct. When following this standard to encode the sensor models, users are suggested to strictly follow the schema proposed in this standard to avoid ambiguity. Second, more efforts are needed to promote the applications of this standard and the resultant schema. In the remote sensing community, geo-positioning information is provided in various forms. Often it is included in the calibration files. In some cases, providers do not distribute a specific file to support the geo-positioning process, in which case users need to find information by themselves. Active adoption and application of this standard is critical to ensure a standardized description of the sensor models, and to promote the interoperability of a variety of remote sensing processing systems. Third, we believe it is now possible to include geo-positioning-related information in the imagery metadata by giving an encoding method of ISO 19130 sensor models. For example, ISO 19115-2, another standard related to geo-positioning process with a published encoding schema, has been implemented in some imagery metadata. Imagery with geo-positioning metadata on the web could be easily harnessed. Finally, both OGC and ISO/TC 211 review and if necessary revise their respect standards and technical specifications periodically. For example, when a new type of sensor is developed or commonly used, it may require the development or alteration of existing standards including this one. Comprehensive revision of this standard may be necessary when there are changes in related standards.

Conclusions
This paper presented a standardized encoding of remote sensing geo-positioning sensor models. It is semantically based on ISO 19130-1 and ISO 19130-2, and syntactically based on OGC SensorML. On the one hand, ISO 19130-1 and ISO 19130-2 define UML models of a variety of sensor models that are widely used for remote sensing data, but this series of standard lacks a concrete encoding specification. The UML models cannot guarantee a consistent encoding of sensor models defined in ISO 19130-1 and ISO 19130-2. On the other hand, OGC SensorML defines the sensor model including geo-location information but in a soft-typing way. It does not indicate the type of sensor, the specific geo-positioning process nor the auxiliary components.
This study proposed three principles toward a cross-mapping of the sensor models defined in ISO 19130-1 and ISO 19130-2 to SensorML, and then provided a detailed encoding standard to finalize the schema. Based on the process-oriented encoding mechanism of SensorML, PSMs, TRMs, and CMSs from ISO 19130-1 and ISO 19130-2 are clearly defined using the process concept consisting of their corresponding inputs, functions, parameters, and outputs, as well as other necessary elements (e.g., GCP information for the check or the refinement sensor models). Other related elements are defined as different process-based classes according to their non-physical or physical, atomic, or composite characteristics.
This encoding of remote sensing geo-positioning sensor models is actually a profile of OGC SensorML. It seamlessly unifies the sensor models defined in ISO 19130-1, ISO 19130-2, and OGC SensorML. It has been reviewed by international experts from member countries of ISO TC/211. It is expected to be fully endorsed and approved as the ISO 19130-3 standard.
By enabling a standardized description of sensor models used to produce remote sensing data, the resulting standard will promote data mobility, interoperability, and integration in the remote sensing domain, especially from the following three aspects. First of all, the geo-positioning process is important for data production in ground segment. However, most of them are independently designed and lack reusable models for geo-positioning. This proposed sensor model encoding standard is expected to fill this gap. Second, in emergency response situations, it is critical important to promptly and precisely align diverse image data acquired by different sensor systems. This standardized geo-positioning description helps facilitate data integration in this pre-processing step. Last but not the least, in the sensor web context, it is necessary to accurately set or obtain the geometric features of various sensors and platforms. The encoding method proposed in this paper helps avoid developing different adaptations and private protocols for each sensor.