OGC Standard

OGC MetOcean Application profile for WCS2.1: Part 0 MetOcean Metadata
Peter Trevelyan Editor Paul Hershberg Editor Steve Olson Editor
Version: 1.0
Additional Formats: XML PDF DOC
OGC Standard


Document number:15-045r7
Document type:OGC Standard
Document subtype:Implementation
Document stage:Approved
Document language:English


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 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.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.

Suggested additions, changes and comments on this standard are welcome and encouraged. Such suggestions may be submitted using the online change request form on OGC web site:


I.  Abstract

This document defines a MetOcean Metadata profile consisting of an information model and an XML encoding for the following three operations:

  1. GetCapabilities - a WCS server describes the services and operations via a GetCapabilities document.

  2. DescribeCoverage - a WCS server describes the contents of a specific coverage via a DescribeCoverage document.

  3. DescribeCoverageCollection — a WCS server describes the contents of a specific coverage collection via a DescribeCoverageCollection document.

Metadata and vocabularies are defined that provide interoperability of these operations and documents using common semantics. The information model proposed supports MetOcean specific concepts, but these may be useful in other communities.

II.  Keywords

The following are keywords to be used by search engines and document catalogues.

ogcdoc, OGC document, WCS, coverage, collection, meteorology, oceanography, NWP, analysis, result mask, observation, measurement, simulation, O&M and MetOcean

III.  Preface

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.

IV.  Security Considerations

No security considerations have been made for this standard.

V.  Submitting Organizations

The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

VI.  Submitters

All questions regarding this submission should be directed to the editor or the submitters:

Name Affiliation
Peter Trevelyan Met Office, UK
Paul Hershberg

National Oceanic and Atmospheric Administration (NOAA)

National Weather Service (NWS)

Steve Olson

National Oceanic and Atmospheric Administration (NOAA)

National Weather Service (NWS)

OGC MetOcean Application profile for WCS2.1: Part 0 MetOcean Metadata

1.  Scope

The purpose of this Met Ocean profile of WCS2.1 is to define the metadata returned in the response documents resulting from the WCS2.1 operations: GetCapabilities, and DescribeCoverage; for use within the meteorological and oceanographic communities. It also defines the new operation DescribeCoverageCollection.

This work has been done by members of the OGC MetOcean Domain Working Group.

2.  Conformance

This standard defines:

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 site1.

In order to conform to this OGC™ interface standard, a software implementation shall choose to implement:


b) Any one of the conformance levels specified in Annex A (normative).

All requirements-classes and conformance-classes described in this document are owned by the standard(s) identified.

Requirements and conformance test URIs defined in this document are relative to:

This document establishes the following requirements and conformance classes:-

covcoll-offering of URI defining covcoll-offering at a conceptual level in 8.1; the corresponding conformance class is covcoll-offering with URI . See A.1.

metOcean-observation-specialisation of URI defining the metOcean-observation-specialisation at a conceptual level in clause 9.1; the corresponding conformance class is metOcean-observation-specialisation with URI . See A.2.

simulation-process-metadata of URI defining the simulation-process-metadata at a conceptual level in clause 9.2; the corresponding conformance class is simulation-process-metadata . See A.3.

result-mask of URI defining the result-mask at a conceptual level in clause 9.3; the corresponding conformance class is result-mask . See A.4.

getCapabilities-metOcean-extension of URI defining the getCapabilities-metOcean-extension in clause 9.4 the corresponding conformance class . See A.5.

getCapabilities-coverageSummary of URI defining the getCapabilities-coverageSummary response in clause 9.5 the corresponding conformance class with URI . See A.6.

getCapabilities-coverageCollectionSummary of URI defining the getCapabilities-coverageCollectionSummary response in clause 9.6 the corresponding conformance class with URI . See A.7.

getCapabilities-groups of URI defining the getCapabilities-groups response in clause 9.7 the corresponding conformance class with URI . See A.8.

describeCoverageCollection of URI defining the describeCoverageCollection response in clause 9.8 the corresponding conformance class with URI . See A.9.

describeCoverageCollection-protocol-binding of URI defining the describeCoverageCollection-protocol-binding on the conceptual level in clause 9.9 the corresponding conformance class is offering with URI . See A.10.

describeCoverageCollection-get-kvp of URI defining describeCoverageCollection-get-kvp on the conceptual level in clause 9.10 the corresponding conformance class is offering with URI . See A.11.

describeCoverageCollection-post-xml of URI defining describeCoverageCollection-post-xml on the conceptual level in clause 9.11 the corresponding conformance class is offering with URI . See A.12.

describeCoverageCollection-soap of URI defining describeCoverageCollection-soap on the conceptual level in clause 9.12 the corresponding conformance class is offering with URI . See A.13.

metoceanDescribeCoverage of URI defining the describeCoverage response in 9.13, the corresponding conformance class with URI . See A.14.

3.  Normative references

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

Policy SWG: OGC 08-131r3, The Specification Model — Standard for Modular specifications. Open Geospatial Consortium (2009).

ISO: ISO/TS 19103:2005, Geographic information — Conceptual schema language. International Organization for Standardization, Geneva (2005).

ISO: ISO 8601:2004, Data elements and interchange formats — Information interchange — Representation of dates and times. International Organization for Standardization, Geneva (2004).

ISO: ISO 19107:2019, Geographic information — Spatial schema. International Organization for Standardization, Geneva (2019).

ISO: ISO 19111:2007, Geographic information — Spatial referencing by coordinates. International Organization for Standardization, Geneva (2007).

ISO: ISO 19123:2005, Geographic information — Schema for coverage geometry and functions. International Organization for Standardization, Geneva (2005).

ISO: ISO 19115-1:2014, Geographic information — Metadata — Part 1: Fundamentals. International Organization for Standardization, Geneva (2014).

ISO: ISO 19156:2011, Geographic information — Observations and measurements. International Organization for Standardization, Geneva (2011).

ISO: ISO 19136:2007, Geographic information — Geography Markup Language (GML). International Organization for Standardization, Geneva (2007).

Peter Baumann: OGC 17-089r1, OGC Web Coverage Service (WCS) 2.1 Interface Standard — Core. Open Geospatial Consortium (2018).

Marie-Françoise Voidrot-Martinez, Chris Little, Jürgen Seib, Roy Ladner, Adrian Custer, Jeff de La B: OGC 12-111r1, OGC Best Practice for using Web Map Services (WMS) with Time-Dependent or Elevation-Dependent Data. Open Geospatial Consortium (2014).

Simon Cox: OGC 10-025r1, Observations and Measurements — XML Implementation. Open Geospatial Consortium (2011).

Alexandre Robin: OGC 08-094r1, OGC® SWE Common Data Model Encoding Standard. Open Geospatial Consortium (2011).

Peter Baumann, Eric Hirschorn, Joan Masó: OGC 09-146r8, OGC Coverage Implementation Schema with Corrigendum. Open Geospatial Consortium (2019).

Arliss Whiteside Jim Greenwood : OGC 06-121r9, OGC Web Service Common Implementation Specification. Open Geospatial Consortium (2010).

UCUM: Unified Code for Units of Measure (UCUM) – Version 1.9, 2013,

OMG UML 2.5.1, Unified Modeling Language. (2017).

W3C: Extensible Mark-up Language (XML) – Version 1.0 (Fifth Edition), August 2008

W3C: XML Schema – Version 1.0 (Second Edition), October 2004

4.  Terms and definitions

For the purposes of this document, the following terms and definitions apply.

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.

This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.

For the purposes of this document, the following additional terms and definitions apply. There is some variation in the specific use of some technical terms within the meteorological domain. We have attempted to follow common usage, referring where possible to the WMO No.306


numerical weather prediction model

A mathematical model of the atmosphere and oceans used to predict the weather based on current weather conditions and are normally run at set times each day.

Synonyms: forecast model, NWP Model, simulation

EXAMPLE The ECMWF model that runs twice per day and creates a ten day prediction of the global atmosphere.


reference time

A temporal parameter used to represent a time axis that can be mapped to some relevant referent time other than validity time. The semantic meaning can differ for different types of data. For numerical weather forecasts it may be a nominal time where observations have been assimilated to initialize the calculation. This will be expressed by using the om:parameter element.

Synonym: model run time.

Note 1 to entry: “reference time” will used in preference to “model run time” as it is more generic and includes services that may be continually updated.


validity time

An attribute value specified by an instant in, or duration of, universal chronological time that identifies when information is valid or applicable. In [ISO 19156], the validity time has the semantics of phenomenonTime. Deciding if the data have a ‘validity time’ is an important step.

Synonym: verification time.

Note 1 to entry: Forecast models running with different reference times will have, for some fields, the same verification time if the durations of the different model runs overlap.


Result Mask

Provides the means to indicate for a set of elevations and times the availability of specific parameters for a given output dataset. See Section 7.6 and Figure 5. This mechanism is important as it allows the 2D coverages to be stacked together in time and elevation to form a 4D coverage even though some of the coverages have gaps.

Note 1 to entry: A data mask is described using a “cis:GeneralGridCoverage”.



A WMO (World Meteorological Organisation) format for gridded binary data exchanged between member countries, including a controlled vocabulary defined in tables.


Web Coverage Service 2.1 (WCS2.1)

An OGC standard that refers to the exchange of geospatial information as ‘coverages’: digital geospatial information representing space-varying phenomena.



A WCS server request for a list of what operations and services (“capabilities”) are being offered by that server.



A WCS server request for additional information about a coverage that a client wants to query. It returns information about the coordinate reference system (CRS), the metadata, the domain, the range and the formats available. A client generally will need to issue a DescribeCoverage request before it can make the proper GetCoverage request.



A WCS server request, newly defined in this document, for additional information about a CoverageCollection that a client wants to query. It returns information about the metadata and the domain, including, principally, a listing of the coverages that constitute the collection.



The MetOcean Profile introduces the term Groups as a way of structuring the GetCapabilities response to provide a hierarchical way of nesting “services”. The nesting reflects the architecture/organisation of the various services. This has the advantage of the client being able to connect to different service end points without having to know beforehand their respective addresses.

5.  Conventions

This sections provides details and examples for any conventions used in the document.

5.1.  Abbreviated terms

GML Geography Mark-up Language

O&M Observations and Measurements

OGC Open Geospatial Consortium

MetOcean Meteorological/Oceanographic

NWP Numerical Weather Prediction

SWE OGC Sensor Web Enablement

UML Unified Modelling Language

WCS2.1 OGC Web Coverage Service version 2.1

WMO World Meteorological Organisation

XML W3C Extensible Markup Language

XSD W3C XML Schema Definition Language

5.2.  Schema language

The XML implementation specified in this standard is described using the XML Schema language (XSD) [XML Schema Part 1: Structures, XML Schema Part 2: Datatypes] and Schematron [ISO/IEC 19757-3, Information technology — Document Schema Definition Languages (DSDL) — Part 3: Rule-based validation — Schematron].

5.3.  UML notation

The diagrams that appear in this standard are presented using the Unified Modeling Language (UML) static structure diagram.

Note: Within the context of this standard, the following color scheme is used to identify the package where the class exists. This is just for informative purposes.

Blue: CIS (Coverage Implementation Schema 1.1)

Orange: ISO19156 – Observations & Measurements

Green: This standard

Tan: WCS2.1

6.  Vocabularies

This standard defines a number of properties that require the use of codes or vocabulary items. In some cases a list of terms is provided. Where no codes are provided, (the link to the WMO registry is in italics), it is expected that a list will be developed in the future, or a local code list may be used. A summary of the vocabularies is shown in Table 1. The WMO is responsible for managing the content of these vocabularies. Once agreement is reached for definitions, the MetOcean DWG will submit updates to the OGC Naming Authority. In the future the vocabularies may be extended to other disciplines, e.g. climate community. These communities have their own conventions e.g CF (climate forecasting see

(as used in the DescribeCoverage response)

Table 1 — Summary of vocabularies within this standard

Code list Package(s) Code items defined
disciplineCode SimulationProcessMetadata Yes
typeOfDataCode SimulationProcessMetadata Yes
significanceOfReferenceTimeCode SimulationProcessMetadata Yes
originatingCentreCode SimulationProcessMetadata Yes
productionStatusCode SimulationProcessMetadata Yes
typeOfCalendarCode SimulationProcessMetadata Yes
fixedSurfaceTypesAndUnitsCode SimulationProcessMetadata Yes

7.  Non-Normative (Informative) Material

The MetOcean Application Profile for WCS2.1 is an initiative of the MetOcean DWG to develop international standards and address interoperability of meteorological and oceanographic information systems.

What’s driving the work is the need to transfer increasing amounts of data across networks. This can be done more efficiently by sub-setting the data on the server side and transferring the relevant data to the client. The obvious candidate for addressing this increased data dissemination need is the OGC’s WCS2.1 and it is therefore logical to extend this standard to customise MetOcean specific metadata. In addition, the advent of the CIS1.1 (Coverage Implementation Schema) has made this much easier through the use of axis specific definitions.

7.1.  WCS2.1

The WCS2.1 specification (see OGC 17-089r1) forms the core Web Coverage Service standard and the extensions (see below). The core standard describes the key operations GetCapabilities, DescribeCoverage and GetCoverage. One of the shortcomings of the prior version WCS2.0 is the metadata aspects. The metadata (other than basic WCS) needs to be community specific and is added by using the wcs:Extension element. Currently, the only profile is for the Earth Observing community.

WCS Core Extensions

The main benefit of WCS2.1 is that it allows the description of a CIS 1.1 Coverage (see Figure 1 and Figure 3). This is important as CIS 1.1 supports multi-dimensional coverages and therefore supports the MetOcean profile.


Figure 1 — WCS CoverageDescriptions UML class diagram

7.2.  Key Concepts

7.2.1.  A Short NWP (Numerical Weather Prediction) Primer

The term “NWP model” refers to a computer simulation used to forecast the future state of the ocean/atmosphere. A NWP model is normally “run” at a set time and repeated at regular intervals during the day; the nominal “start” time is known (amongst the MetOcean community), as the “model run time” i.e. a notional starting point. All forecast times for a specific model run are therefore relative to this “reference” time. It is important to note that the term “reference time” will be used in preference to “model run time” as it is more generic and includes services that may be continually updated.

7.2.2.  Post processing

It is becoming increasingly common for raw NWP model output to be “post processed” using a number of techniques ranging from the application of statistical methods based on past model behaviour to adjustments made using ensemble forecasts. As we move away from simple deterministic models i.e. raw model output, the notion of reference time becomes less useful and terms such as “simulated forecast” become more meaningful.

7.3.  Coverages

The WCS core defines a coverage as a digital representation of some “space-time varying phenomenon”. Coverages contain a “DomainSet” component describing the coverage’s domain (i.e. the locations for which values are stored in the coverage) and a “Range­Set” component containing the values of the coverage. In addition, a “coverage” also contains a “RangeType” element that describes the coverage’s RangeSet data structure that consists of one or more fields (also referred to as parameters) that uses the SWE Common [OGC 08-094] Data­Record. The metadata component represents an extensible slot for metadata.

7.3.1.  4D Coverages

A typical NWP forecast simulation may be expressed as a set of 2D coverages, often, but not always based on rectified grids. A typical model run contains thousands of 2D coverages and the metadata returned by the GetCapabilites response therefore soon becomes unmanageable. The problem can be simplified by identifying, where possible, “4D Coverages” from many 2D coverages, as shown in Figure 2.


Figure 2 — Diagram denoting the visualization of a stack of 2D coverages as one true 4D coverage object

7.3.2.  CIS1.1 Dependency

This simplification of identifying a 4D coverage from many 2D coverages has been made much easier by using the OGC’s Coverage Implementation Schema (CIS1.1) OGC 09-146r5, which is shown in Figure 3. CIS1.1 is a core component of WCS2.1


Figure 3 — UML Diagram representing the coverage model (CIS1.1).

A typical NWP forecast simulation also has a number of different vertical coordinates: for example, pressure, height above mean sea level, height above ground, surface, max wind level, etc. As long as the 2D coverages all share one of these vertical coordinates, and the same horizontal and temporal domains, a 4D coverage can be identified from the many 2D coverages. This transformation of a stack of 2D coverages to one 4D coverage can be challaging as vertical and temporal axes are not regular and need to be specifically described; but it is the “GeneralGridCoverage”, as described by the OGC’s CIS1.1 (also shown in

Figure 3 – UML Diagram representing the coverage model (CIS1.1).), that makes this irregular axis labelling and enumeration possible.

Since this key concept, afforded by CIS1.1, changes the traditional view that coverage data is a set of 2D fields (each with a level, level type, parameter name and forecast period), we can now describe the whole atmosphere (ocean) as a multidimensional 4D cube that contains parameters, e.g. temperature, wind, humidity (salinity), etc. Coverages are no longer labelled as parameters (such as temperature or salinity), but instead are defined by (axis) dimensions that can contain one of more of these meteorological/oceanographic parameters.

The 2D to 4D transformation results in a reduction in the number of coverage identifiers, thus reducing complexity. This reduces 1) the number of data coverage queries necessary because the number of coverages is reduced (for WCS2.1 this equates to fewer GetCoverage operations) and 2) the amount of metadata returned in a GetCapabilities response document. The effect on both the GetCoverage requests and GetCapabilities responses for 2D vs 4D coverages was undertaken and can be accessed via the following link:

Note, there are special cases where the vertical axis has no vertical dependency, e.g. surface, max wind level, but still needs to be specified in order for it to be named. It is also the case that some parameters will belong to more than one coverage, e.g. surface, isobaric, etc.

7.4.  Groups and Collections

7.4.1.  Groups

Meteorological and oceanographic data are by nature hierarchical and the ability to group entities together is important. Thus, a set of simulations may be clustered together to form a logical group. The MetOcean Profile introduces the term Groups as a way of structuring the GetCapabilities response to provide a hierarchical way of nesting “services”. Groups simply allow for the organization of data, and, if required, have service endpoints also known as serviceInstances. There is nothing geospatial about Groups. The main benefit of Groups is in creating a structure that reflects the organization of the intended use of data, rather than its underlying structure. Figure 4 depicts a top level Group as “US Models” with two subsequent Groups as the “GFS” and “HRRR” NWP models. The MetOcean Profile supports an organized response from a GetCapabilities request by utilizing Groups.


Figure 4 — An example of a set of groups and coverage collections

7.4.2.  CoverageCollections

A CoverageCollection is a useful mechanism for grouping together coverages into a collection, very similar to a feature collection. This mechanism for grouping coverages is particularly relevant to a NWP output as this by nature is a collection of coverages which are related by their horizontal and temporal footprint.

Each CoverageCollection is a single, uniquely identified resource identifying the member coverages. Each coverage within a CoverageCollection shares characteristics such as provenance and the horizontal and temporat CRS’s. Use of CoverageCollection resources makes it simpler to refer to an aggregate set of coverage resources (using the identifier), and common metadata may be attributed to the CoverageCollection resource itself. The CoverageCollection identifier may have a semantically meaningful name such as GFS_Global_2015-05-15T00.00.00Z; synonymous with a specific “model run” or simulation (Figure 4 also denotes a CoverageCollection as a specific model at a specific run time, e.g. “GFS 00Z Run”).

There is also an additional benefit of CoverageCollections: a WCS server is able to suppress information about individual coverages in its GetCapabilities response. Thus, the XML document provided by the WCS end-point that supports the CoverageCollection is significantly smaller and easier to parse. This results in mitigating challenges arising from working with very large XML documents. In such situations, a client application may gather information about the CoverageCollection resources from a WCS server using the new “DescribeCoverageCollection” service. All coverages contained in the collection are returned in a DescribeCoverageCollection response. A user can then request information for each member coverage in the DescribeCoverage request.

Again, this reiterates how the new MetOcean Application Profile’s higher dimensional concepts of Groups and CoverageCollections help to reduce the size of GetCapabilities response documents that was first described in Section 7.3.2.

7.5.  Time Dependant data (from WMS Best Practice OGC document:12-111r1)

Complex data sets can have temporal dependencies of many kinds. This document adopts the phrase ‘validity time’ that is essentially identical to the concept of ‘phenomenonTime’ from the standard ISO 19156:2011, Geographic Information — Observations and Measurements, which refers to the applicability of the data using the chronological Gregorian calendar.

Frequently, data are additionally temporally dependent relative to some reference time instant. For example, observations may have an accession time into a data repository. Furthermore, numerical weather forecasts may have a nominal time where observations have been assimilated to initialize the calculation. Finally, watches, warnings, and advisory alerts may have a time when they are issued or published.

The diversity of such references precludes defining a dimension type with explicit semantics though the need for a mechanism to distinguish data based on some temporal referent is widely shared. The definition of a generic dimension called referenceTimeAxis, may be used for such occasions and is supported in this profile.

This WCS2.1 standard uses a combination of time stamp, a list of time stamps, or a start_time/end_time/time_interval to enumerate time. The semantics of this string representation of a time stamp is built from the time components and specific separators. A full string representation has the following format:



  • YYYY indicates a 4-digit year

  • MM indicates a month

  • DD indicates a day of a month

  • T is the separator between the date part and the time part

  • hh indicates an hour

  • mm indicates a minute

  • ss indicates a second

  • SSS indicates a millisecond

  • Z is the time zone designator for the zero UTC offset

The precision of a time stamp t is determined by the last time component. Time stamps may be associated with a time zone. If no time zone is specified with a time stamp t, then t is assumed to be in local time.

A time interval is a triple tmin/tmax/r where tmin and tmax are time stamps that define the lower and upper bounds of the interval and r is the resolution. The interval contains all time stamps tmin + i * r, i >= 0, that are lower or equal than tmax. A resolution r is represented by the format P [n1Y] [n2M] [n3D] [T [n4H] [n5M] [n6S]] where:

  • P is a starting character.

  • Y is the year designator that follows the value n1 for the number of years.

  • M is the month designator that follows the value n2 for the number of months.

  • D is the day designator that follows the value n3 for the number of days.

  • T is the time designator that precedes the time components of the representation.

  • H is the hour designator that follows the value n4 for the number of hours.

  • M is the minute designator that follows the value n5 for the number of minutes.

    Some Examples:

1- A Time stamp


2- A list of time stamps

2015-05-15T00:00:00Z, 2015-05-15T06:00:00Z, etc.

3- A start and end time


4- Example of a start time/end time/interval


Example of a list of durations: (Note a reference time is specified using om:phenomenonTime) PT0H, PT6H, PT12H. Thus PT12H denotes a time duration of 12 hours relative to the reference time.

Where no reference time is specified, but the times are relative to a starting and end point, then a recurring time interval can be used:


Where no reference time is specified, a set of time stamps may be used, e.g. 2015-05-15T00:00:00Z, 2015-05-15T12:00:00Z, 2015-05-15T18:00:00Z (Note, where times are irregular then the form start/end/interval is not appropriate.)

7.6.  Result Mask

A result mask is used to depict the quality of data. The O&M model supports a result quality property (om:resultQuality) which is key in supporting a ResultMask, which would then allow a value to reflect the result quality for a given parameter (data values), level, and forecast period (Figure 5). In Figure 5, a blue symbol indicates missing data.


Figure 5 — Result Mask Diagram representing the irregularity of the time and vertical axes and the sparsity of the output in the coverage model

The ResultMask has a “GeneralGridCoverage” property as described by CIS1.1. Using a GeneralGridCoverage type allows for each axis of the coverage to be described using an irregular axis (i.e. cis:irregularAxis, which allows for enumeration) or a regular axis (i.e. cis:regularAxis, with start, end, and interval).

The vertical CRS is assigned by reference (see and the units of measure are specified in the WMO GRIB2 table 4.5. The “RangeSet” part of the coverage is a tuple list used to define quality value.

7.6.1.  CoverageSummary

Defines the summary of the coverages listed in the GetCapabilities response. This includes summary information for each coverage contained in each member (e.g. model run) of the simulation.

7.7.  MetOcean Profile and GetCapabilities

The MetOcean Application Profile modifies the GetCapabilities function to support three distinctive patterns, each having its own conformance class. These three patterns are based on the way the GetCapabilities response is configured, i.e. Groups, CoverageCollections or Coverage Summaries. These are illustrated in Figure 10, Figure 11, Figure 12, and Figure 13.

As stated in Section 7.4.1, the use of groups allows for a very flexible hierarchical approach, and, it is conceivable that each group may have separate “serviceInstances”. The net result is that groups support a service orientated architecture. It should be pointed out that these “end points” do not need to point to specific MetOcean services (e.g. a digital elevation model). Section 9.4 and Section 9.5 will provide examples to illustrate the supported patterns.

7.8.  The basic Observation type

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:

  • phenomenonTime (mandatory): The attribute phenomenonTime:TM_Object shall describe the time that the result applies to the property of the feature-of-interest. This is often the time of interaction by a sampling procedure or observation procedure with a real-world feature. In the case of a simulation this may be interpreted as a validity period denoting the time period for which the data is valid.

  • 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. for a meteorological forecast then it is intended to denote the time period for which the forecast may be used.

  • relatedObservation (optional): related observations providing important context for understanding the result

  • metadata (optional): descriptive metadata

  • featureOfInterest (mandatory): The association Domain links 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 links 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 links 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 links the OM_Observation to the OM_Process used to generate the result. The process has the role procedure with respect to the observation.

  • parameter: if present, the attributes parameter:NamedValue shall describe an arbitrary event-specific parameter, in this case the reference time of the simulation.

7.9.  MetOcean Observation metadata mapping to the Observations and Measurements model

To represent MetOcean metadata in a DescribeCoverage response, this profile extends the Observations and Measurements properties with MetOcean specific information. The relationship of MetOceanObservation to the O&M model is shown in Figure 7, Figure 8, Section 9.1, and Table 4. The adaptation, in places, uses specialisation particularly with respect to the basic Observation Type. In the examples the object MetOceanObservation is an abstract type and has to be substituted by a concrete object of type ObservationType.

There are benefits of organizing MetOcean metadata in line with the O&M model in a DescribeCoverage Response. By utilizing the O&M model’s ability to link to WMO registers there is support for a controlled vocabulary, facilitating interoperability and extensibility. Secondly, the O&M model supports links for references. Thus, the metadata is not tied to a specific data format, i.e. GRIB2. Thirdly, the O&M model supports the use of supports the use of common Atmopheric/Oceanic vertical reference systems. And finally, as described in Section 7.6, the O&M model provides a mechanism for quality control using a data Result Mask.

8.  CoverageCollection data model

8.1.  Requirements Class covcoll-offering

This requirements class specifies the underlying data model used to describe CoverageCollection resources and their relationship with the coverage resources themselves. These optional resources are part of the GetCapabilities response.

Requirements Class

Requirement 1


The cis:Envelope property, shall contain at a minimum, a horizontal bounding limit. Note the cis:Envelope element may be used to provide the bounding box in as many dimensions as is appropriate.

Requirement 2


The OfferedCoverageCollection cis:Envelope property shall only have those axes (as listed by the cis:axisLabels) that are shared by the Offered Coverages. Thus any axis that is unique to one of the constituent coverages would not be referenced by the CoverageCollection property cis:Envelope.

Requirement 3


All axes shared by the component coverages shall have the same axisExtent.

Requirement 4


Each CoverageCollection resource offered by a WCS server implementing this extension shall specify an identifier that is unique within the scope of that WCS server through their coverageCollectionId identifier.

8.2.  Requirement class overview

A WCS server implementing this extension offers a – possibly empty – set of CoverageCollection resources.