10-157r4 - OGC EO Metadata profile of O&M
License Agreement
Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.
If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.
THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD.
THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.
This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.
Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.
This OGC Implementation Standard defines a profile of Observations and Measurements (ISO 19156:2010 and OGC 10-025r1) for describing Earth Observation products (EO products).
This profile is intended to provide a standard schema for encoding Earth Observation product metadata to support the description and cataloguing of products from sensors aboard EO satellites.
The metadata being defined in this document is applicable in a number of places where EO product metadata is needed.
In the EO Product Extension Package for ebRIM (OGC 10-189). This extension package defines how to catalog Earth Observation product metadata described by this document. Using this metadata model and the Catalogue Service defined in OGC 10-189, client applications can provide the functionality to discover EO Products. Providing an efficient encoding for EO Product metadata cataloguing and discovery is the prime purpose of this specification.
In the EO Application Profile of WMS (OGC 07-063r1). The GetFeatureInfo operation on the outline (footprint layer) should return metadata following the Earth Observation Metadata profile of Observation and Measurements.
In a coverage downloaded via an EO WCS AP (OGC 10-140). In WCS 2.0 (OGC 10-084), the GetCoverage and DescribeCoverage response contains the
metadata
element intended to store metadata information about the coverage. The Earth Observation Application profile of WCS (OGC 10-140) specifies that the metadata format preferred for Earth Observation is defined by this document.
Potentially enclosed within an actual product to describe georeferencing information as for instance within the JPEG2000 format using GMLJP2. GMLJP2 defines how to store GML coverage metadata inside a JP2 file.
Earth Observation data products are generally managed within logical collections that are usually structured to contain data items derived from sensors onboard a satellite or series of satellites. The key characteristics differentiating products within the collections are date of acquisition, location as well as characteristics depending on the type of sensor, For example, key characteristics for optical imagery are the possible presence of cloud, haze, smokes or other atmospheric or on ground phenomena obscuring the image.
The common metadata used to distinguish EO products types are presented in this document for generic and thematic EO products (i.e optical, radar, atmospheric, altimetry, limb-looking and synthesis and systematic products). From these metadata the encodings are derived according to standard schemas. In addition, this document describes the mechanism used to extend these schemas to specific missions and for specific purposes such as long term data preservation.
The following are keywords to be used by search engines and document catalogues.
ogcdoc, OGC document, Observations and Measurement, Earth Observation, metadata
This OGC Implementation Standard defines a profile of Observations and Measurements (ISO 19156:2010) for describing Earth Observation (EO) product metadata.
The document was initially produced during the ESA Heterogeneous Missions Accessibility [HMA] initiative and related projects. Although this standard has been developed in the context of these HMA projects, the content is generic to Earth Observation product description. The metadata model described in this document is structured to follow the different types of products (Optical, Radar, …) which are not HMA specific.
Suggested additions, changes, and comments on this standard are welcome and encouraged. Such suggestions may be submitted by email message to the editors.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.
The following organizations submitted this Document to the Open Geospatial Consortium (OGC):
ESA - European Space Agency
CNES - French Space Agency
Luciad
GIM – Geographic Information Management
STFC - Science and Technology Facilities Council
All questions regarding this submission should be directed to the editor or the submitters:
Name
Representing
OGC member
Jerome Gasperi
Centre National d’Études Spatiales (CNES)
Yes
Frederic Houbie
Luciad
Yes
Andrew Woolf
Science & Technology Facilities Council (STFC)
Yes
Steven Smolders
GIM
Yes
Other contributors::
Name
Representing
OGC member
Jolyon Martin
ESA
Yes
Fabian Skivee
Yes
Dominic Lowe
STFC
Yes
Wim De Smet
GIM
Yes
1. Scope
This document describes the encodings required to describe Earth Observation (EO) products metadata from general Earth Observation Product descriptions to mission specific characteristics. The document is a profile of the Observations and Measurements 2.0 standard.
2. Conformance
EO Product metadata conforming to this profile of Observations and Measurements shall be encoded as XML documents that are fully compliant with the normative XML Schema Documents associated with this standard (i.e.
eop.xsd
for general EO Products,
opt.xsd
sar.xsd
atm.xsd
alt.xsd
lmb.xsd
and
ssp.xsd
for optical, radar, atmospheric, altimetry, limb looking and “synthesis and systematic” products respectively).
In addition to validation against the aforementioned XML schema, schematron validation (i.e
schematron_rules_for_eop.sch
) shall be used to verify the compliance of an XML instance.
Conformance with this standard shall be checked using all the relevant tests specified in Annex A (normative) of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site
[1]
All requirements-classes and conformance-classes described in this document are owned by the standard(s) identified.
3. Normative References
The following normative documents contain provisions that, through reference in this text, constitute provisions of this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.
[OGC 10-004r3]
OGC Abstract Specification Topic 20 -
Observations and Measurements, Version 2.0 (also published as ISO/DIS 19156:2010, Geographic information — Observations and Measurements)
[OGC 10-025r1]
Observations and Measurements – XML Implementation
, Version 2.0
[OGC 07-036]
Geography Markup Language,
Version 3.2.1 (also published as ISO 19136:2007, Geographic information — Geography Markup Language)
[OGC 06-080r4]
GML 3.1.1 Application schema for Earth Observation products
, Version 1.0.0
[OGC 09-046r2]
OGC Naming Authority (OGC-NA) Policies & Procedures
[OGC 06-135r11]
Policy Directives for Writing and Publishing
OGC Standards: TC Decisions.
In addition to this document, this standard includes several normative XML Schema files. These schemas are posted online at
. These XML Schema files may also be bundled with the zip version of this document (informative version). In the event of a discrepancy between the bundled and online versions of the XML Schema files, the online files shall be considered authoritative.
4. Terms and Definitions
This document uses the terms defined in Sub-clause 5.3 of [OGC 06-121r8], which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this standard.
For the purposes of this document, the following additional terms and definitions apply.
4.1
client
software component that can invoke an
operation
from a
server
4.2
datastrip
A satellite acquisition
4.3
geographic information
information concerning phenomena implicitly or explicitly associated with a location relative to the Earth [ISO 19101]
4.4
identifier
a character string that may be composed of numbers and characters that is exchanged between the client and the server with respect to a specific identity of a resource
4.5
request
invocation of an
operation
by a
client
4.6
response
result of an
operation,
returned from a
server
to a
client
4.7
scene
The result of cutting a datastrip into multiple parts
EXAMPLE For the PHR mission, a scene is a 20x20 km^2 square part.
4.8
schema
formal description of a model [ISO 19101, ISO 19103, ISO 19109, ISO 19118]
5. Conventions
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.
Table
: namespace mappings
Prefix
Namespace URI
Description
eop
General EO product schema namespace
opt
Optical High Resolution EO product schema
namespace
sar
Radar EO product schema namespace
atm
Atmospheric EO product schema namespace
alt
Altimetry EO product schema namespace
lmb
Limb looking EO product schema namespace
ssp
Synthesis and Systematic EO product schema
namespace
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)
Figure:
: A layered view of EO O&M Products metadata.
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.
Figure:
: The basic Observation type (from OGC10-004r3)
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.
Table
: Observations and Measurements properties mapping within the Earth Observation context
Observations and
Measurements property
Awaited Content
Description
metadata
eop:EarthObservationMetadata
General
properties such as the data identifier, the downlink and archiving
information.
phenomenonTime
gml:TimePeriod
The
acquisition duration
procedure
eop:EarthObservationEquipment
The
Platform/Instrument/Sensor used for the acquisition and the acquisition
parameters (i.e. pointing angles, etc.)
featureOfInterest
eop:Footprint
The
observed area (or its projection) on the ground i.e. the footprint of
acquisition
result
Eop:EarthObservationResult
The metadata
describing the Earth Observation result composed of the browse, mask and
product descriptions
observedProperty
xlink
reference to eop:EarthObservationResult/eop:parameter/
eop:ParameterInformation/eop:phenomenon/
swe:Phenomenon
if provided or CF Standard Name code list entry
See
section 6.3.1
resultTime
gml:TimeInstant
See
section 6.3.2
Figure:
: 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.
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:
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:EarthObservationResultType
element which extends and acts as a substitution for
eop:
EarthObservationResultType
[…]
[…]
[…]
[…]
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
Example : resolution
Each angle property is recommended to use the existing GML type
Example : Instrument Across Track incidence angle
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].
Table
: Requirements for XML instances
Target
type
Data instance
Dependency
Requirement
Any XML element in the substitution group of eop:EarthObservation shall be well-formed and validate against the schema.
Requirement
eop:metaDataProperty shall contain eop:EarthObservationMetaData or an extension: either an alt or ssp thematic extension corresponding to the product type or a mission-specific extension with appropriate attribute eop:type.
Requirement
om:procedure shall contain eop:EarthObservationEquipment or an extension: either an alt, atm, lmb or ssp thematic extension corresponding to the product type or a mission-specific extension with appropriate attribute eop:type.
Requirement
eop:acquisitionParameters shall contain eop:Acquisition or an extension: either a sar, alt, atm or lmb thematic extension corresponding to the product type or a mission-specific extension with appropriate attribute eop:type.
Requirement
om:result shall contain eop:EarthObservationResult or an extension: either an atm, opt or ssp thematic extension corresponding to the product type or a mission-specific extension with appropriate attribute eop:type.
Requirement
om:featureOfInterest shall contain an eop:Footprint or an extension of eop:Footprint corresponding to the product type (alt, lmb, ssp).
Requirement
om:phenomenonTime shall contain a gml:TimePeriod/gml:beginPosition and a gml:TimePeriod/gml:endPosition.
Requirement
Footprint eop:multiExtentOf shall contain a gml:MultiSurface/gml:surfaceMembers/gml:Polygon/gml:exterior/gml:LinearRing/gml:posList.
Requirement
Footprint eop:centerOf shall contain a gml:Point/gml:pos.
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
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.
Table
:
Field name
Field description
Cardinality
om:phenomenonTime/
gml:TimePeriod/
gml:beginPosition
Acquisition start
date time
dateTime in ISO 8601 format (CCYY-MM-DDThh:mm[:ss[.cc]]Z)
om:phenomenonTime/
gml:TimePeriod/
gml:endPosition
Acquisition end
date time
dateTime in ISO 8601 format (CCYY-MM-DDThh:mm[:ss[.cc]]Z)
om:resultTime/gml:TimeInstant/
gml:timePosition
The time
when the result becomes available
dateTime
in ISO 8601 format (CCYY-MM-DDThh:mm[:ss[.cc]]Z)
om:procedure/
eop:EarthObservationEquipment
Platform/Instrument/Sensor
used for the acquisition and the acquisition parameters
om:observedProperty
An xlink to the
observed property definition
1..n
om:featureOfInterest
eop:Footprint
Observed area on
the ground or its projection i.e. the footprint of acquisition
0..1
om:result/
eop:EarthObservationResult
Earth Observation
result metadata composed of the browse, mask and product description
0..1
eop:metaDataProperty/eop:EarthObservationMetaData
Additional external
metadata about the data acquisition
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.
Table
:
Field name
Field description
Cardinality
identifier
Identifier for
metadata item
creationDate
creation date for
the metadata item. When retrieved from a metadata catalogue, the creationDate
is the date when the metadata item was ingested for the first time (i.e.
inserted) in the catalogue.
0..1
modificationDate
Date
of the last modification to the metadata item. When retrieved from a metadata
catalogue, the modificationDate is the date when the metadata item was last
modified (i.e. updated) in the catalogue.
0..1
doi
Digital Object
Identifier identifying the product (see http://www.doi.org)
0..1
parentIdentifier
Collection
Identifier
0..1
acquisitionType
Used to distinguish
at a high level the appropriateness of the acquisition for
"general" use, whether the product is a nominal acquisition,
special calibration product or other.
Values:
- NOMINAL
- CALIBRATION
- OTHER
acquisitionSubType
The broad value
defined by the acquisitionType is however too restrictive, so mission
specific type definition should refer to mission/ground segment dedicated
codeSpace
0..1
productType
Describes the
product type in case that mixed types are available within a single
collection, this is a ground segment specific definition
0..1
Status
Refers to product
status.
Values :
- ARCHIVED
- ACQUIRED
- CANCELLED
- FAILED
- PLANNED
- POTENTIAL
- REJECTED
- QUALITYDEGRADED
[2]
statusSubType
Refines the status
of a product when the “status” is set to “ARCHIVED”.
Possible values:
- “ON-LINE”
- “OFF-LINE”
0..1
statusDetail
This field refers
to the eop:status value. It should be used to motivate the reason of a
failure, cancelation, rejection or degraded quality.
0..1
downlinkedTo/
DownlinkInformation/
acquisitionStation
Acquisition /
receiving station code. Possible values are mission specific and should be
retrieved using codespace.
(with eop:downlinkedTo 0..n)
downlinkedTo/
DownlinkInformation/
acquisitionDate
Acquisition date
time.
0..1
archivedIn/
ArchivingInformation/
archivingCenter
Archiving center
code. Possible values are mission specific and should be retrieved using
codeSpace.
(with eop:ArchivingInformation 0..n)
archivedIn/
ArchivingInformation/
archivingDate
Archiving date
time.
archivedIn/
ArchivingInformation/
archivingIdentifier
Local archiving id
as created by the mission ground segment that may be required to allow
subsequent order processing
0..1
imageQualityDegradation
Quality
degradation percentage (i.e. uom=’%’)
This element
is deprecated. Please use the
equivalent productQualityDegradation element instead.
0..1
productQualityDegradation
Quality degradation percentage (i.e. uom=’%’)
0..1
imageQualityDegradationQuotationMode
Indicator to
know how the quality degradation percentage has been calculated.
Values:
AUTOMATIC
MANUAL
This element
is deprecated. Please use the
equivalent productQualityDegradationQuotationMode element
instead.
0..1
productQualityDegradationQuotationMode
Indicator to
know how the quality degradation percentage has been calculated.
Values :
AUTOMATIC
MANUAL
0..1
imageQualityStatus
Indicator
that specifies whether the product quality is degraded or not. This optional field shall be provided if
the product has passed a quality check.
Values:
DEGRADED,
NOMINAL
This element
is deprecated. Please use the
equivalent productQualityStatus element instead.
0..1
productQualityStatus
Indicator
that specifies whether the product quality is degraded or not. This optional field shall be provided if
the product has passed a quality check.
Values:
DEGRADED,
NOMINAL
0..1
imageQualityDegradationTag
Contains
further textual information concerning the quality degradation. It shall be provided if
eop:imageQualityStatus value is DEGRADED. Possible values are mission
specific and should refer to mission/ground segment dedicated codeSpace.
Example of
values could be "RADIOMETRY" or "GEOLOCATION".
This element
is deprecated. Please use the
equivalent productQualityDegradationTag element
instead.
0..n
productQualityDegradationTag
Contains
further textual information concerning the quality degradation. It shall be provided if eop:productQualityStatus
value is DEGRADED. Possible values are mission specific and should refer to
mission/ground segment dedicated codeSpace.
Example of
values could be "RADIOMETRY" or "GEOLOCATION".
0..n
imageQualityReportURL
URL reference
to an external quality report file
This element
is deprecated. Please use the
equivalent productQualityReport element instead.
0..1
productQualityReportURL
URL reference
to an external quality report file
0..1
histograms/
Histogram/
bandId
Histogram specific : identifier of
the spectral band used to compute histogram values
0.. 1
(with eop:histograms 0..n)
histograms/
Histogram/
min
Histogram specific : minimum value
histograms/
Histogram/
max
Histogram specific : maximum value
histograms/
Histogram/
mean
Histogram specific : mean value
0..1
histograms/
Histogram/
stdDeviation
Histogram specific : standard
deviation value
0..1
composedOf
Link to an EO product that is part of
this EO product (e.g. a phr:DataStrip is composed of one or more phr:Scene)
0..n
subsetOf
Link to the “father” EO product (e.g.
a phr:Scene is a subset of a phr:DataStrip)
0..n
linkedWith
Specify a link to another EO product
(e.g. ERS1 and ERS2 interferometric pair)
0..n
processing/
ProcessingInformation/
processingCenter
Processing center code. Possible
values are mission specific and should be retrieved using codeSpace.
0..1
(with
eop:processing 0..n)
processing/
ProcessingInformation/
processingDate
Processing date time
0..1
processing/
ProcessingInformation/
compositeType
Type of composite product
expressed as timeperiod that the composite product covers (e.g. P10D for a 10 day composite)
0..1
processing/
ProcessingInformation/
method
Method used to
compute datalayer. (e.g. Kalman filtering, ROSE)
0..1
processing/
ProcessingInformation/
methodVersion
Method version
(e.g. 1.0)
0..1
processing/
ProcessingInformation/
processorName
Processor software
name (e.g. FastROSE)
0..1
processing/
ProcessingInformation/
processorVersion
Processor software
version (e.g. 1.0)
0..1
processing/
ProcessingInformation/
processingLevel
Processing level
applied to the product
0..1
processing/
ProcessingInformation/
nativeProductFormat
Native product
format
0..1
processing/
ProcessingInformation/ auxiliaryDataSetFileName
Name(s) of
auxiliary dataset(s) used in the process
0..n
processing/
ProcessingInformation/
processingMode
Processing mode
taken from mission specific code list
Examples of values
are:
NRT
NOMINAL
BACKLOGGED
REPROCESSED
VALIDATE
0..1
productGroupId
Holds
the identifier of a particular group to which the product belongs to. Group
members represent then "granules" or "portions" of
end-user products that are eligible for specific aggregations (e.g. all
Sentinel-2 granules having the same productGroupId can be assembled together
to form a Sentinel-2 end-user product)
0..1
vendorSpecific/
SpecificInformation/
localAttribute
Container for
ad-hoc metadata that does not merit a mission specific schema or extension,
the localAttribute describes the name of the attribute
(with eop:vendorSpecific 0..n)
vendorSpecific/
SpecificInformation/
localValue
Container for
ad-hoc metadata that does not merit a mission specific schema or extension,
the localAttribute describes the value of the attribute
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.
Table
:
Field name
Field description
Cardinality
platform/
Platform/
shortName
Platform short name
(e.g. PHR)
(with eop:platform 0..1)
platform/
Platform/
serialIdentifier
Platform serial
identifier (e.g. for PHR : 1A)
0..1
platform/
Platform/
orbitType
High level
characterisation of main mission types taken from a codelist
Values:
GEO
LEO
0..1
instrument/
Instrument/
shortName
Instrument (Sensor)
name
0..1
(with eop:instrument 0..1)
instrument/
Instrument/
description
Instrument
description
0..1
instrument/
Instrument/
instrumentType
Instrument type
0..1
sensor/
Sensor/
sensorType
Sensor type based
on codelist
Values:
- OPTICAL
- RADAR
- ALTIMETRIC
- ATMOSPHERIC
- LIMB
0..1
(with eop:sensor 0..1)
sensor/
Sensor/
operationalMode
Sensor mode.
Possible values are mission specific and should be retrieved using codeSpace.
0..1
sensor/
Sensor/
resolution
Sensor resolution.
0..1
sensor/
Sensor/
swathIdentifier
Swath identifier
(e.g. Envisat ASAR has 7 distinct swaths (I1,I2,I3...I7) that correspond to
precise incidence angles for the sensor). Value list can be retrieved with
codeSpace.
0..1
sensor/Sensor/wavelengthInformation/WavelengthInformation/discreteWavelengths
List of discrete
wavelengths observed in the product (gml:MeasureList)
0..1
(with eop: wavelengthInformation
0..n)
sensor/Sensor/wavelengthInformation/WavelengthInformation/endWavelength
End of the observed
wavelength range (gml:Measure)
0..1
sensor/Sensor/wavelengthInformation/WavelengthInformation/spectralRange
The observed
Spectral Range:
Values:
- INFRARED
- NEAR-INFRARED
- UV
- VISIBLE
- OTHER
0..1
sensor/Sensor/wavelengthInformation/WavelengthInformation/startWavelength
Start of the
observed wavelength range (gml:Measure)
0..1
sensor/Sensor/wavelengthInformation/WavelengthInformation/wavelengthResolution
Spacing between
consecutive wavelengths (gml:Measure)
0..1
acquisitionParameters/
Acquisition/
orbitNumber
Acquisition orbit
number
0..1
(with eop:acquisitionParameters 0..1)
acquisitionParameters/
Acquisition/
lastOrbitNumber
Acquisition last
orbit number
0..1
acquisitionParameters/
Acquisition/
orbitDirection
Acquisition orbit direction
Values:
ASCENDING
DESCENDING
0..1
acquisitionParameters/
Acquisition/
wrsLongitudeGrid
Neutral
wrsLongitudeGrid to replace track in track/frame, K in K/J, etc.
The optional
attribute "eop:codeSpace" is used to point the reference grid
0..1
acquisitionParameters/
Acquisition/
wrsLatitudeGrid
Neutral
wrsLatitudeGrid to replace frame in track/frame, J in K/J, etc.
The optional
attribute "eop:codeSpace" is used to point the reference grid
0..1
acquisitionParameters/
Acquisition/
ascendingNodeDate
UTC date and time
at ascending node of orbit
0..1
acquisitionParameters/
Acquisition/
ascendingNodeLongitude
Longitude at
ascending node of orbit. Should be expressed in degrees.
0..1
acquisitionParameters/
Acquisition/
startTimeFromAscendingNode
Start time of
acquisition in milliseconds from ascending node date
0..1
acquisitionParameters/
Acquisition/
completionTimeFromAscendingNode
Stop time of
acquisition in milliseconds from ascending node date
0..1
acquisitionParameters/
Acquisition/
orbitDuration
Actual orbit
duration in milliseconds
0..1
acquisitionParameters/
Acquisition/
illuminationAzimuthAngle
Mean
illumination/solar azimuth angle given in degrees. (i.e. uom='deg')
0..1
acquisitionParameters/
Acquisition/
illuminationZenithAngle
Mean
illumination/solar zenith angle given in degrees. (i.e. uom='deg')
0..1
acquisitionParameters/
Acquisition/
illuminationElevationAngle
Mean
illumination/solar elevation angle given in degrees. (i.e. uom='deg')
0..1
acquisitionParameters/
Acquisition/
instrumentAzimuthAngle
Mean instrument
azimuth angle given in degrees. (i.e. uom='deg')
0..1
acquisitionParameters/
Acquisition/
instrumentZenithAngle
Mean instrument
zenith angle given in degrees. (i.e. uom='deg')
0..1
acquisitionParameters/
Acquisition/
instrumentElevationAngle
Mean instrument elevation
angle given in degrees. (i.e. uom='deg')
0..1
acquisitionParameters/
Acquisition/
incidenceAngle
Acquisition global
incidence angle given in degrees (i.e. uom='deg')
0..1
acquisitionParameters/
Acquisition/
acrossTrackIncidenceAngle
Acquisition across
track incidence angle given in degrees. (i.e. uom='deg')
0..1
acquisitionParameters/
Acquisition/
alongTrackIncidenceAngle
Acquisition along
track incidence angle given in degrees. (i.e. uom='deg')
0..1
acquisitionParameters/
Acquisition/
pitch
Satellite pitch
angle given in degrees (i.e. uom='deg')
0..1
acquisitionParameters/
Acquisition/
roll
Satellite roll
angle given in degrees (i.e. uom='deg')
0..1
acquisitionParameters/
Acquisition/
yaw
Satellite yaw angle
given in degrees (i.e. uom='deg')
0..1
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.
Table
:
Field name
Field description
Cardinality
multiExtentOf
Acquisition
footprint coordinates, described by a closed polygon (last point=first
point), using latitude, longitude pairs.
Expected structure is
gml:Polygon/gml:exterior/gml:LinearRing/gml:posList.
[3]
centerOf
Acquisition center
coordinates
0..1
orientation
Determines the orientation
of the coordinate pairs for the exterior boundary of the footprint
polygons. Possible values are CW
(clockwise), counter-clockwise (CCW) or OTHER (unspecified orientation). Note that this property is only to be
provided for footprints that do not follow the normal counterclockwise for
exterior boundaries convention as defined in [OGC06-103r4]. If the property is not provided, a CCW
orientation for the exterior boundary will be assumed.
0..1
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
Table
:
Field name
Field description
Cardinality
browse/
BrowseInformation/
type
Browse type.
Values are :
- THUMBNAIL
- QUICKLOOK
- ALBUM.
(with eop:browse 0..n)
browse/
BrowseInformation/
subtype
Browse subType.
Value is mission specific. Value list can be retrieved with codeSpace (e.g.
for MODIS : OPTICAL, THERMAL)
0..1
browse/
BrowseInformation/
referenceSystemIdentifier
Indicates if browse
is geo-referenced, and thus can be assumed to be displayed directly on a map
(in which case it should point to a code space for the CRS), when not
supplied it is assumed that the browse is provided in "raw"
satellite frame of reference
browse/
BrowseInformation/
filename
Reference
to File or OGC Web Service
In case the browse products are offered
from FTP or HTTP URLS, the xlink:href attribute is used to encode the
full URL to the product and the ows:RequestMessage element is left
blank.
In case the browse products are offered
through WMS or WCS using HTTP GET with KeyValuePair encoding, the
xlink:href attribute is used to encode the full URL including the KVP
and the ows:RequestMessage element is left blank.
In case the browse products are offered
through a service supporting HTTP POST or SOAP the xlink:href attribute
is used to encode the service endpoint (online resource and the
ows:RequestMessage shall contain the XML encoded message (including the
SOAP Header in case of SOAP messaging).
product/
ProductInformation/
referenceSystemIdentifier
Indicates if
product is geo-referenced, (in which case should point to a code space for
the CRS), when not supplied it is assumed that the browse is provided in
"raw" satellite frame of reference
0..1
product/
ProductInformation/
filename
Reference
to File or OGC Web Service
In case the products are offered from FTP
or HTTP URLS, the xlink:href attribute is used to encode the full URL to
the product and the ows:RequestMessage element is left blank.
In case the products are offered through WMS
or WCS using HTTP GET with KeyValuePair encoding, the xlink:href
attribute is used to encode the full URL including the KVP and the ows:RequestMessage
element is left blank.
In case the products are offered through a
service supporting HTTP POST or SOAP the xlink:href attribute is used to
encode the service endpoint (online resource and the ows:RequestMessage
shall contain the XML encoded message (including the SOAP Header in case
of SOAP messaging).
(with eop:product 0..n)
product/
ProductInformation/
version
Product version
0..1
product/
ProductInformation/
size
Product size
(bytes) allowing the user to realise how long a download is likely to take
0..1
product/
ProductInformation/timeliness
Timeliness
of the product, such as "near real time", "rush".
Possible values are mission specific and shall refer to mission/ground
segment dedicated codeSpace.
Example
of values could be "NRT", "NOMINAL", “NTC” or “STC”
0..1
mask/
MaskInformation/
type
Mask type. Possible
values are : SNOW, CLOUD and QUALITY
(with eop:mask 0..n)
mask/
MaskInformation/
subType
Allows to further
specify the type of mask
0..1
mask/
MaskInformation/
format
Mask format.
Possible values are: RASTER or VECTOR
mask/
MaskInformation/
referenceSystemIdentifier
Indicates if mask
is geo-referenced, and thus can be assumed to be displayed directly on a map
(in which case should point to a code space for the CRS), when not supplied
it is assumed that the mask is provided in "raw" satellite frame of
reference
0..1
mask/
MaskInformation/
fileName
Reference
to File or OGC Web Service
In case the masks are offered from FTP or
HTTP URLS, the xlink:href attribute is used to encode the full URL to
the product and the ows:RequestMessage element is left blank.
In case the masks are offered through WMS
or WCS using HTTP GET with KeyValuePair encoding, the xlink:href
attribute is used to encode the full URL including the KVP and the ows:RequestMessage
element is left blank. Preferably the masks are encoded using GML 3.2.1
following the model that is specified in Annex F.
In case the masks are offered through a
service supporting HTTP POST or SOAP the xlink:href attribute is used to
encode the service endpoint (online resource and the ows:RequestMessage
shall contain the XML encoded message (including the SOAP Header in case
of SOAP messaging).
0..1
(either fileName or multiExtentOf
shall be provided)
mask/MaskInformation/
multiExtentOf
Contains inline encoded
mask polygon geometries using the gml:MultiSurface/gml:surfaceMembers/gml:Polygon
constructs.
0..1
(either fileName or multiExtentOf
shall be provided)
parameter/ParameterInformation/unitOfMeasure
Units of measure for the
observed phenomenon.
Note that for a
multi-faceted Constrained or Composite Phenomenon multiple unitOfMeasure
attributes must be present and the unitOfMeasure element order must
correspond to the order of the phenomenon descriptions.
0..n
(with eop: parameter 0..1)
parameter/ParameterInformation/phenomenon
A SWE 1.0 Phenomenon. Could
be a single SWE Phenomenon (such as Sea Surface Height) or a SWE
ConstrainedPhenomenon, such as a list of particular radiance bands, or a SWECompositePhenomeon
which groups several discrete phenomena
0..1
coverage
Reference
to coverage exploitation metadata (domainSet, RangeType, ...) as offered by a
corresponding WCS using a HTTP GET encoded DescribeCoverage Request.
0..n
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:
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
One property is extended from the eop schema :
opt:EarthObservationResult
extends
eop:EarthObservationResult
Table
:
Field name
Field description
Cardinality
opt:EarthObservationResult/
opt:cloudCoverPercentage
Cloud cover percentage (i.e. uom=’%’)
0..1
opt:EarthObservationResult/
opt:cloudCoverPercentageAssessmentConfidence
Cloud cover assessment confidence.
Expressed in percents.
0..1
opt:EarthObservationResult/
opt:cloudCoverPercentageQuotationMode
Indicator to know how the cloud cover
percentage has been calculated
Values :
AUTOMATIC
MANUAL
0..1
opt:EarthObservationResult/
opt:snowCoverPercentage
Snow cover percentage (i.e. uom=’%’)
0..1
opt:EarthObservationResult/
opt:snowCoverPercentageAssessmentConfidence
Snow cover assessment confidence.
Expressed in percents.
0..1
opt:EarthObservationResult/
opt:snowCoverPercentageQuotationMode
Indicator to know how the snow cover
percentage has been calculated
Values :
AUTOMATIC
MANUAL
0..1
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
One property is extended from the eop schema :
sar:Acquisition
extends
eop:Acquisition
(Table 10).
Table
:
Field name
Field description
Cardinality
eop:EarthObservationEquipment/
eop:acquisitionParameters/
sar:Acquisition/
sar:polarisationMode
Polarisation mode taken from
codelist:
S (for single),
D (for dual),
T (for twin),
Q (for quad),
UNDEFINED
0..1
eop:EarthObservationEquipment/
eop:acquisitionParameters/
sar:Acquisition/
sar:polarisationChannels
polarisation
channel transmit/receive configuration: horizontal, vertical.
Values:
- HH
- HV
- VH
- VV
- HH, VV
- HH, VH
- HH, HV
- VH, VV
- VH, HV
- VV, HV
- VV, VH
- HV, VH
- HH, HV, VH, VV
- UNDEFINED
0..1
eop:EarthObservationEquipment/
eop:acquisitionParameters/
sar:Acquisition/
sar:antennaLookDirection
Look direction of antenna taken from
codelist
Values:
- LEFT
- RIGHT
0..1
eop:EarthObservationEquipment/
eop:acquisitionParameters/
sar:Acquisition/
sar:minimumIncidenceAngle
Minimum incidence angle
0..1
eop:EarthObservationEquipment/
eop:acquisitionParameters/
sar:Acquisition/
sar:maximumIncidenceAngle
Maximum incidence angle
0..1
eop:EarthObservationEquipment/
eop:acquisitionParameters/
sar:Acquisition/
sar:incidenceAngleVariation
Incidence angle variation
0..1
eop:EarthObservationEquipment/
eop:acquisitionParameters/
sar:Acquisition/
sar:dopplerFrequency
Doppler Frequency of acquisition
0..1
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
One property is extended from the eop schema :
atm:EarthObservationResult
extends
eop:EarthObservationResult
(Table 11).
Table
:
Field name
Field description
Cardinality
atm:EarthObservationResult/
atm:dataLayers/
atm:DataLayer/
atm:speciesError
Error on species contained in
DataLayer
0..1
atm:EarthObservationResult/
atm:dataLayers/
atm:DataLayer/
atm:unit
Unit of species in DataLayer
0..1
atm:EarthObservationResult/
atm:dataLayers/
atm:DataLayer/
atm:verticalRange
Top height of DataLayer. May be
expressed in meters or other units such as pressure.
0..1
atm:EarthObservationResult/
atm:dataLayers/
atm:DataLayer/
atm:species
Species contained in DataLayer
0..1
atm:EarthObservationResult/
atm:dataLayers/
atm:DataLayer/
atm:algorithmName
Name of algorithm used to compute
DataLayer
0..1
atm:EarthObservationResult/
atm:dataLayers/
atm:DataLayer/
atm:algorithmVersion
Algorithm version used to compute
DataLayer
0..1
atm:EarthObservationResult/
atm:dataLayers/
atm:DataLayer/
atm:verticalResolution
Full width at half maximum of the
rows of the vertical averaging kernel matrix
0..1
atm:EarthObservationResult/atm:cloudCoverPercentage
Cloud cover percentage (i.e. uom=’%’)
0..1
atm:EarthObservationResult/atm:cloudCoverPercentageAssessmentConfidence
Cloud cover assessment confidence.
Expressed in percents.
0..1
atm:EarthObservationResult/atm:cloudCoverPercentageQuotationMode
Indicator to know how the cloud cover
percentage has been calculated
Values :
AUTOMATIC
MANUAL
0..1
atm:EarthObservationResult/atm:snowCoverPercentage
Snow cover percentage (i.e. uom=’%’)
0..1
atm:EarthObservationResult/atm:snowCoverPercentageAssessmentConfidence
Snow cover assessment confidence.
Expressed in percents.
0..1
atm:EarthObservationResult/atm:snowCoverPercentageQuotationMode
Indicator to know how the snow cover
percentage has been calculated
Values :
AUTOMATIC
MANUAL
0..1
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
Four properties are extended from the eop schema:
alt:EarthObservationEquipment
extends
eop:EarthObservationEquipment
([Table 12]);
alt:Footprint
extends
eop:Footprint
([Table 13]).
alt:
ProcessingInformation
extends
eop:
ProcessingInformation
([Table 14]).
alt:
Acquisition
extends
eop:
Acquisition
([Table 15]).
Table
:
Field name
Field description
Cardinality
alt:EarthObservationEquipment/
alt:instrument
Cardinality
of the instrument attribute in base schema is 0..1
For
combined products (made with multiple altimeters) there may be more than one
primary instrument.
Cardinality
is therefore modified to 0..n
(Note this
is separate from the requirement for Auxiliary Instruments).
This
requirement is for the case when a gridded product for example is the result
of more than one instrument.
0..n
alt:EarthObservationEquipment/
alt:auxiliaryInstrument
Must be of
type AuxiliaryInstrument
Auxiliary
instruments are a class of instruments that are not the primary instrument.
It is desirable to identify them for discovery purposes.
e.g.
DORIS-DIODE is an auxiliary instrument used in altimetry.
0..n
alt:EarthObservationEquipment/
alt:auxiliaryInstrument/alt:instrumentType
The type of
the auxiliary instrument.
Allowed
Values are:
DOPPLER
GPS
LASER
MICROWAVE_RADIOMETER
OTHER
alt:EarthObservationEquipment/
alt:platform
Cardinality
of the platform attribute in base schema is 0..1
For combined
products (made with multiple altimeters) there may be more than one primary
platform.
Cardinality
is therefore modified to 0..n
0..n
Table
:
Field name
Field description
Cardinality
alt:Footprint/
alt:nominalTrack
A geometry
of type GM_Multicurve used to define the nominal track on the earths surface.
This track is essentially a line that is representative of the product but
does not include points for every value.
The use of
GM_MultiCurve allows for multiple lines and breaks in lines.
0..1
Table
:
Field name
Field description
Cardinality
alt:ProcessingInformation/alt:groundTrackUncertainty
Measure of
the uncertainty of the ground track. Sometimes known as deadband e.g. 1Km
deadband.
0..1
alt:ProcessingInformation/alt:productContentsType
Classification
of product according to ground type covered. Note cardinality allows for
multiple instances of this property.
Allowed
Values:
COASTAL
CONTINENTAL
HYDROLOGY
ICE
OPEN_OCEAN
OTHER
REGIONAL
0..n
alt:ProcessingInformation/alt:
samplingRate
Rate at
which samples are provided in product. Some products may contain more than
one sampling rate, e.g. 1kHz and 20kHz. Cardinality is therefore zero to
many.
Must be
gml:Measure
0..n
Table
:
Field name
Field description
Cardinality
alt:Acquisition/
alt:cycleNumber
Number of
Cycles
0..1
alt:Acquisition/
alt:isSegment
Acquisition
may not be a pass but may be a segment characterised by a start and end time.
In this case
the isSegment flag should be set to "True"
The default
value (or the assumed value if not present) is "False"
0..1
alt:Acquisition/
alt:relativePassNumber
Pass number
since start of cycle.
0..1
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
Three properties are extended from the eop schema:
lmb:Footprint
extends
eop:Footprint
([Table 16]).
lmb:Sensor
extends
eop:Sensor
([Table 17]).
lmb:Acquisition
extends
eop:Acquisition
([Table 18]).
Table
:
Field name
Field description
Cardinality
lmb:Footprint/
lmb:maximumAltitude
Upper bound
of measurements in vertical dimension. Must be of gml:MeasureType
0..1
lmb:Footprint/
lmb:minimumAltitude
Lower bound
of measurements in vertical dimension. Must be of gml:MeasureType
0..1
lmb:Footprint/
lmb:nominalTrack
A geometry
of type GM_Multicurve is used to define the nominal track on the earths
surface (projection of the measured volume). This track is essentially a line
that is representative of the product but does not include points for every
value.
The use of
GM_MultiCurve allows for multiple lines and breaks in lines.
0..1
lmb:Footprint/
lmb:occultationPoints
A set of unstructured
occultation points (e.g. with non-astronomical bodies like GPS satellites) at
which atmospheric profiles are available within the product.
0..1
Table
:
Field name
Field description
Cardinality
lmb:Sensor/
lmb:measurementType
Measurement
type taken from codelist:
Values:
- ABSORPTION
- EMISSION
0..1
Table
:
Field name
Field description
Cardinality
lmb:Acquisition/
lmb:observationMode
Observation
mode used in acquisition. e.g 'UTLS-1' is one of the seven MIPAS observation
modes which determine the sampling regime. Not constrained to codelist at the
limb-looking level as these modes are instrument specific.
0..1
lmb:Acquisition/
lmb: verticalResolution
Vertical
spacing of data (if regular)
0..1
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
Four properties are extended from the eop schema:
ssp:Footprint
extends
eop:Footprint
([Table 19]);
ssp:EarthObservationEquipment
extends
eop:EarthObservationEquipment
([Table 20]);
ssp:EarthObservationResult
extends
eop:EarthObservationResult
([Table 21]); and
ssp
:E
arthObservationMetaData
extends
eop:EarthObservationMetaData
([Table 22]).
Table
:
Field name
Field description
Cardinality
ssp:Footprint/
gml:locationName
Name to
indicate the area that is covered e.g. "World", "Africa". Modelled as gml:locationName:a convenience
property where the text value describes the location of the feature. If the
location names are selected from a controlled list, then the list shall be
identified in the codeSpace attribute.
Table
:
Field name
Field description
Cardinality
ssp:EarthObservationEquipment/
ssp:instrument
ssp could be
generated on the basis of products resulting from one or more instruments.
Cardinality
is modified to 0..n
0..n
ssp:EarthObservationEquipment/
ssp:platform
ssp could be
generated on the basis of products resulting from instruments onboard more
than one satellite.
Cardinality
is modified to 0..n
0..n
Table
:
Field name
Field description
Cardinality
ssp:EarthObservationResult /
ssp:cloudCoverPercentage
Cloud Cover
Percentage (cfr optical products)
0..1
ssp:EarthObservationResult /
ssp:cloudCoverPercentageAssessmentConfidence
Cloud Cover
Percentage Assesment Confidence (cfr optical products)
0..1
ssp:EarthObservationResult /
ssp:cloudCoverPercentageQuotationMode
Cloud Cover
Percentage Quotation Mode (cfr optical products)
0..1
ssp:EarthObservationResult /
ssp:snowCoverPercentage
Snow Cover
Percentage (cfr optical products)
0..1
ssp:EarthObservationResult /
ssp:snowCoverPercentageAssessmentConfidence
Snow Cover
Percentage Assesment Confidence (cfr optical products)
0..1
ssp:EarthObservationResult /
ssp:snowCoverPercentageQuotationMode
Snow Cover
Percentage Quotation Mode (cfr optical products)
0..1
Table
:
Field name
Field description
Cardinality
ssp:EarthObservationMetaData/
ssp:derivedFrom
Link to the
EO Product(s) that were used in the generation of the ssp product
0..n
ssp:EarthObservationMetaData/
ssp: nominalDate
Nominal date
assigned to the synthesis product
0..1
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].
Table
: Conformance class
Conformance
class
Requirements
Dependency
NOTE: The EOP
schema imports the XML Schema for Observation and Measurements. However
Observation and Measurements conformance includes additional tests that are
not enforced by schema validation.
Test
/observation-valid
Requirement
Test purpose
Verify that any XML element in the substitution group of eop:EarthObservation
is well-formed
and valid
Test method
Validate the XML document using the XML Schema document
(eop.xsd, opt.xsd, sar.xsd, atm.xsd, alt.xsd, lmb.xsd, ssp.xsd) that
describes the appropriate namespace (EOP, OPT, SAR, ATM, ALT, LMB, SSP). Pass
if no errors reported. Fail otherwise.
Test type
Basic
Test
/metaDataProperty
eop:metaDataProperty : expected content is
eop:EarthObservationMetaData or an extension
Requirement
Test purpose
Verify that the content model of any eop:metaDataProperty element
is an eop:EarthObservationMetaData element or an extension (alt or ssp
thematic extension corresponding to the product type or mission-specific
extension with appropriate attribute eop:type)
Test method
Validate the XML document using the rule
metaDataProperty_strict
and
metaDataProperty_extended
per product type of the Schematron document schematron_rules_for_eop.sch.
Pass if no errors reported. Fail otherwise.
Test type
Capability
Test
/om_procedure
om:procedure: expected contents is eop:EarthObservationEquipment
or an extension.
Requirement
Test purpose
Verify that the content model of any om:procedure element is an eop:EarthObservationEquipment
element or an extension (alt, atm, lmb or ssp corresponding to the product
type or mission-specific extension with appropriate attribute eop:type)
Test method
Validate the XML document using the rule
using_strict
and
using_extended
per productType
of the Schematron document schematron_rules_for_eop.sch.
Pass if no errors reported. Fail otherwise.
Test type
Capability
Test
eop:acquisitionParameters: expected contents is eop:Acquisition
or an extension
Requirement
Test purpose
Verify that the content model of any eop:acquisitionParameters
element is an eop:Acquisition element or an extension (sar, alt, atm, lmb corresponding
to the product type or mission-specific extension with appropriate attribute
eop:type).
Test method
Validate the XML document using the rules
acquisition_strict
and
acquisition_extended per product type,
of the Schematron document
schematron_rules_for_eop.sch. Pass if no errors reported. Fail otherwise.
Test type
Capability
Test
om_result
om:result : expected contents is eop:EarthObservationResult or
an extension
Requirement
Test purpose
Verify that the content model of any om:result element is an
eop:EarthObservationResult element or an extension (opt, atm, ssp
corresponding to the product type or mission-specific extension with
appropriate attribute eop:type)
Test method
Validate the XML document using the rule
result_strict,
and
result_extended
per product Type
of the Schematron document schematron_rules_for_eop.sch.
Pass if no errors reported. Fail otherwise.
Test type
Capability
Test
/om_featureOfInterest
om:featureOfInterest: expected contents is eop:Footprint or an
extension corresponding to the product type (alt, lmb, ssp)
Requirement
Test purpose
Verify that the content model of any om:featureOfInterest
element is an eop:Footprint element or an extension corresponding to the
product type (alt, lmb, ssp).
Test method
Validate the XML document using the rule
eop_featureOfInterest, alt_featureOfInterest, lmb_featureOfInterest
and
ssp_featureOfInterest
of the
Schematron document schematron_rules_for_eop.sch. Pass if no errors reported.
Fail otherwise.
Test type
Capability
Test
/om_phenomenonTime
om:phenomenonTime : expected contents is gml:TimePeriod/gml:beginPosition
and gml:TimePeriod/gml:endPosition
Requirement
Test purpose
Verify that the content model of any om:phenomenonTime element
is an gml:TimePeriod/gml:beginPosition and gml:TimePeriod/gml:endPosition
Test method
Validate the XML document using the rule
validTime_beginPosition
and
validTime_endPosition
of the Schematron document schematron_rules_for_eop.sch. Pass if no
errors reported. Fail otherwise.
Test type
Capability
Test
/multiExtentOf
Footprint eop:multiExtentOf : expected contents is gml:MultiSurface/gml:surfaceMembers/gml:Polygon/gml:exterior/gml:LinearRing/gml:posList.
Requirement
Test purpose
Verify that the content model of any eop:multiExtentOf element
is an gml:MultiSurface/gml:surfaceMembers/gml:Polygon/gml:exterior/gml:LinearRing/gml:posLis
element
Test method
Validate the XML document using the rule
footprint_extentOf
of the Schematron document
schematron_rules_for_eop.sch. Pass if no errors reported. Fail otherwise.
Test type
Capability
Test
Footprint eop:centerOf : expected contents is gml:Point/gml:pos.
Requirement
Test purpose
Verify that the content model of any eop:centerOf element is an gml:Point/gml:pos
element.
Test method
Validate the XML document using the rule
footprint_centerOf
of the Schematron document
schematron_rules_for_eop.sch. Pass if no errors reported. Fail otherwise.
Test type
Capability
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
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
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.
Table
: GML vs. O&M observation properties (optional properties in italics)
GML
O&M
validTime
phenomenonTime
using
procedure
target
featureOfInterest
resultOf
result
observedProperty
parameter
resultQuality
resultTime
validTime
relatedObservation
metadata
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).
Figure:
: Model-driven approach of ISO TC211
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
Date
Release
Author
Paragraph modified
Description
12 July 2010
0.1.0
Frederic Houbie
& Fabian Skivee
N/A
Initial document
11 January 2011
0.2.0
Fabian Skivée
Integrate comments
from Steven Smolders and Jolyon Martin
16 May 2011
1.0.0
F. Houbie
OAB comments
ESA comments
19 June 2013
1.0.1
S.
Smolders
W. De Smet
Update taking into account the first
set of Change Requests
27 November 2013
1.0.2
S. Smolders
7.5
Update to ATS following ETS
implementation
06 January 2014
1.0.3
W. De Smet
6.2
Update of namespaces to version 2.1
18 February 2014
1.0.4
S. Smolders
8.1.1
Update taking into account the
change request related to creation and modification date
22 October 2014
1.1.0
S. Smolders
Update following approval of all
change requests and incorporation of OAB comments
23 March 2016
1.1.0
S. Simmons
Convert document to updated OGC
template for publishing, minor text edits throughout document
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,
[12]
W3C,
XML Schema Part 1: Structures
[13]
W3C,
XML Schema Part 2: Datatypes
[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.