16
Copyright © 2015 Open Geospatial Consortium.
For backwards compatibility, GridCoverage and RectifiedGridCoverage should be kept, but deprecated.
6.3 A GMLCOV ReferenceableGrid Element for Remote Sensing Systems
6.3.1 Analysis
A ReferenceableGridCoverage with a SensorML 2.0-based ReferenceableGrid coordinate transformation should typically involve two inputs: a sensor model description containing
free variables plus a separate set of variable instantiations. Clearly the sensor model de- scription itself substitutes for the usual domain set of a coverage, which leaves open the
question of where to put the model instantiation, i.e., the variable assignments.
One option is to put these into the metadata field of a coverage. However, this has several disadvantages. Firstly, the metadata section is semantically not interpreted when a cover-
age is read, so the model is not closed any longer. Secondly, the two ingredients required for deriving direct position coordinates are sitting at different places in a coverage, some-
thing which is not elegant or desirable. Therefore, this choice has been abandoned.
A second alternative is to put both the sensor model and its instantiation into the domain set. Here a coverage reader can find all location-determining information in one place,
which is considered an asset. Of course, the domain set definition has to be extended with a new, radically different alternative, but this is the case for the first option as well.
Recommendation: The second option should be detailed into a concrete Change Request adding a SensorML 2.0 -based alternative to the coverage domain.
For OGC remote sensing imagery in, for example a GMLJP2 2.0 format, below is a diagram showing the relationships between the OGC standards making use of the
proposed element:
Figure 10: Relationships between OGC standards using the proposed ReferenceableGridBySensorModel element
6.3.2 Change Request
We propose a ReferenceableGridBySensorModel element for GMLCOV 1.0 that would enable access to the SensorML 2.0 elements SimpleProcess, AggregateProcess, and
PhysicalSystem, using a mandatory subelement “sensorModel”.
The element may be processed for instantiation parameters, which can be specified with a dependent SensorML 2.0 –based description using subelement “sensorInstance”.
The following XML Schema snippet defines a ReferenceableGridBySensorModel ele- ment that defines the transformation from the coordinates of the image pixels to ground
coordinates:
element name=ReferenceableGridBySensorModel type=gmlcov:ReferenceableGridBySensorModelType
substitutionGroup=gmlcov:AbstractReferenceableGrid complexType name=ReferenceableGridBySensorModelType
complexContent extension base=gmlcov:AbstractReferenceableGridType
sequence element name=sensorModel
type=sml:AbstractProcessPropertyType maxOccurs=unbounded
element name=sensorInstance type=sml:AbstractProcessPropertyType
minOccurs=0 maxOccurs=unbounded
sequence extension
complexContent complexType
Note that there is no upper limits on the number of sensor models and instances. This is allowed to make it possible to provide alternate sets of sensor models. For example, for a
frame camera sensor one may provide a physics-based sensor model or instead a so- called “replacement model” where the details of the sensor are missing. The dependent
SensorML document is required to use the sml:typeOf element to specify a primary sensor model document and by doing so keep the connection between the pair of
SensorML documents clear.
Please see Annex 2 of this ER for an example of use.
