5.1 Abbreviated terms

The following symbols and abbreviated are used in this standard;

ALT

 ALTimetry

ATM

ATMospheric

CF

  Climate and Forecast

EO

  Earth Observation

EOP

  Earth Observation Product

GML

  Geography Markup Language

HMA

  Heterogeneous Missions Accessibility

LMB

  LiMB looking

OGC

  Open Geospatial Consortium

OPT

  OPTical

O&M

  Observations and Measurements

PHR

   Pleiades High Resolution

SAR

   Synthetic Aperture Radar

SSP

   Synthesis and Systematic Product

XML

   eXtensible Markup Language

5.2    Namespace prefix conventions

The namespace prefixes used in this document are not normative and are merely chosen for convenience; they may appear in examples without being formally declared, and have no semantic significance. The namespaces to which the prefixes correspond are normative, however.

6.    Conceptual Model

This section focuses on the purpose and requirements for this standard. In particular, the document describes the model of the Earth Observation Metadata defined as a profile of Observations and Measurements.

6.1    General concepts

The approach consists in modelling EO product metadata as a profile of Observations and Measurements – XML Implementation [OGC 10-025r1]. ISO definitions are specified for attributes where available, although not the full ISO schema is used for the structural definitions, which would lead to a less efficient overall structure.

The general mechanism is to create a schema with a dedicated namespace for each level of specificity from a general description which is common to each EO Product to a restricted description for specific mission EO Products. Each level of specificity is an extension of the previous one.

The general EO product schema is the main application schema for EO Product metadata. It is associated with the “eop” namespace.

Each Thematic EO product schema extends the “eop” schema.

• The Optical EO Product schema is used to describe optical products. It is associated with the “opt” namespace.
• The SAR EO Product schema is used to describe radar products. It is associated with the “sar” namespace.
• The Atmospheric EO Product schema is used to describe atmospheric products. It is associated with the “atm” namespace.
• The Altimetry EO Product schema is used to describe altimetry products. It is associated with the “alt” namespace.
• The Limb Looking EO Product schema is used to describe limb looking products. It is associated with the “lmb” namespace.
• The Synthesis and Systematic EO Product schema is used to describe “Synthesis and Systematic” products. It is associated with the “ssp” namespace.

The idea behind this layered levels approach is to create an efficient schema set that describes EO Product metadata concentrating on the core metadata characteristics that differentiate an EO product within a collection.

The adoption of this layered schema structure is intended to facilitate the realization of clients / viewers that understand the schema at various levels.  For example, since this profile extends GML and O&M, our products can be displayed by a generic GML viewer, which will see EO Products as features with a footprint and “unknown” metadata, or by an EO Product specific viewer, which will understand the semantics of these metadata (cf. Figure 1)

More precisely, a generic GML viewer capable of handling O&M will only understand the “O&M” vocabulary of the O&M document; a “Generic EO Products viewer” will understand the “O&M” and “eop” vocabulary of the O&M document; an “Optical EO Products viewer” will understand the “O&M”, “eop” and “opt” vocabulary of the O&M document. Mission specific vocabulary will only be understood by a “Specific Mission Viewer”.

6.2    Observations & Measurements

In natural language, the model states:

An observation is an event that estimates an observed property of some feature of interest using a specified procedure and generates a result.

The quantity to be measured can be simple (a single temperature), or it may be a complex quantity such as a coverage. Remotely sensed images in the sense of their acquisition can be viewed as observations in which the result of the observation (value of the result property) is a remotely-sensed image product.

The major elements of the model are indicated in bold and modelled through associations in the UML model. In addition, an observation has the following attributes and associations.

• parameter (optional): for arbitrary event-specific parameters, e.g. instrument settings.
• phenomenonTime (mandatory): the time that the result applies to the feature of interest.
• resultQuality (optional): the quality of the result.
• resultTime (mandatory): the time when the result becomes available (e.g. if postprocessing or laboratory analysis is required, it might be different to the phenomenonTime).
• validTime (optional): the time period during which the result is intended to be used (e.g. if a meteorological forecast is modelled as an observation, then it is intended to be used during a specific period of time).
• relatedObservation (optional): related observations providing important context for understanding the result.
• metadata (optional): descriptive metadata.
• featureOfInterest(mandatory):The association Domain shall link the OM_Observation to the GFI_Feature that is the subject of the observation and carries the observed property. This feature has the role featureOfInterest with respect to the observation.
• observedProperty (mandatory): The association Phenomenon shall link the OM_Observation to the GFI_PropertyType for which the OM_Observation:result provides an estimate of its value. The property type has the role observedProperty with respect to the observation.
• result: The association Range shall link the OM_Observation to the value generated by the procedure. The value has the role result with respect to the observation.
• procedure: The association ProcessUsed shall link the OM_Observation to the OM_Process (6.2.3) used to generate the result. The process has the role procedure with respect to the observation.

6.3    Earth Observation metadata mapping on Observations and Measurements

To represent Earth Observation metadata, this profile extends the Observations and Measurements properties with EO specific information. Table 2 defines the awaited content of each Observations and Measurements property. Figure 3 shows the relationship of EarthObservation and EarthObservationEquipment to O&M.

6.3.1    Observed property

The ‘observed property’ is mandatory for OM_Observation.

• The standard XML encoding of observedProperty is a gml:ReferenceType. 
• It may be null with a nilReason if required, e.g. <om:observedProperty nilReason=“inapplicable”/>.
• If there is a parameter property present within the EarthObservationResult then the observed property should point using xlink to the Phenomenon definition that is included as part of the eop:ParameterInformation. 
• If there is no parameter property present and the observedProperty is not left null, then the observedProperty should be an xlink to the observedPropery definition. The code list that is mandated is the NETCDF CF Standard names. An example of an Observed Property from this code list is:

<om:observedProperty xlink:href=“http://cf-pcmdi.llnl.gov/documents/cf-standard-names/standard-name-table/15/cf-standard-name-table.xml#sea_surface_height_above_sea_level”/>.

6.3.2    Result time

The OM_Observation ‘resultTime’ is the time at which the result became available. In general, this may be different to the ‘phenomenonTime’, which is the geophysically relevant time at which the final product applies. The times may be different when additional processing is performed to retrieve geophysical parameters.

6.4    General recommendations

When creating the Earth Observation Metadata profile, a set of principles was followed. It is recommended that a mission specific extension of this profile follows these same principles.

6.4.1    Language recommendation

Natural language is used as far as possible for property names. For instance, complete names for properties are preferred to abbreviations.

6.4.2     Extensions

As seen in §6.3, each Earth Observation product fits exactly the structure of an OM_Observation element.

Thus, in the inheritance mechanism for thematic or mission specific namespaces, it is needed to extend existing properties defined in the eop namespace or create new properties that fit inside the model.

6.4.2.1    Thematic extended namespace

Thematic extended namespace (opt for example) contains:

• opt “words”;
• an opt:EarthObservation element that inherits from eop:EarthObservation.This inheritance is an XML schema extension (to avoid restriction problems) with no elements added (because all elements fit inside one of the Observation properties metadata, procedure, phenomenonTime, result or featureOfInterest); 
• one or more extensions of existing eop properties (see example below).

For example, “opt” thematic EO Products metadata include the cloud cover percentage, named “cloudCoverPercentage”. This property is described within the opt:EarthObservationResultTypeelement which extends and acts as a substitution for eop: EarthObservationResultType:

<opt:EarthObservation>
      […]
      <om:result>
           <opt:EarthObservationResult gml:id=“eop_2”> >
                […]
                <opt:cloudCoverPercentage uom=“%” >30</opt:cloudCoverPercentage>                               
                         […]
           </opt: EarthObservationResult >
      </om:result>
               […]
               </opt: EarthObservation>

6.4.2.2    Mission specific extended namespace

A mission specific extended namespace contains the following.

• Mission-specific “words.”
• A mission specific EarthObservation  element that inherits from for instance sar:EarthObservation.This inheritance is an XML schema extension (to avoid restriction problems) with no element added (because all elements fit inside one of the Observation property metadata, procedure, phenomenonTime, result or featureOfInterest).
• One or more extensions of existing sar properties.

These principles are close to those described for the thematic extended namespace. However, the property extension approach leads to a drawback in the mission specific case.

Indeed, from a client point of view, an “eop” enabled reader must encounter well-known structures under “eop” properties. This is not a problem for the “eop” and thematics schemas since they are completely described in this document (i.e. structure can be “hard coded” in the client).  For mission specific schema however, the specific schema is not in the scope of this document.

Thus, in order for a generic “eop” enabled reader to “understand” such mission specific metadata, it should be able to process complex schema inheritance mechanisms.

To avoid this drawback, we introduce an attribute "eop:type" at the eop level. This attribute is required for properties that extend one of eop or its thematic properties. This attribute is expected to contain the name of the property it extends directly. This mechanism is comparable to the ISO19139 gco:isoType.

6.4.3    Units of measure

Each non-angle property concerned by a unit of measure is recommended to use the existing GML type <gml:MeasureType>.

Example : resolution

     <xs:element name="resolution" type="gml:MeasureType">
          <xs:annotation>
               <xs:documentation> resolution</xs:documentation>
          </xs:annotation>
     </xs:element>

Each angle property is recommended to use the existing GML type <gml:AngleType>.

Example : Instrument Across Track incidence angle

     <xs:element name="instrumentAcrossTrackIncidenceAngle " type="gml:AngleType" minOccurs="0">
               <xs:annotation>
                    <xs:documentation>Instrument across track Incidence angle given in degrees.</xs:documentation>
               </xs:annotation>
     </xs:element>

6.4.4    GML restrictive use

The use of GML types is restricted to those relevant to the EO Products metadata description, i.e.:

• gml:AngleType;
• gml:CodeListType;
• gml:MeasureType;
• gml:MeasureListType;
• gml:UnitOfMeasureType;
• gml:ReferenceType;
• gml:Point (expected structure : gml:Point/gml:pos);
• gml:MultiSurface (expected structure : gml:MultiSurface/gml:surfaceMembers/gml:Polygon/gml:exterior/gml:LinearRing/gml:posList);
• gml:TimePeriod; and
• gml:TimeInstant.

7.    Requirements for XML Instances

To allow exchange of metadata, the conceptual model described in the previous section must be encoded in XML.

As a profile of Observations and Measurements, this document provides XML schemas that extend Observations and Measurements for XML. To generate these schemas, we adopted the model-driven approach of ISO TC211. This approach is described in Annex D.

This section constitutes the core requirements class for all XML instances of the Earth Observation Metadata profile of Observations and Measurements.

XML representations of earth observation metadata requires the use of the element eop:EarthObservation or a member of its substitution group.

There is a dependency on the requirements classes for Observations and Measurements documents, defined in Clause 7.3 of [OGC 10-025r1].

8.    EO Products schemas

8.1    General EO product data schema

The “eop” schema provides the description of metadata common to all EO Products derived from satellite based remote sensing.

The root element of the “eop” schema, named <eop:EarthObservation> extends the <om:OM_Observation> type as follows :

<element name=“EarthObservation” substitutionGroup=“om:OM_Observation” type=“eop:EarthObservationType”/>
    <complexType name=“EarthObservationType”>
        <complexContent>
            <extension base=“om:OM_ObservationType”>
                <sequence>
                    <element name=“metaDataProperty” type=“eop:EarthObservationMetaDataPropertyType”/>
                    <element name=“version” type=“string”/>
                </sequence>
            </extension>
        </complexContent>
    </complexType>       

The “EarthObservation” element contains a mandatory “version” attribute that references the schema version number.

The “eop” metadata are referenced inside higher level structure (see Table 2):

• eop:EarthObservationMetaData;
• eop:EarthObservationEquipment;
• eop:Footprint; and
• eop:EarthObservationResult.

A complete description of an EarthObservation element is given in Table 4.

8.1.1    EarthObservationMetaData

The eop:EarthObservationMetaData block contains all the metadata relative to an eop:EarthObservation that do not fit inside one of the other blocks, i.e. metadata that do not describe the time, the mechanism, the location or the result of the observation.