Instrument Capabilities Document

This section introduces the parts of an Instrument Capabilities that are common to all three sentinels. The following examples are extracted from the SPOT5 HRG instrument instance. Separate pages describe the specifics of each sentinel profile.

Overall structure of the document type

The overall structure of a Platform Capabilities document is show below:

<sml:SensorML
   xmlns:sml="http://www.opengis.net/sensorML/1.0.1" 
   xmlns:swe="http://www.opengis.net/swe/1.0.1"
   xmlns:gml="http://www.opengis.net/gml"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   xmlns:xlink="http://www.w3.org/1999/xlink"
   version="1.0.1">
   <!-- -->
   <sml:member xlink:role="urn:ogc:def:dictionary:CEOS:documentRoles:v01#instrument_capabilities">
      <sml:System gml:id="LOCAL_INSTRUMENT_ID">
         <gml:description ... />
         <sml:identification ... />
         <sml:classification ... />
         <sml:validTime ... />
         <sml:characteristics xlink:role="urn:ogc:def:role:CEOS:eop:GeometricCharacteristics" ... />
         <sml:characteristics xlink:role="urn:ogc:def:role:CEOS:eop:MeasurementCharacteristics" ... />
         <sml:characteristics xlink:role="urn:ogc:def:role:CEOS:eop:PhysicalCharacteristics" ... />
         <sml:characteristics xlink:role="urn:ogc:def:role:CEOS:eop:InstrumentConfigurations" ... />
         <sml:contact xlink:role="urn:ogc:def:role:OGC:contact:distributor" ... />
         <sml:documentation xlink:role="urn:ogc:def:role:OGC:document:datasheet" ... />
         <sml:inputs ... />
         <sml:components ... />
      </sml:System>
   </sml:member>
   <!-- -->
</sml:SensorML>

The "description" element allows the inclusion of a humanly readable text describing the Instrument, its strength, design particularities, etc...

The "Geometric Characteristics" and "Measurement Characteristics" sections are different in each sentinel and are thus described on separate pages.

All other sections are detailed in the following paragraphs.

Identification Section

Below is a typical identification section for an EO instrument:

<sml:identification>
   <sml:IdentifierList>
      <sml:identifier name="Instrument UID">
         <sml:Term definition="urn:ogc:def:property:CEOS:eop:InstrumentID">
            <sml:value>urn:ogc:id:CEOS:instrument:SPOT5:HRG1:v01</sml:value>
         </sml:Term>
      </sml:identifier>
      <sml:identifier name="Platform UID">
         <sml:Term definition="urn:ogc:def:property:CEOS:eop:PlatformID">
            <sml:value>urn:ogc:id:CEOS:platform:SPOT5:v01</sml:value>
         </sml:Term>
      </sml:identifier>
      <sml:identifier name="Short Name">
         <sml:Term definition="urn:ogc:def:property:OGC:shortName">
            <sml:value>SPOT-5 HRG1</sml:value>
         </sml:Term>
      </sml:identifier>
      <sml:identifier name="Long Name">
         <sml:Term definition="urn:ogc:def:property:OGC:longName">
            <sml:value>Spot-5 High Resolution Geometric 1</sml:value>
         </sml:Term>
      </sml:identifier>
   </sml:IdentifierList>
</sml:identification>

• Instrument UID: Identifies the Instrument by its unique ID, so that several documents describing the different aspects of the same system (capabilities, configuration, calibration...) can be related through this UID. Instrument Unique IDs should preferably all use the same URN structure: urn:ogc:id:CEOS:instrument:[''platform_name'']:[''instrument_name'']:v[''version_number''].

• Platform UID: Identifies the Platform to which this system is attached by its unique ID. Platform Unique IDs should preferably all use the same URN structure: urn:ogc:id::platform:[platform_name]:v[version_number].

• Short Name: Gives the short name of the Instrument. This is usually an acronym. It is usually useful to include the Platform name in the Instrument name for easier understanding.

• Long Name: Gives the complete name of the Instrument. If the Instrument is usually refered to with an acronym, this field should give the full name (spelled completely).

Each identifier has the structure shown by the following snippet:

<sml:identifier name="Short Name">
   <sml:Term definition="urn:ogc:def:identifierType:OGC:shortName">
      <sml:value>SPOT-5 HRG1</sml:value>
   </sml:Term>
</sml:identifier>

This structure has a syntax where each element/attribute has a very specific meaning.

• The name attribute should be used by tools for display only and not be taken as carrying any semantic meaning.
• The definition attribute has the semantic role and that is why it takes a URN as a value. This URN can be resolved in order to obtain the full description of the field contained in a dictionary. In the case of an identifier the definition attribute should point to the definition of an identifierType explaining what type of identifier the field represents. This is useful to be able to identifiy a system by different means (i.e. UID vs. Short Name vs. Long Name).
• The value element carries the actual value used for identification.

Classification Section

Below is a typical classification section for an EO instrument:

<sml:classification>
   <sml:ClassifierList>
      <sml:classifier name="Instrument Type">
         <sml:Term definition="urn:ogc:def:property:OGC:sensorType">
            <sml:codeSpace xlink:href="urn:ogc:def:dictionary:CEOS:eop:InstrumentTypes:v01"/>
            <sml:value>Imaging Multispectral Radiometer</sml:value>
         </sml:Term>
      </sml:classifier>
      <sml:classifier name="Acquisition Method">
         <sml:Term definition="urn:ogc:def:property:OGC:sensorType">
            <sml:codeSpace xlink:href="urn:ogc:def:dictionary:CEOS:eop:AcquisitionMethods:v01"/>
            <sml:value>Pushbroom</sml:value>
         </sml:Term>
      </sml:classifier>
      <sml:classifier name="Application">
         <sml:Term definition="urn:ogc:def:property:OGC:application">
            <sml:codeSpace xlink:href="urn:ogc:def:dictionary:CEOS:eop:InstrumentApplications:v01"/>
            <sml:value>Land - Multi-purpose Imagery</sml:value>
         </sml:Term>
      </sml:classifier>
   </sml:ClassifierList>
</sml:classification>

• Instrument Type: Classifies the Instrument according to the CEOS classification defined by the codespace. (You can view the GML dictionary document defining this codespace (through a stylesheet): urn:ogc:def:dictionary:CEOS:eop:InstrumentTypes:v01).

• Acquisition Method: Classifies the Instrument according to one of the acquisition methods defined by the codespace. (You can view the GML dictionary document defining this codespace (through a stylesheet): urn:ogc:def:dictionary:CEOS:eop:AcquisitionMethods:v01).

• Application: One or more application classifiers classify the Instrument according to one or more applications as defined by the codespace. (You can view the GML dictionary document defining this codespace (through a stylesheet): urn:ogc:def:dictionary:CEOS:eop:InstrumentApplications:v01).

Each classifier has the structure shown by the following snippet:

<sml:classifier name="Acquisition Method">
   <sml:Term definition="urn:ogc:def:property:OGC:sensorType">
      <sml:codeSpace xlink:href="urn:ogc:def:dictionary:CEOS:eop:AcquisitionMethods:v01"/>
      <sml:value>Pushbroom</sml:value>
   </sml:Term>
</sml:classifier>

• The name, definition and value have the same meaning as for an identifier
• The codeSpace element references a code space via the href attribute. This resolves to a dictionary that defines the list of possible choices that are allowed in this classifier.

ValidTime Section

This section allows the specification of a temporal validity time range that applies to the document. The example below shows a typical validity period of such a document:

<sml:validTime>
    <gml:TimePeriod>
        <gml:beginPosition>2002-05-04T00:00:00Z</gml:beginPosition>
        <gml:endPosition indeterminatePosition="now"/>
    </gml:TimePeriod>    
</sml:validTime>

For Platform Capabilities and Instrument Capabilities documents, the validity period usually goes from the launch date to today (indicated by 'now') or the end of the life of the satellite. It can however be different if one of the on-board systems has limited functionality due to some incident. When an incident occurs, a new document can thus be created with a validity period going from the date of the incident to 'now'. The old document should be archived (perhaps for use with older products generated before the incident) with a validity period ending at the date of the incident.

Physical Characteristics Section

Below is a typical physical characteristics section for an EO instrument:

<sml:characteristics xlink:role="urn:ogc:def:role:CEOS:eop:PhysicalCharacteristics">
   <swe:DataRecord>
      <gml:name>Physical Characteristics</gml:name>
      <swe:field name="Mass">
         <swe:Quantity definition="urn:ogc:def:property:OGC:mass">
            <swe:uom code="kg"/>
            <swe:value>356</swe:value>
         </swe:Quantity>
      </swe:field>
      <swe:field name="Maximum Power Consumption">
         <swe:Quantity definition="urn:ogc:def:property:CEOS:eop:MaximumPowerConsumption">
            <swe:uom code="W"/>
            <swe:value>344</swe:value>
         </swe:Quantity>
      </swe:field>
   </swe:DataRecord>
</sml:characteristics>

This shows only a small set of the properties that could be included in a SensorML document describing an EO instrument, as an example.

Each field uses a SWE Common component (Quantity for numerical values, Category for categorical values, Count for integer countable values, Text, etc.) to give the value of a given physycal property of the Instrument.

The name and definition are here used in the same way as with the identifiers or classifiers.

When the field is of type Quantity, a unit of measure (i.e. uom) should also be specified using a UCUM code as defined in the SWE Common Data Model OGC standard.

More physical characteristics can be added provided they are assigned a URN and well defined in an online accessible dictionary (i.e. GML) or ontology (i.e. OWL).

Instrument Configurations Section

A list of possible instrument configurations should be given if the instrument has several modes of operation.

<sml:characteristics xlink:role="urn:ogc:def:role:CEOS:eop:InstrumentConfigurations">
   <swe:DataRecord>
      <gml:name>Possible Instrument Configurations</gml:name>
      <swe:field name="PA Mode">
         <swe:Category definition="urn:ogc:def:property:CEOS:eop:InstrumentMode">
            <swe:value>urn:ogc:id:CEOS:instrument:SPOT5:HRG:PA-HMA:v01</swe:value>
         </swe:Category>
      </swe:field>               
      <swe:field name="PA+XS Mode">
         <swe:Category definition="urn:ogc:def:property:CEOS:eop:InstrumentMode">
            <swe:value>urn:ogc:id:CEOS:instrument:SPOT5:HRG:PA+XS:v01</swe:value>
         </swe:Category>
      </swe:field>
      <swe:field name="PA Super Mode">
         <swe:Category definition="urn:ogc:def:property:CEOS:eop:InstrumentMode">
            <swe:value>urn:ogc:id:CEOS:instrument:SPOT5:HRG:PA-Super:v01</swe:value>
         </swe:Category>
      </swe:field>
      <swe:field name="PA+XS Super Mode">
         <swe:Category definition="urn:ogc:def:property:CEOS:eop:InstrumentMode">
            <swe:value>urn:ogc:id:CEOS:instrument:SPOT5:HRG:PA+XS-Super:v01</swe:value>
         </swe:Category>
      </swe:field>
   </swe:DataRecord>
</sml:characteristics>

Each mode is uniquely identified by a URN and is fully described in a separate Instrument Configuration document. The given URNs should be resolvable to those documents.

Contact Section(s)

An Instrument Capabilities document can contain one or more contact:

<sml:contact xlink:role="urn:ogc:def:role:OGC:contact:operator">
    <sml:ResponsibleParty>
        <sml:individualName>Didier Giacobbo</sml:individualName>
        <sml:organizationName>Spot-Image</sml:organizationName>               
        <sml:contactInfo>
            <sml:phone>                
                <sml:voice>+33 5 62 19 42 52</sml:voice>
            </sml:phone>
            <sml:address>
                <sml:deliveryPoint>5, rue des satellites, BP 4359</sml:deliveryPoint>
                <sml:city>TOULOUSE, Cedex 4</sml:city>
                <sml:postalCode>31030</sml:postalCode>
                <sml:country>FRANCE</sml:country>                
            </sml:address>
        </sml:contactInfo>
    </sml:ResponsibleParty>
</sml:contact>

This structure can be repeated as many times as necessaey to specify contacts with different roles (i.e. operator, distributor, manufacturer, etc.) that are related to the system being described.

Instrument Components

As discussed above, an Instrument is sometimes composed of several Detectors, that can all be listed in this section.

<sml:components>
   <sml:ComponentList>
      <sml:component name="HMA Detector" xlink:href="Detector_SPOT5-HRG-HMA_v01_draft03.xml#HRG-HMA"/>
      <sml:component name="HMB Detector" xlink:href="Detector_SPOT5-HRG-HMB_v01_draft03.xml#HRG-HMB"/>
      <sml:component name="XS1 Detector" xlink:href="Detector_SPOT5-HRG-XS1_v01_draft03.xml#HRG-XS1"/>
      <sml:component name="XS2 Detector" xlink:href="Detector_SPOT5-HRG-XS2_v01_draft03.xml#HRG-XS2"/>
      <sml:component name="XS3 Detector" xlink:href="Detector_SPOT5-HRG-XS3_v01_draft03.xml#HRG-XS3"/>
      <sml:component name="SWIR Detector" xlink:href="Detector_SPOT5-HRG-SWIR_v01_draft03.xml#HRG-SWIR"/>
   </sml:ComponentList>
</sml:components>

It is recommended to not include the Detector descriptions inline in the Instrument Capabilities document but to reference an external document via an xlink. This allows reusing the same documents when describing Instrument Configurations.

Each Detector (included inline or by reference in the previous structure) must have the following structure:

<sml:Component gml:id="HRG-HMA">
   <gml:description ... />
   <sml:identification ... />
   <sml:characteristics xlink:role="urn:ogc:def:role:CEOS:eop:GeometricCharacteristics" ... />
   <sml:characteristics xlink:role="urn:ogc:def:role:CEOS:eop:MeasurementCharacteristics" ... />
</sml:Component>

The identification section is similar to that of an Instrument description. Details of the "Geometric Characteristics" and "Measurement Characteristics" are different for each sentinels and thus detailed on the corresponding sections.

-- AlexandreRobin - 01 Feb 2008