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.

These metadata are mainly the EarthObservation identifier, the acquisition type and information relative to the downlink and archiving centers. The complete description of the EarthObservationMetaData is given in Table 5.

8.1.1.1    Resource identifiers

The primary purpose of the identifier is to allow operations on a resource without ambiguities. For that reason, it is important to have a totally unique identifier that will never be generated twice by any system. This identifier will be used throughout the process of manipulating the product, from tasking to ordering.

8.1.2    EarthObservationEquipment

The eop:EarthObservationEquipment block contains metadata relative to the mechanism used during the EarthObservation.

These metadata describe on one hand the platform, instrument and sensor used for the EarthObservation, and, on the other hand, the acquisition parameters of this observation. Complete description of the EarthObservationEquipment is given in Table 6.

8.1.3    Footprint

The eop:Footprint block contains the description of  the target location observed during the EarthObservation.

Complete description of  eop:Footprint is given in Table 7.

8.1.4    EarthObservationResult

The eop:EarthObservationResult block contains the description of the result of the EarthObservation.

Complete description of eop:EarthObservationResult is given in Table 8

The coverage element is foreseen in order to have the possibility to reference additional “exploitation” metadata of the EO Product.
This exploitation metadata consists of detailed information on the spatial domain of the EO product (origin, offset vectors, grid envelope, axis labels) and the Range Structure (information on the available bands with their names, units of measure, data type and nill value list). As this type of metadata is already defined by the GML 3.2 Application Schema for WCS 2.0 (OGC09-146) that is used within the wcs:CoverageDescriptions Element, it is proposed to let the coverage element defined in this specification refer to a wcs:CoverageDescriptions element that is returned in response to a WCS DescribeCoverage Request. In case the EO Product is offered by a WCS service, this proves a convenient manner to offer this type of metadata without duplicating the information. In case the product isn’t offered by a WCS Service, an alternative HTTP GET URL could be used.

An example of the use of the coverage element is:

<eop:coverage xlink:href="http://hma.xxx.xx/wcseoserver/ows?Service=WCS&amp;Version=2.0.0&amp;Request=DescribeCoverage&amp;coverageId=coverageId"/>

8.2    Thematic EO product data schema

The Thematic EO Product schemas provide the description of metadata common to a specific thematic category of EO Products. Thematic EO Products schemas extend the “eop” schema.

8.2.1    Optical EO Product data schema

The “opt” schema provides the description of metadata common to all EO Products derived from optical satellite based remote sensing. It describes the same fields as the “eop” schema plus specific fields for optical products.

As described in §6.4.2.1, the root element of the “opt” schema, named <opt:EarthObservation> simply extends the <eop:EarthObservationType> type (with no element added) :

          <xs:element name="EarthObservation" type="opt:EarthObservationType"
                            substitutionGroup="eop:EarthObservation"/>
         
          <xs:complexType name="EarthObservationType">
               <xs:complexContent>
                    <xs:extension base="eop:EarthObservationType">
                         <xs:sequence/>
                    </xs:extension>
               </xs:complexContent>
          </xs:complexType>

One property is extended from the eop schema :

• opt:EarthObservationResult extends eop:EarthObservationResult

8.2.2    Radar EO Product data schema

The “sar” schema provides the description of metadata common to all EO Products derived from radar satellite based remote sensing. It describes the same fields as the “eop” schema plus radar specific fields.

As described in §6.4.2.1, the root element of the “sar” schema, named <sar:EarthObservation> simply extends the <eop:EarthObservationType> type (with no element added) :

          <xs:element name="EarthObservation" type="sar:EarthObservationType"
                            substitutionGroup="eop:EarthObservation"/>
         
          <xs:complexType name="EarthObservationType">
               <xs:complexContent>
                    <xs:extension base="eop:EarthObservationType">
                         <xs:sequence/>
                    </xs:extension>
               </xs:complexContent>
          </xs:complexType>

One property is extended from the eop schema :

• sar:Acquisition extends eop:Acquisition (Table 10).

8.2.3    Atmospheric EO Product data schema

The “atm” schema provides the description of metadata common to all EO Products derived from atmospheric based remote sensing. It describes the same fields as the “eop” schema plus atmospheric specific fields.

As described in §6.4.2.1, the root element of the “atm” schema, named <atm:EarthObservation> simply extends the <eop:EarthObservationType> type (with no element added) :

          <xs:element name="EarthObservation" type="atm:EarthObservationType"
                            substitutionGroup="eop:EarthObservation"/>
         
          <xs:complexType name="EarthObservationType">
               <xs:complexContent>
                    <xs:extension base="eop:EarthObservationType">
                         <xs:sequence/>
                    </xs:extension>
               </xs:complexContent>
          </xs:complexType>

One property is extended from the eop schema :

• atm:EarthObservationResult extends eop:EarthObservationResult (Table 11).

8.2.4    Altimetry EO Product data schema

The “alt” schema provides the description of metadata common to all EO Products derived from radar altimeter based remote sensing. It describes the same fields as the “eop” schema plus altimetry specific fields.

As described in §6.4.2.1, the root element of the “alt” schema, named <alt:EarthObservation> simply extends the <eop:EarthObservationType> type (with no element added) :

          <xs:element name="EarthObservation" type="alt:EarthObservationType"
                            substitutionGroup="eop:EarthObservation"/>
         
          <xs:complexType name="EarthObservationType">
               <xs:complexContent>
                    <xs:extension base="eop:EarthObservationType">
                         <xs:sequence/>
                    </xs:extension>
               </xs:complexContent>
          </xs:complexType>

Four properties are extended from the eop schema:

• alt:EarthObservationEquipmentextends eop:EarthObservationEquipment([Table 12]);
• alt:Footprintextends eop:Footprint([Table 13]).
• alt:ProcessingInformationextends eop:ProcessingInformation([Table 14]).
• alt:Acquisitionextends eop:Acquisition ([Table 15]).

8.2.5    Limb Looking EO Product data schema

The “lmb” schema provides the description of metadata common to all EO Products derived from limb looking based remote sensing. It describes the same fields as the “eop” schema plus limb looking specific fields.

As described in §6.4.2.1, the root element of the “lmb” schema, named <lmb:EarthObservation> simply extends the <eop:EarthObservationType> type (with no element added) :

          <xs:element name="EarthObservation" type="lmb:EarthObservationType"
                            substitutionGroup="eop:EarthObservation"/>
                                                           
          <xs:complexType name="EarthObservationType">
               <xs:complexContent>
                    <xs:extension base="eop:EarthObservationType">
                         <xs:sequence/>
                    </xs:extension>
               </xs:complexContent>
          </xs:complexType>

Three properties are extended from the eop schema:

• lmb:Footprintextends eop:Footprint([Table 16]).
• lmb:Sensorextends eop:Sensor([Table 17]).
• lmb:Acquisitionextends eop:Acquisition([Table 18]).

8.2.6    Synthesis and Systematic EO Product data schema

Synthesis (or composite) products are products that are generated by combining information from multiple EO Products that are acquired over a certain period of time. 

Examples of synthesis products are

• SPOT VGT derived products as 10-Daily Mean Value Composite synthesis (VGT S10) or 10-Daily BiDirectional Composite synthesis (VGT D10)
• MODIS/Terra 16 day Maximum Value Composite

The “ssp” schema provides the description of metadata common to all EO Products derived from Synthesis and Systematic products. It describes the same fields as the “eop” schema plus Synthesis and Systematic specific fields.

As described in §6.4.2.1, the root element of the “ssp” schema, named <ssp:EarthObservation> simply extends the <eop:EarthObservationType> type (with no element added) :

          <xs:element name="EarthObservation" type="ssp:EarthObservationType"
                            substitutionGroup="eop:EarthObservation"/>
                                                           
          <xs:complexType name="EarthObservationType">
               <xs:complexContent>
                    <xs:extension base="eop:EarthObservationType">
                         <xs:sequence/>
                    </xs:extension>
               </xs:complexContent>
          </xs:complexType>

Four properties are extended from the eop schema:

• ssp:Footprintextends eop:Footprint([Table 19]);
• ssp:EarthObservationEquipmentextends eop:EarthObservationEquipment([Table 20]);
• ssp:EarthObservationResultextends eop:EarthObservationResult([Table 21]); and
• ssp:EarthObservationMetaDataextends eop:EarthObservationMetaData([Table 22]).

Annex : Conformance Class Abstract Test Suite (Normative)

A.1     Conformance class: Generic observation data

This is the core conformance class for all XML metadata instances compliant with the Earth Observation Metadata profile of Observations and Measurements.

There is a dependency on the conformance class for Observations and Measurements documents, defined in Clause 7.3 and Annex A.1 of [OGC 10-025r1].

Annex : Examples (informative)

The associated “XML Examples” contains six example XML documents:

• eop_example.xml
• opt_example.xml
• alt_example.xml
• lmb_example.xml
• ssp_example.xml
• sar_example.xml

They are available at http://schemas.opengis.net/eompom/1.1/. 

Annex : Background to Standardisation of EO product metadata (informative)

This annex contains background information related to the development of this specification. It explains the past approach based on gml:observations and the evolution to Observations and Measurements.

Past approach

In the frame of the initial Heterogeneous Missions Accessibility -Interoperability (HMA-I) project, ESA together with other GMES participating agencies as ASI, CNES, CSA-MDA, and DLR decided to model the metadata of Earth Observation products as geographic features encoded in the OGC Geographic Markup Language. 

The reasoning for adopting gml instead of a more traditional approach using the ISO19115 Geographic Information Metadata model was the fact that the ISO 19115 elements are more suited for describing the metadata of collections of EO Products rather than for describing individual EO products themselves: 

• Typical mandatory ISO 19115 metadata elements like contactInformation (gmd:Contact), citation and abstract (MD_dataIdentication) constitute information that will be identical for each individual product in the collection.  It does not make a lot of sense to repeat these elements in every product metadata record. The complexity of the overall ISO19115 model with deep nesting of elements leads to a less efficient data structure for web access.
• On the other hand specific metadata elements like for instance cloud cover are required to allow for efficient discovery of EO products.  In case ISO19115 would have been selected, such elements would have needed to be added to a non-comprehensive profile extension of ISO19115 which would anyway have been specific to the HMA community. 

Instead of choosing this clearly sub-optimal ISO19115 approach, it was agreed to model EO Product metadata as a geographic feature characterised by a footprint and a set of attributes. As the specification document [OGC 06-080r4] states:” From an end user point of view, an EO data product can be naturally described by a spatial extent (e.g. the geographic footprint of a satellite acquisition) and several attributes describing the metadata (e.g. date of acquisition, etc.)”.  The encoding language for describing geographic features is the Geography Markup Language as standardised by the OGC and further adopted as ISO19136.

The GML application schema for Earth Observation Products was developed during a consensus process in which a mapping was done between metadata elements from the different partners on to a harmonised set of elements.  Where possible, the element names were taken from corresponding element names within the ISO19115 [ISO 19115:2003] and ISO19115 Part 2 [ISO 19115-2:2009] standards.

The metadata was initially modelled as features (extending <gml:AbstractFeature>) and later on refined as gml:observations.

All metadata elements common to all Earth Observation products were defined within an Earth Observation Product (eop) GML application schema (formerly known as hma schema).  Specific metadata elements for optical radar and atmospheric products, were assigned to three specific application schemas deriving (respectively opt, sar and atm) from the base eop schema.  For products of specific missions requiring further metadata elements for their descriptions, it is possible to define a specific application schema deriving from one of the thematic application schemas. 

Evolutions of the Standards baseline

In the continuation of the Heterogeneous Missions Accessibility (HMA) project, the HMA Follow on (HMA-FO) project proposed to extend the EO product metadata to address radar altimeter, limb looking and synthesis/systematic products and some minor improvements to the base schema.

Besides the schema extensions for the new product types, it is beneficial to evaluate the underlying standards baseline. 

Adoption of GML 3.2.1

Since the initial work on the GML Application Schema for EO Products in 2006, the base GML 3.1.1 specification of which [OGC 06-080r4] is an application schema has been superseded by a newer version.  GML 3.2.1 [OGC 07-036] is now the official OGC GML Implementation Specification since July 2007.  It was therefore logical to align this new version of the specification with GML 3.2.1 which is also used within O&M and WCS 2.0.

Observations and Measurements

Over almost ten years, OGC has been developing a richer conceptual model for observations and measurements within the ISO standard 19156 “Geographic Information – Observations and Measurements” [OGC 10-004r3].

In view of this the existing gml:Observation will be deprecated and replaced by the ISO model.

The differences between the two models are not major, with the ISO model adding the following mandatory properties to the GML model:

• the observed property and
• the result time (which in general may be different to the phenomenonTime).

To adopt the standard OM_Observation (ISO 19156), minimal refactoring is required by replacing the GML observation properties with their equivalent.

Annex : Model Driven Approach (informative)

It was proposed, for extending the ‘GML Application Schema for EO Products’ to adopt the model-driven approach of ISO TC211, illustrated in Figure 4 below.

In this approach, a universe of discourse is modelled formally as a conceptual model in a UML application schema using the General Feature Model of ISO 19109 [ISO 19109:2005]. Feature types may be registered in a feature catalogue specified within ISO 19110 [ISO 19110:2005] for re-use (e.g. as part of other application schemas, through association or generalisation), thus aiding interoperability.

From the UML model, a canonical XML encoding may be generated automatically, providing a GML application schema as per OGC 07-036/ISO 19136 [OGC 07-036]. Exchange datasets containing feature instances may then be transformed from existing (legacy) database or other storage into an XML document conforming to the GML application schema.

Usually these GML instances are accessed through a Web Feature Service as specified in ISO 19142 [ISO 19142].

In the case of the ‘GML Application Schema for EO Products’, the GML dataset contains product-level metadata and is instead accessed through the CSW ebRIM profile (OGC 07-110r2) using the EO Products ebRIM Extension Package (OGC 10-189r2).

The term ‘model-driven’ refers to the fact that the primary artefact is the UML conceptual model – the GML application schema (and other artefacts, e.g. model documentation) are generated automatically from the UML model.

The motivation for a model-driven approach follows naturally from the theoretical principles underlying the conceptual modelling framework adopted by ISO TC211, the Conceptual Schema Modelling Facilities (CSMF) [ISO 14481].

Without dwelling on the details of this, CSMF defines a number of important principles for conceptual modelling. Chief among them are:

• the “100% principle”: everything significant in the universe of discourse should be described in the conceptual model;
• the “conceptualization principle”: the conceptual model should contain only aspects of the universe of discourse (it should not include aspects related to implementation details, e.g. data representation or storage); and
• the “Helsinki principle”: any meaningful exchange should follow agreed syntax and semantics related to the conceptual model.

In particular, the Helsinki principle implies a direct relationship between the UML conceptual model and the GML application schema, and that the latter should in principle be generated from the former.

Annex : Revision history

Annex : Bibliography

[1] [HMA] Heterogeneous Missions Accessibility - Design Methodology, Architecture and Use of Geospatial Standards for the Ground Segment Support of Earth Observation missions ESA TM-21 http://www.esa.int/About_Us/ESA_Publications/ESA_TM-21_Heterogeneous_Missions_Accessibility

[2] [ISO 19115:2003] Geographic information – Metadata

[3] [ISO 19115-2:2009] Geographic information – Metadata – Part 2: Extensions for imagery and gridded data

[4] [ISO 19109:2005] ISO 19109:2005 Geographic information – Rules for application schema

[5] [ISO 19110:2005] ISO 19110:2005: Geographic information – Methodology for feature cataloguing

[6] [ISO 19142] ISO/DIS 19142: Geographic information – Web Feature Service

[7] [ISO 14481] ISO/IEC 14481: Conceptual Schema Modeling Facilities (CSMF)

[8] [OGC 06-103r4] OpenGIS Implementation Specification for Geographic information - Simple feature access - Part 1: Common architecture, Version 1.2.1, 2011-05-28

[9] [OGC 07-110r2] OGC CSW-ebRIM Registry Service - Part 1: ebRIM profile of CSW, version 1.0.0, 2008/02/29.

[10] [OGC 10-189r2] Cataloguing Earth Observation Products for ebXML Registry Information Model 3.0 based Catalogues

[11] W3C, Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation, 6 October 2000, http://www.w3.org/TR/REC-xml

[12] W3C, XML Schema Part 1: Structures, http://www.w3.org/TR/xmlschema-1

[13] W3C, XML Schema Part 2: Datatypes, http://www.w3.org/TR/xmlschema-2

[14] W3C, Namespaces in XML, http://www.w3.org/TR/1999/REC-xml-names-19990114

[1] www.opengeospatial.org/cite

[2] The value qualityDegraded is deprecated. Please use the productQualityStatus element instead.

[3] The Polygon geometry shall be encoded in WGS:84 geographic coordinates. The coordinate pairs shall be ordered as lat, long following the official axis ordering convention.