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

8.2.1.  CoverageOfferings

The new class CoverageOfferings extends wcs:CoverageOfferings, established in WCS core (OGC 17-089r1) by adding an additional content OfferedCoverageCollection, defined in Table 2 and shown in Figure 6.

Table 2 — METOCEAN::CoverageOfferings components

8.2.2.  OfferedCoverageCollection

An OfferedCoverageCollection, as specified in Table 3, contains a single CoverageCollection resource.

Table 3 — COVCOLL::OfferedCoverageCollection components

9.1.1.  Requirements class overview

The MetOceanObservation requirements class defines how metadata appropriate to the MetOcean community will be expressed as part of the responses to a WCS2.1 DescribeCoverage request.

9.1.2.  MetOceanObservation

MetOcean observations are defined as a specialised type OM_Observation from ISO19156 (as previously denoted in Section 7.9), with the following qualifications:

• The feature of interest is the entity about which the observation is made and forecasts clearly relate to the real world. For example, we may provide a weather forecast for the North Atlantic European area with the express intention of sampling the grid to provide a forecast for a specific location and time such as a town or airport. Thus the sampling regime is a proxy for the real entity of interest and the Observations and Measurements model provides a conceptual model linking to these two concepts i.e. SamplingFeatures. The sampling feature is related to the real world via the property <sam:sampledFeature> (and further specialisations are provided by the addition of the shape property via SF_SpatialSamplingFeature and sub-types thereof). For NWP models the most obvious real-world-entity is the domain over which the simulation was carried out by using the shape property.

• The observedProperty references WMO GRIB2 code tables that list, by “Product Discipline” ref http://codes.wmo.int/grib2/codeflag/0.0; the list of disciplines defines the domain of the environment being measured.

• The procedure references the metadata that describes the procedure that was used by the simulation process. This is described in a separate conformance class. Note that this is done by reference and although in this document these point to the WMO GRIB2 code tables, other controlled vocabularies could be used.

• The resultQuality will point to the result mask used to indicate if a parameter is available at a particular time/level.

• The validTime is the time period that spans the first and last validity times of the forecast.

Table 4 — METOCEAN::MetOceanObservation properties

9.1.3.  metocean::ObservedProperties

The properties relating to a NWP model as used in weather, climate and ocean forecast models.

Table 5 — METOCEAN::ObservedProperties

9.1.4.  SimulationProcessDomain

The SimulationProcessDomain.

Table 6 — METOCEAN::SimulationProcessDomain Properties

9.1.5.  metocean::Footprint

A description of the horizontal domain of the Simulation.

Table 7 — METOCEAN::Footprint

9.1.6.  metce:MeasurementContext

A description of the horizontal domain of the Simulation.

Table 8 — METCE::Process

9.1.7.  NamedValue

A description of the horizontal domain of the Simulation.

Table 9 — OM::NamedValue

9.2.1.  Requirements class overview

Simulations of weather, climate and ocean forecasts are made using mathematical models based on principles that are used to generate either short-term weather forecasts or longer-term climate predictions and as such have many properties that describe the spatial/temporal domain of the model and these are expressed using the simulation process description. Figure 8 contains the elements that are specialised for this profile that are referenced by the O&M model.

9.2.2.  SimulationProcessMetadata

The metadata for the computer simulation. Note that other tables may be used, but will have to be defined. As yet no other controlled vocabularies, that are accessible via register, have been created.

Table 10 — METOCEAN::SimulationProcessMetadata Properties

9.2.3.  DisciplineCode

A type capturing the relevant scientific discipline.

Table 11 — METOCEAN::DisciplineCode code items

9.2.4.  TypeOfDataCode

A type code capturing the type of products.

Table 12 — METOCEAN::TypeOfDataCode code items

9.2.5.  SignificanceOfReferenceTimeCode

A type code capturing the significance of the referenceTime.

Table 13 — METOCEAN::SignificanceOfReferenceTimeCode code Items

9.2.6.  OriginatingCentreCode

A code list to indicate the centre responsible for the product, this is referenced by http://codes.wmo.int/grib2/codeflag/0

9.2.7.  ProductionStatusCode

A type code capturing the significance of the reference time.

Table 14 — METOCEAN::ProductionStatusCode code Items

9.2.8.  TypeOfCalendarCode

A type code capturing the significance of the Calendar used.

Table 15 — METOCEAN::TypeOfCalendarCode code Items

9.2.9.  FixedSurfaceTypesAndUnits

The code list is used to indicate the surface type (cf vertical CRS) and the associated units. http://codes.wmo.int/grib2/codeflag/4.5

9.3.1.  Requirements class overview

The result mask is used in the DescribeCoverage response document and is linked by the element om:resultQuality that is part of the OM:Observation class. This result mask is quite generic and may be used, for example, to indicate where data may be missing (see Figure 5). It may also be used to indicate a quantifiable data quality. The ResultMask references a ParameterMask that contains the property TimeHeight Mask of type cis:GeneralGridCoverage. The “Domain Set” will define the axes and for the examples a (See appendix) temporal axis and vertical axis is used. One of the key uses is to be able to define a 4D coverage from a set of 2D coverages.

9.3.2.  ResultMask

The Resultmask holds quality control information and normally has a vertical and temporal axis as it most frequently used to indicate missing data (see figure 5).

Table 16 — METOCEAN::ResultMask

9.3.3.  ParameterMask

The properties relating to a Parameter Mask.

Table 17 — METOCEAN::Parameter Mask

9.4.1.  Requirements class overview

The MetOcean profile supports an extended GetCapabilites operation that allows for three distinct patterns, described in the next three requirements classes. To make implementation easier they are mutually exclusive. This MetOcean profile also provides a method of defining a hierarchical structure through the use of groups, with each group, if required, having a serviceInstance (as denoted in Section 7.4.1). The main benefit of this approach is to create a structure that reflects the organisation of intended use of the data, rather than its underlying structure.

Note that the CoverageCollectionMetadata element has a choice construct that means the three GetCapabilites conformance classes are based on each of these choices. These classes are described in sections 9.5, 9.6 and 9.7.

There is an optional constraint CountDefault specifying the maximum number of CoverageDescription elements reported in a DescribeCoverageCollection response

9.5.1.  Requirements class overview

The GetCapabilities-CoverageSummary requirements class supports the listing of coverage identifiers that have MetOcean specific metadata. This profile supports the listing of coverages, as well as a full geospatial/temporal footprint by use of the cis:Envelope element. The following example showcases this:

An example of a GetCapabilities request with MetOceanCoverageSummary:

<?xml version="1.0" encoding="UTF-8"?>
<wcs:GetCapabilities
xmlns:metocean="http://www.opengis.net/wcs/metoceanProfile/1.0"
xmlns:cis="http://www.opengis.net/cis/1.1/gml"
xmlns:wcs="http://www.opengis.net/wcs/2.0"
xmlns:ows="http://www.opengis.net/ows/2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/wcs/2.0 http://schemas.opengis.net/wcs/2.0/wcsAll.xsd http://www.opengis.net/wcs/metoceanProfile/1.0 http://schemas.opengis.net/wcs/metoceanProfile/1.0/wcsMetOceanGetCapabilitiesExtension.xsd" service="WCS">
<ows:AcceptVersions>
<ows:Version>2.1.0</ows:Version>
</ows:AcceptVersions>
<ows:Sections>
<ows:Section>OperationsMetadata</ows:Section>
<ows:Section>MetOceanCoverageSummary</ows:Section>
</ows:Sections>
</wcs:GetCapabilities>

The response fragment:

<metocean:CoverageSummary>
<wcs:CoverageId>BestData_AGL</wcs:CoverageId>
<cis:Envelope srsName="http://www.opengis.net/def/crs-compound?
1=http://www.opengis.net/def/crs/EPSG/0/4326;
2=http://http://www.opengis.net/def/crs/OGC/0/Time"
axisLabels="Lat Lon Time" srsDimension="3">
<cis:AxisExtent axisLabel="Lat" uomLabel="deg" lowerBound="-90" upperBound="90" />
<cis:AxisExtent axisLabel="Lon" uomLabel="deg" lowerBound="-180" upperBound="180" />
<cis:AxisExtent axisLabel="Time" uomLabel="ISO8601" lowerBound="2015-05-15T00.00.00Z"
upperBound="2015-05-20T00.00.00Z" />
</cis:Envelope>
</metocean:CoverageSummary>

A full example is given in the appendix.

9.5.2.  wcs:Extension

Even though this is not part of the MetOcean profile it is used to show the relationship between this extension point and the MetOcean specific metadata.

Table 18 — WCS::Extension properties

9.5.3.  metocean:GetCapabiltiesExtension

The GetCapabiltiesExtension is a high level object that forms the core part of the MetOcean GetCapabilities response.

Table 19 — METOCEAN::GetCapabiltiesMetOceanExtension properties

9.5.4.  metocean:CoverageSummary

The metadata required to describe a listed coverage.

Table 20 — METOCEAN::CoverageSummary properties

9.5.5.  metocean:AdditionalMetadata

Additional Metadata properties about the coverage.

Table 21 — METOCEAN::AdditionalMetadata properties

Table 22 — Values for OWS::Constraint elements

9.6.1.  Requirements class overview

The GetCapabilities-coverageCollectionSummary requirements class supports the listing of CoverageCollection identifiers that have MetOcean specific metadata. The CoverageCollection is an important construct within the MetOcean community as it describes the assembly of the output from a computer simulation that by nature uses a number of vertical CRS’s, but a common horizontal/temporal domain.

9.6.2.  CoverageCollectionSummary

The metadata required to describe a listed coverage collection.

Table 23 — METOCEAN::GetCapabiltiesMetOceanExtension properties

Table 24 — COVCOLL::CoverageCollectionSummary properties

An example of a GetCapabilities request with MetoceanCoverageCollectionSummary:

<?xml version="1.0" encoding="UTF-8"?>
<wcs:GetCapabilities
xmlns:ows="http://www.opengis.net/ows/2.0"
xmlns:wcs="http://www.opengis.net/wcs/2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/wcs/2.0 http://schemas.opengis.net/wcs/2.0/wcsAll.xsd http://www.opengis.net/wcs/metoceanProfile/1.0 http://schemas.opengis.net/wcs/metoceanProfile/1.0/wcsMetOceanGetCapabilitiesExtension.xsd" service="WCS">
<ows:AcceptVersions>
<ows:Version>2.1.0</ows:Version>
</ows:AcceptVersions>
<ows:Sections>
<ows:Section>OperationsMetadata</ows:Section>
<ows:Section>MetoceanCoverageCollectionSummary</ows:Section>
</ows:Sections>
</wcs:GetCapabilities>

An example of a response fragment:-

<wcs:Contents>
<wcs:Extension>
<metocean:CoverageCollectionMetadata>
<metocean:coverageCollectionSummary>
<metocean:CoverageCollectionSummary>
<metocean:coverageCollectionId>UK_Global_Climate_HistoricCO2</metocean:coverageCollectionId>
<cis:Envelope srsName="http://www.opengis.net/def/crs-compound?
1=http://www.opengis.net/def/crs/EPSG/0/4326;
2=http://http://www.opengis.net/def/crs/OGC/0/Time"
axisLabels="Lat Lon Time" srsDimension="3">
<cis:AxisExtent axisLabel="Lat" uomLabel="deg" lowerBound="-90" upperBound="90" />
<cis:AxisExtent axisLabel="Lon" uomLabel="deg" lowerBound="-180" upperBound="180" />
<cis:AxisExtent axisLabel="Time" uomLabel="ISO8601" lowerBound="2015-05-15T00.00.00Z" upperBound="2015-05-20T00.00.00Z" />
</cis:Envelope>
</metocean:CoverageCollectionSummary>
<metocean:CoverageCollectionSummary>
<metocean:coverageCollectionId>UK_Global_Climate_DoubleCO2</metocean:coverageCollectionId>
<cis:Envelope srsName="http://www.opengis.net/def/crs-compound?
1=http://www.opengis.net/def/crs/EPSG/0/4326;
2=http://http://www.opengis.net/def/crs/OGC/0/Time"
axisLabels="Lat Lon Time" srsDimension="3">
<cis:AxisExtent axisLabel="Lat" uomLabel="deg" lowerBound="-90" upperBound="90" />
<cis:AxisExtent axisLabel="Lon" uomLabel="deg" lowerBound="-180" upperBound="180" />
<cis:AxisExtent axisLabel="Time" uomLabel="ISO8601" lowerBound="2015-05-15T00.00.00Z" upperBound="2015-05-20T00.00.00Z" />
</cis:Envelope>
</metocean:CoverageCollectionSummary>
</metocean:coverageCollectionSummary>
</metocean:CoverageCollectionMetadata>
</wcs:Extension>
</wcs:Contents>

A full example is given at the end of the document

9.7.1.  Requirements class overview

The GetCapabilities-Groups class structures the GetCapabilities file to provide a hierarchical way of nesting “services”. Even though this requirements class is part of the MetOcean profile it is not restricted to MetOcean and any service may be referenced as long as it has the concept of coverageCollections.

The GetCapabilities-groups requirements class is dependent on the DescribeCoverageCollection operation being supported by the WCS server.

Table 25 — METOCEAN::GetCapabiltiesMetOceanExtension properties

9.7.2.  metocean:Group

Meteorological and oceanographic data is 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 (see Figure 4).

Table 26 — METOCEAN::Group properties

9.7.3.  metocean:SimulationCollection

The development and use of computer models for the study of actual or postulated dynamic systems is common in the field of environment science. It is commonplace to “run” simulations at regular intervals and it is convenient to group together these simulations and list each instance (or member) of that series with each member having a unique identifier.

Table 27 — METOCEAN::SimulationCollection properties

9.7.4.  metocean:SimulationMember

This simulation member identifier will point to a CoverageCollection resource that, for example, may be a NWP model run. The CoverageCollectionId will uniquely identify a collection of coverages.

Table 28 — METOCEAN::SimulationMember properties

An example of a GetCapabilities request with MetoceanGroups:

<?xml version="1.0" encoding="UTF-8"?>
<wcs:GetCapabilities
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:metocean="http://www.opengis.net/wcs/metoceanProfile/1.0"
xmlns:cis="http://www.opengis.net/cis/1.1/gml"
xmlns:wcs="http://www.opengis.net/wcs/2.0"
xmlns:ows="http://www.opengis.net/ows/2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/wcs/2.0 http://schemas.opengis.net/wcs/2.0/wcsAll.xsd http://www.opengis.net/wcs/metoceanProfile/1.0 http://schemas.opengis.net/wcs/metoceanProfile/1.0/wcsMetOceanGetCapabilitiesExtension.xsd" service="WCS">
<ows:AcceptVersions>
<ows:Version>2.1.0</ows:Version>
</ows:AcceptVersions>
<ows:Sections>
<ows:Section>OperationsMetadata</ows:Section>
<ows:Section>MetoceanGroups</ows:Section>
</ows:Sections>
</wcs:GetCapabilities>

An example of a response fragment:-

<metocean:group>
<metocean:Group>
<metocean:name>Atmospheric Models</metocean:name>
<metocean:Group>
<metocean:name>Global Models</metocean:name>
<metocean:Group>
<metocean:name>USA_GFS</metocean:name>
<metocean:serviceInstance>
<ows:DCP>
<ows:HTTP>
<ows:Get xlink:href="http://www.noaa/GFS_Forecast" xlink:type="simple"/>
<ows:Post xlink:href="http://www.noaa.org/GFS_Forecast" xlink:type="simple">
<ows:Constraint name="PostEncoding">
<ows:AllowedValues>
<ows:Value>XML</ows:Value>
</ows:AllowedValues>
</ows:Constraint>
</ows:Post>
</ows:HTTP>
</ows:DCP>
</metocean:serviceInstance>
<metocean:coverageCollectionSummary>
<metocean:CoverageCollectionSummary>
<metocean:coverageCollectionId>GFS_Global_2017-04-26T00.00.00Z</metocean:coverageCollectionId>
</metocean:CoverageCollectionSummary>
<metocean:CoverageCollectionSummary>
<metocean:coverageCollectionId>GFS_Global_2017-04-26T12.00.00Z</metocean:coverageCollectionId>
</metocean:CoverageCollectionSummary>
</metocean:coverageCollectionSummary>
</metocean:Group>
</metocean:Group>
</metocean:Group>
</metocean:group>

There is a full example at the end of the document

9.8.1.  Requirements class overview

A DescribeCoverageCollection request submits a list of identifiers for CoverageCollection resources and returns, for each identified CoverageCollection resource, a description of the CoverageCollection. The description of a CoverageCollection resource in a DescribeCoverageCollection response includes:

• An identifier for the CoverageCollection resource,

• Summary information about coverages which comprise this CoverageCollection resource (if any),

• Information about the boundary spatial (or spatiotemporal) extent of the CoverageCollection,

• Other metadata or extension information.

9.8.2.  DescribeCoverageCollection request

The DescribeCoverageCollection request structure is derived from RequestBase, extended with a non-empty list of CoverageCollection identifiers. This structure is shown in Figure 14 and Table 29.

Figure 14 — DescribeCoverageCollection request UML class diagram

(shaded components originate from OWS Common)

Table 29 — COVCOLL::DescribeCoverageCollection request components

The following XML excerpt shows an example of a DescribeCoverageCollectionRequest:

<?xml version="1.0" encoding="UTF-8"?>
<covcoll:DescribeCoverageCollection
xmlns:covcoll="http://www.opengis.net/wcs/metoceanProfile/1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:cis="http://www.opengis.net/cis/1.1"
service="WCS" version="2.1.0" count="100"
xsi:schemaLocation="http://www.opengis.net/wcs/metoceanProfile/1.0 http://schemas.opengis.net/wcs/metoceanProfile/1.0/wcsMetOceanCoverageCollection.xsd">
<covcoll:coverageCollectionId>someCoverageCollectionId</covcoll:coverageCollectionId>
</covcoll:DescribeCoverageCollection>

The response fragment:

<metocean:CoverageCollectionDescriptions
xmlns:wcs="http://www.opengis.net/wcs/2.0"
xmlns:cis="http://www.opengis.net/cis/1.1/gml"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:ows="http://www.opengis.net/ows/2.0"
xmlns:wcs21="http://www.opengis.net/wcs/2.1/gml"
xmlns:wcs20="http://www.opengis.net/wcs/2.0"
xmlns:cis11="http://www.opengis.net/cis/1.1/gml"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:metocean="http://www.opengis.net/wcs/metoceanProfile/1.0"
xsi:schemaLocation="http://www.opengis.net/wcs/metoceanProfile/1.0 http://schemas.opengis.net/wcs/metoceanProfile/1.0/wcsMetOceanProfileALL.xsd">
<metocean:CoverageCollectionDescription>
<metocean:coverageCollectionId>GFS_Global_2016-10-12T00.00.00Z</metocean:coverageCollectionId>
<ows:Metadata xlink:href="www.codes.wmo.int/GRIB2/codeflag/0.0/_0/Meteorological Products">
<metocean:collectionDescription collectionName="Generic NWP Model Run">
<cis:Envelope srsName="http://www.opengis.net/def/crs-compound?
1=http://www.opengis.net/def/crs/EPSG/0/4326;
2=http://http://www.opengis.net/def/crs/OGC/0/AnsiDate"
axisLabels="Lat Lon Time " srsDimension="3">
<cis:AxisExtent axisLabel="Lat" uomLabel="deg" lowerBound="-90" upperBound="90" />
<cis:AxisExtent axisLabel="Lon" uomLabel="deg" lowerBound="-180" upperBound="180" />
<cis:AxisExtent axisLabel="Time" uomLabel="ISO8601" lowerBound="2016-10-12T00.00.00Z" upperBound="2015-05-17T00:00:00Z" />
</cis:Envelope>
</metocean:collectionDescription>
</ows:Metadata>
<metocean:coverageSummary>
<wcs:CoverageSummary>
<wcs:CoverageId>GFS_Global_2016-10-12T00.00.00Z_ISBL</wcs:CoverageId>
<wcs:CoverageSubtype>VerticalDependency</wcs:CoverageSubtype>
<ows:Metadata xlink:href="www.codes.wmo.int/GRIB2/table4.5/IsobaricSurface">
<metocean:coverageDescription coverageName="Isobaric Surface">
<metocean:referenceTime>
<gml:timePosition>2015-05-15T00.00.00Z</gml:timePosition>
</metocean:referenceTime>
<cis:Envelope srsName="http://www.opengis.net/def/crs-compound?
1=http://www.opengis.net/def/crs/EPSG/0/4326;
2=http://http://www.opengis.net/def/crs/OGC/0/AnsiDate&amp;
3=http://www.codes.wmo.int/GRIB2/table4.5/IsobaricSurface"
axisLabels="Lat Lon Time Pressure" srsDimension="4">
<cis:AxisExtent axisLabel="Lat" uomLabel="deg" lowerBound="-90" upperBound="90" />
<cis:AxisExtent axisLabel="Lon" uomLabel="deg" lowerBound="-180" upperBound="180" />
<cis:AxisExtent axisLabel="Time" uomLabel="ISO8601" lowerBound="2016-10-12T00.00.00Z" upperBound="2015-05-17T00:00:00Z" />
<cis:AxisExtent axisLabel="Pressure" uomLabel="hPa" lowerBound="1000.0" upperBound="200.0" />
</cis:Envelope>
</metocean:coverageDescription>
</ows:Metadata>
</wcs:CoverageSummary>
<wcs:CoverageSummary>
<wcs:CoverageId>GFS_Global_2016-10-12T00.00.00Z_Max_Wind</wcs:CoverageId>
<wcs:CoverageSubtype>ComputedSurface</wcs:CoverageSubtype>
<ows:Metadata xlink:href="www.codes.wmo.int/GRIB2/table4.5/MaximumWindLevel">
<metocean:coverageDescription coverageName="Maximum Wind Level">
<metocean:referenceTime>
<gml:timePosition>2015-05-15T00.00.00Z</gml:timePosition>
</metocean:referenceTime>
<cis:Envelope srsName="http://www.opengis.net/def/crs-compound?
1=http://www.opengis.net/def/crs/EPSG/0/4326;
2=http://http://www.opengis.net/def/crs/OGC/0/AnsiDate"
axisLabels="Lat Lon Time" srsDimension="4">
<cis:AxisExtent axisLabel="Lat" uomLabel="deg" lowerBound="-90" upperBound="90" />
<cis:AxisExtent axisLabel="Lon" uomLabel="deg" lowerBound="-180" upperBound="180" />
<cis:AxisExtent axisLabel="Time" uomLabel="ISO8601" lowerBound="2016-10-12T00.00.00Z" upperBound="2015-05-17T00:00:00Z" />
<cis:AxisExtent axisLabel="Max_Wind" uomLabel="NA" lowerBound="1" upperBound="1"/>
</cis:Envelope>
</metocean:coverageDescription>
</ows:Metadata>
</wcs:CoverageSummary>
</metocean:coverageSummary>
</metocean:CoverageCollectionDescription>
</metocean:CoverageCollectionDescriptions>

9.8.3.  COVCOLL::DescribeCoverageCollection response

The response to a successful DescribeCoveragecollection request contains a list of coverage metadata, one for each Coveragecollection identifier passed in the request. This structure is shown in Figure 15 and Table 30, Table 31, Table 32, Table 33, Table 34, and Table 35.

Table 30 — Exception codes for DescribeCoverage operation

Figure 15 — CoverageCollectionDescription UML class diagram

Figure 15 illustrates how CoverageCollectionSummary elements are structured. New classes are highlighted in blue.

Table 31 — COVCOLL::CoverageCollectionDescription components

(shaded components originate from OWS Common)

Table 32 — WCS::CoverageSummary additional components

Table 33 — COVCOLL::CoverageDescription

9.8.4.  CoverageCollectionSummary

The metadata required to describe a listed coverage collection.

Table 34 — COVCOLL::CoverageCollectionSummary properties

Table 35 — Coverage Sub-Type definition

9.10.1.  DescribeCoverageCollection HTTP/GET using KVP request structure

The DescribeCoverageCollection request for HTTP/GET using KVP is defined below.

Table 36 — COVCOLL::DescribeCoverageCollection request URL encoding

The following KVP-encoded DescribeCoverageCollection example request addresses the service path on server www.service.org at port 8080, and retrieves all Coverages that are contained within the CoverageCollection with an identifier of UKPP4-201-10-15-12Z:

http://www:server.org:port/8080?
service=WCS&version=2.1.0
&request=DescribeCoverageCollection
&count=100
&coverageCollectionId=UKPP4-2016-10-15-12Z

9.13.1.  Requirements class overview

The additional metadata uses the cis:Extension hook to link, via the CoverageMetadata entity, to the MetOceanObservation. The DescribeCoverage response encodes the MetOceanObservation to provide metadata that is based on the WMO (World Meteorological Organisation) GRIB2 coding. The MetOceanObservation is specialised by community specific types, e.g. NWPObservation, SimulatedObservation, and others yet to be defined.

9.13.2.  cis:Extension

The extension point that links MetOcean specific metadata to the DescribeCoverage response:

Table 37 — CIS::Extension properties

9.13.3.  MetOceanCoverageMetadata

A MetOceanObservation is a more specialised Observation (as defined by O&M) that adds specific metadata and is used by MetOceanCoverageDescription:

Table 38 — METOCEAN::CoverageMetadata properties

An example of a DescribeCoverage Request

<?xml version="1.0" encoding="UTF-8"?>
<DescribeCoverage xmlns="http://www.opengis.net/wcs/2.1/gml"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wcs="http://www.opengis.net/wcs/2.1/gml"
xmlns:wcs20="http://www.opengis.net/wcs/2.0"
xmlns:metocean="http://www.opengis.net/wcs/metoceanProfile/1.0"
xsi:schemaLocation="http://www.opengis.net/wcs/2.1/gml http://schemas.opengis.net/wcs/2.1/gml/wcsDescribeCoverage.xsd http://www.opengis.net/wcs/2.1/gml http://schemas.opengis.net/wcs/2.1/gml/wcsAll.xsd"
service="WCS" version="2.1.0">
<wcs20:Extension>
<metocean:sections>
<metocean:Section>metocean_ResultMask</metocean:Section>
<metocean:Section>metocean_DescribeCoverageProfile</metocean:Section>
</metocean:sections>
</wcs20:Extension>
<wcs20:CoverageId>GlobEGRR_2015-10-15T00.00.00Z_ISBL</wcs20:CoverageId>
</DescribeCoverage>