This document defines a MetOcean Metadata profile consisting of an information model and an XML encoding for the following three operations:
GetCapabilities - a WCS server describes the services and operations via a GetCapabilities document.
DescribeCoverage - a WCS server describes the contents of a specific coverage via a DescribeCoverage document.
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.
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
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):
- Met Office, UK
- National Weather Service (NOAA), US
All questions regarding this submission should be directed to the editor or the submitters:
|Peter Trevelyan||Met Office, UK|
National Oceanic and Atmospheric Administration (NOAA)
National Weather Service (NWS)
National Oceanic and Atmospheric Administration (NOAA)
National Weather Service (NWS)
OGC MetOcean Application profile for WCS2.1: Part 0 MetOcean Metadata
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.
This standard defines:
A MetOcean application profile that outlines the MetOcean specific metadata to be part of the DescribeCoverage response.
An amended GetCapabilities operation whose response provides a means of grouping together coverages and coverage collections such that the response document can reflect a user defined hierarchy. A client application may request this information about CoverageCollection resources in a GetCapabilities response by specifying the token, in the Sections element of the GetCapabilities request (See section 9.5, 9.6, 9.7 for details).
A new operation “DescribeCoverageCollection” that is used to list the coverages contained within a “CoverageCollection” including the respective bindings.
The conformance classes that describe the CoverageCollection data model.
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 http://www.opengis.net/spec/WCS_application-profile_metocean/1.0/req/covcoll-offering defining covcoll-offering at a conceptual level in 8.1; the corresponding conformance class is covcoll-offering with URI http://www.opengis.net/spec/WCS_application-profile_metocean/1.0/conf/covcoll-offering . See A.1.
metOcean-observation-specialisation of URI http://www.opengis.net/spec/WCS_application-profile_metocean/1.0/req/metOcean-observation-specialisation defining the metOcean-observation-specialisation at a conceptual level in clause 9.1; the corresponding conformance class is metOcean-observation-specialisation with URI http://www.opengis.net/spec/WCS_application-profile_metocean/1.0/conf/metOcean-observation-specialisation . See A.2.
simulation-process-metadata of URI http://www.opengis.net/spec/WCS_application-profile_metocean/1.0/req/simulation-process-metadata defining the simulation-process-metadata at a conceptual level in clause 9.2; the corresponding conformance class is simulation-process-metadata http://www.opengis.net/spec/WCS_application-profile_metocean/1.0/conf/simulation-process-metadata . See A.3.
result-mask of URI http://www.opengis.net/spec/WCS_application-profile_metocean/1.0/req/result-mask defining the result-mask at a conceptual level in clause 9.3; the corresponding conformance class is result-mask http://www.opengis.net/spec/WCS_application-profile_metocean/1.0/conf/result-mask . See A.4.
getCapabilities-metOcean-extension of URI http://www.opengis.net/spec/WCS_application-profile_metocean/1.0/req/getCapabilities-metOcean-extension defining the getCapabilities-metOcean-extension in clause 9.4 the corresponding conformance class http://www.opengis.net/spec/WCS_application-profile_metocean/1.0/conf/getCapabilities-metOcean-extension . See A.5.
getCapabilities-coverageSummary of URI http://www.opengis.net/spec/WCS_application-profile_metocean/1.0/req/getCapabilities-coverageSummary defining the getCapabilities-coverageSummary response in clause 9.5 the corresponding conformance class with URI http://www.opengis.net/spec/WCS_application-profile_metocean/1.0/conf/getCapabilities-coverageSummary . See A.6.
getCapabilities-coverageCollectionSummary of URI http://www.opengis.net/spec/WCS_application-profile_metocean/1.0/req/getCapabilities-coverageCollectionSummary defining the getCapabilities-coverageCollectionSummary response in clause 9.6 the corresponding conformance class with URI http://www.opengis.net/spec/WCS_application-profile_metocean/1.0/conf/getCapabilities-coverageCollectionSummary . See A.7.
getCapabilities-groups of URI http://www.opengis.net/spec/WCS_application-profile_metocean/1.0/req/getCapabilities-groups defining the getCapabilities-groups response in clause 9.7 the corresponding conformance class with URI http://www.opengis.net/spec/WCS_application-profile_metocean/1.0/conf/getCapabilities-groups . See A.8.
describeCoverageCollection of URI http://www.opengis.net/spec/WCS_application-profile_metocean/1.0/req/describeCoverageCollection defining the describeCoverageCollection response in clause 9.8 the corresponding conformance class with URI http://www.opengis.net/spec/WCS_application-profile_metocean/1.0/conf/describeCoverageCollection . See A.9.
describeCoverageCollection-protocol-binding of URI http://www.opengis.net/spec/WCS_application-profile_metocean/1.0/req/describeCoverageCollection-protocol-binding defining the describeCoverageCollection-protocol-binding on the conceptual level in clause 9.9 the corresponding conformance class is offering with URI http://www.opengis.net/spec/WCS_application-profile_metocean/1.0/conf/describeCoverageCollection-protocol-binding . See A.10.
describeCoverageCollection-get-kvp of URI http://www.opengis.net/spec/WCS_application-profile_metocean/1.0/req/describeCoverageCollection-get-kvp defining describeCoverageCollection-get-kvp on the conceptual level in clause 9.10 the corresponding conformance class is offering with URI http://www.opengis.net/spec/WCS_application-profile_metocean/1.0/conf/describeCoverageCollection-get-kvp . See A.11.
describeCoverageCollection-post-xml of URI http://www.opengis.net/spec/WCS_application-profile_metocean/1.0/req/describeCoverageCollection-post-xml defining describeCoverageCollection-post-xml on the conceptual level in clause 9.11 the corresponding conformance class is offering with URI http://www.opengis.net/spec/WCS_application-profile_metocean/1.0/conf/describeCoverageCollection-post-xml . See A.12.
describeCoverageCollection-soap of URI http://www.opengis.net/spec/WCS_application-profile_metocean/1.0/req/describeCoverageCollection-soap defining describeCoverageCollection-soap on the conceptual level in clause 9.12 the corresponding conformance class is offering with URI http://www.opengis.net/spec/WCS_application-profile_metocean/1.0/conf/describeCoverageCollection-soap . See A.13.
metoceanDescribeCoverage of URI http://www.opengis.net/spec/WCS_application-profile_metocean/1.0/req/describeCoverage defining the describeCoverage response in 9.13, the corresponding conformance class with URI http://www.opengis.net/spec/WCS_application-profile_metocean/1.0/conf/describeCoverage . 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). https://portal.ogc.org/files/?artifact_id=34762&version=2
ISO: ISO/TS 19103:2005, Geographic information — Conceptual schema language. International Organization for Standardization, Geneva (2005). https://www.iso.org/standard/37800.html
ISO: ISO 8601:2004, Data elements and interchange formats — Information interchange — Representation of dates and times. International Organization for Standardization, Geneva (2004). https://www.iso.org/standard/40874.html
ISO: ISO 19107:2019, Geographic information — Spatial schema. International Organization for Standardization, Geneva (2019). https://www.iso.org/standard/66175.html
ISO: ISO 19111:2007, Geographic information — Spatial referencing by coordinates. International Organization for Standardization, Geneva (2007). https://www.iso.org/standard/41126.html
ISO: ISO 19123:2005, Geographic information — Schema for coverage geometry and functions. International Organization for Standardization, Geneva (2005). https://www.iso.org/standard/40121.html
ISO: ISO 19115-1:2014, Geographic information — Metadata — Part 1: Fundamentals. International Organization for Standardization, Geneva (2014). https://www.iso.org/standard/53798.html
ISO: ISO 19156:2011, Geographic information — Observations and measurements. International Organization for Standardization, Geneva (2011). https://www.iso.org/standard/32574.html
ISO: ISO 19136:2007, Geographic information — Geography Markup Language (GML). International Organization for Standardization, Geneva (2007). https://www.iso.org/standard/32554.html
Peter Baumann: OGC 17-089r1, OGC Web Coverage Service (WCS) 2.1 Interface Standard — Core. Open Geospatial Consortium (2018). http://docs.opengeospatial.org/is/17-089r1/17-089r1.html
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). https://portal.ogc.org/files/?artifact_id=56394
Simon Cox: OGC 10-025r1, Observations and Measurements — XML Implementation. Open Geospatial Consortium (2011). https://portal.ogc.org/files/?artifact_id=41510
Alexandre Robin: OGC 08-094r1, OGC® SWE Common Data Model Encoding Standard. Open Geospatial Consortium (2011). https://portal.ogc.org/files/?artifact_id=41157
Peter Baumann, Eric Hirschorn, Joan Masó: OGC 09-146r8, OGC Coverage Implementation Schema with Corrigendum. Open Geospatial Consortium (2019). http://docs.opengeospatial.org/is/09-146r8/09-146r8.html
Arliss Whiteside Jim Greenwood : OGC 06-121r9, OGC Web Service Common Implementation Specification. Open Geospatial Consortium (2010). https://portal.ogc.org/files/?artifact_id=38867
UCUM: Unified Code for Units of Measure (UCUM) – Version 1.9, 2013, http://unitsofmeasure.org/
OMG UML 2.5.1, Unified Modeling Language. (2017). https://www.omg.org/spec/UML/2.5.1/
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 http://www.wmo.int/pages/prog/www/WMOCodes.
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.
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.
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.
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.
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
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
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 http://cfconventions.org/)
(as used in the DescribeCoverage response)
Table 1 — Summary of vocabularies within this standard
|Code list||Package(s)||Code items defined|
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.
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
WCS Range Subsetting Extension, version 1.0.0, OGC 12-040
WCS Scaling Extension, version 1.0.0, OGC 12-039
WCS Interpolation Extension, version 1.0.0, OGC 12-049
WCS CRS Extension, version 1.0, OGC 11-053r1
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.
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 “RangeSet” 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] DataRecord. 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: https://sats.nws.noaa.gov/~WGDS/powerPointPresentations/Effect_of_4D_coverages_vs_2D_coverages.pptx.
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
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
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.
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 http://codes.wmo.int/grib2/codeflag/4.5) 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.
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.
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.
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.
All axes shared by the component coverages shall have the same axisExtent.
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.