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 term “reference time” will used in preference to “model run time”, as it is more generic and includes services that may be continually updated.

7.3.1.  4D Coverages

A typical NWP forecast may typically be expressed as a set of 2D coverages, but these are not always based on rectified grids. Also, a typical model run contains thousands of 2D coverages and the metadata returned by the GetCapabilites response quickly becomes unmanageable. The problem can be simplified by identifying, wherever possible, “4D Coverages”. This was made much easier with the adoption of the OGC’s CIS 1.1.

In addition, a typical numerical simulation has a number of different vertical coordinates F(i.e. pressure, height above mean sea level, height above ground, surface, max wind level). By forming a 4D coverage from all of the 2D coverages that share the same horizontal, vertical and temporal domains, the number of coverage identifiers can be significantly reduced, thus reducing complexity. This is a challenge, as the vertical and temporal axes are not regular and need to be enumerated. Fortunately, the “GeneralGridCoverage” as described CIS makes this possible with the use of the IrregularAxis component (see figure 2).

This key concept therefore changes the traditional view of data as being a set of 2D fields each with a level, level type, parameter name and forecast period. We can now describe the whole atmosphere as multidimensional cube with properties, e.g. temperature, wind and humidity. It is therefore possible to make geospatial queries. For WCS2.1, this equates to the GetCoverage operation and the proposed new operation GetCorridor. There are special cases where the vertical axis has no vertical dependency (e.g. surface, max wind level), and are described with a simple name. The properties of each coverage are given common names such as temperature, humidity etc. It will be common for some coverages to have these parameters, or properties, in common.

7.5.1.  Scenario 1: Specifying the path

In scenario 1, the path will be defined within the GetCorridor request as a specialized element metocean:PathDescription, this is a specialised type of a cis:GeneralGridType. This example is based on Figure 3, although the detail is not exact!

<metoceancorridor:path
xmlns:wcs="http://www.opengis.net/wcs/2.0"
 xmlns:metoceancorridor="http://www.opengis.net/wcs/metoceanProfile_getCorridor/1.0"
 xmlns:gml="http://www.opengis.net/gml/3.2"
 xmlns:cis="http://www.opengis.net/cis/1.1/gml"
 xmlns:rsub="http://www.opengis.net/wcs/range-subsetting/1.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<metoceancorridor:PathDescription srsName="http://www.opengis.net/def/crs-compound?
1=http://www.opengis.net/def/crs/EPSG/0/4326&amp;
2=http://http://www.opengis.net/def/crs/OGC/0/AnsiDate&amp;
3= http://codes.wmo.int/grib2/codeflag/4.5/_102/Specific_altitude_above_mean_sea_level"
axisLabels="Lat Lon Time Specific_altitude_above_mean_sea_level">
<cis:DisplacementAxisNest axisLabels="Lat Lon Time Specific_altitude_above_mean_sea_level" uomLabels="deg deg ISO8601 ft">
<cis:P><cis:C>45.0</cis:C><cis:C>5.0</cis:C><cis:C>2017-05-15T00:00:00Z</cis:C><cis:C>3600</cis:C></cis:P>
<cis:P><cis:C>46.0</cis:C><cis:C>0.0</cis:C><cis:C>2017-05-15T00:15:00Z</cis:C><cis:C>3500</cis:C></cis:P>
<cis:P><cis:C>47.0</cis:C><cis:C>-5.0</cis:C><cis:C>2017-05-15T00:30:00Z</cis:C><cis:C>34200</cis:C></cis:P>
<cis:P><cis:C>48.0</cis:C><cis:C>-10.0</cis:C><cis:C>2017-05-15T00:45:00Z</cis:C><cis:C>3400</cis:C></cis:P>
<cis:P><cis:C>49.0</cis:C><cis:C>-15.0</cis:C><cis:C>2017-05-15T01:00:00Z</cis:C><cis:C>3200</cis:C></cis:P>
<cis:P><cis:C>51.0</cis:C><cis:C>-20.0</cis:C><cis:C>2017-05-15T01:15:00Z</cis:C><cis:C>3000</cis:C></cis:P>
<cis:P><cis:C>52.0</cis:C><cis:C>-25.0</cis:C><cis:C>2017-05-15T01:30:00Z</cis:C><cis:C>2000</cis:C></cis:P>
</cis:DisplacementAxisNest>
<cis:GridLimits srsName="http://www.opengis.net/def/crs/OGC/0/Index1D" axisLabels="i">
<cis:IndexAxis axisLabel="i" lowerBound="0" upperBound="6"/>
</cis:GridLimits>
</metoceancorridor:PathDescription>
</metoceancorridor:path>

7.5.2.  Scenario 2: Breaking the path into segments

In scenario 2, the trajectory may, if required, be broken up into segments, therefore creating extra “sample points”. If a time dimension is defined, then a choice can be made for having segments equal in time or distance. Breaking up the path into segments, either by time or distance, must be specified in the GetCorridor request in the scal:TargetAxisSize element as part of the scaling specification. For a trajectory broken up into equal time segments, the distances will be equal only between “way points” , as a constant speed is assumed.

Figure 4 represents a typical trajectory with just the ‘way points’.

Figure 4 — way points

Note each yellow marker represents a “way point” in time and space. Essentially the 4D trajectory is transformed into a 3D feature.

7.5.3.  Scenario 3: Breaking the path into segments of equal distance

In this scenario, the trajectory is broken up into 16 segments (see Figure 5) equal in distance (i.e. 62.5 miles). For the first and last phases, this equates to 15 minute intervals. For the second phase, the time interval is 7.5 mins i.e. twice the first and last phases. Note that the segment points and the wave points overlap, but this is not always the case.

Figure 5 — Segments equal in distance

7.5.4.  Scenario 4: Breaking the path into segments of equal time

Figure 6 shows a trajectory broken up into 16 segments equal in time (i.e. 11.25 minutes). For the first five segments, the speed is assumed to be 250 mph. For the next 6 segments, the average speed is assumed to be 500 mph. Note that the segment points and the “way points” do not overlap for each point. This may not be what is really required and it would be better to break up each “phase” into a discrete number of segments.

Figure 6 — Segments equal in Time

7.5.5.  Scenario 5: Segments equal in distance for each “phase” broken into a discrete segments.

Figure 7 shows a trajectory broken up into 13 segments. For phases 1 and 3, this equates to a distance of 62.5 miles. For the middle phase, the distance between segments is 100 miles. For the first and last phases, this equates to 15 minute intervals. For the second phase, the time interval is 12 mins. Note that the segment points and the “way points” will always coincide.

Figure 7 — Discrete Segments equal in distance

7.5.6.  Scenario 6: Segments equal in time for each “phase” broken into a discrete segments,

Figure 8 shows a trajectory broken into an integral number of segments for each phase. For phase 1, this equates to 15 minute intervals or 62.5 miles. For the middle phase, the distance between segments is 33.3 minutes or 166.67 miles. For last phases, this equates to 30 minute intervals or 125 miles. Note that the segment points and the “way points” will always coincide.

Figure 8 — Discrete Segments equal in time

7.5.7.  Scenario 7: Describing the corridor:

Corridor vertical aligned with the local vertical coordinate

The depiction of the corridor seen in Figure 9 shows the trajectory, shown in red, based on the “way points”, shown in yellow. The corridor, shown in blue, is based on a simple grid that is orthogonal to the trajectory. An alternative view is shown in Figure 10. Note the vertical orientation of the corridor is aligned with the vertical coordinate.

Figure 9 — Corridor aligned with trajectory axis

Figure 10 — Alternative view of the corridor aligned with trajectory axis

7.5.8.  Corridor vertically aligned perpendicular to the trajectory.

In this example the vertical alignment of the corridor may be required to be perpendicular to the flight path. This is particularly important where the trajectory is very steep (see Figure 11)

Figure 11 — Corridor vertical aligned perpendicular to the trajectory

7.6.1.  Method: 1 Trajectory Intersection using Voxel semantics

With reference to Figure 12, the path is defined by a set of “way points” (shown in green). The coverage returned in response to a successful GetCorridor request would have as its “domain set” the center points of the “grid boxes” intersected by the trajectory. The “result set” is made up of direct points from the MetOcean coverage (in red) extracted from each grid box that the path intersects).

Figure 12 — Extraction of the trajectory using grid-box semantics

An alternative view:

In Figure 12 there is an alternative depiction. Note that there may not be a continuous set of Voxels intercepted.

Figure 13 — A ‘Voxel’ view of the trajectory

7.6.2.  Method 2: (Corridor with “Voxel” semantics)

In method 2 the path is defined by a set of “way points” with a horizontal buffer region around the path. The coverage returned in response to a successful GetCorridor request would have as its “domain set“ the points contained within the buffer using “grid-box -in-centre” semantics. The “result set” is made up of direct points from the MetOcean coverage (in red) extracted from each grid box within the boundary box (see Figure 14). No horizontal interpolation is performed.

Figure 14 — Extraction of the corridor using grid-box semantics

Figure 15 — A “Voxel” view of the corridor

Figure 15 is an attempt to show how a corridor with “Voxels” would look like in 3D.

7.6.3.  Method 3: (Corridor point collection)

In this method all the grid points contained within the corridor form a collection. The path is defined by a set of “way points” (in green) with a horizontal buffer region around the path (defined by a “horizontal buffer extent”). The coverage returned in response to a successful GetCorridor request would have as its “domain set” all the points that lie within the corridor (the points are in red) The “result set” is made up of direct points from the MetOcean coverage (in red) extracted from each point that lies within the boundary box (see Figure 16).

Figure 16 — Extraction of a corridor, using point based semantics

Note that this is different from the first two examples as it based on “grid point” semantics, not “grid-box” semantics.

Figure 17 — Extraction of a corridor, using point based semantics

7.6.4.  Method: 4 (Trajectory with point based semantics)

In method 4 the path is defined by a set of “way points” (in red) that are un-equally spaced. The coverage returned in response to a successful GetCorridor request would have as its “domain set” the way points that lie along the trajectory (the points in red). The “result set” is calculated by interpolating horizontally and if required, temporally from the MetOcean coverage (see Figure 18)

Figure 18 — Trajectory with point based semantics

If there a different time for each way point then the data will be interpolated to the correct time for each point given the coverage has a time dimension. Thus each returned data point would have a different time.

Figure 19 — Trajectory with point based semantics

7.6.5.  Method: 5 (Corridor grid with vertical aligned with grid)

In method 5 the path, denoted in the diagram by blue stars is shown in figure 5. The coverage returned in response to a successful GetCorridor request would have as its “domain set” each sample point (the points are shown in red). The “result set” is calculated by interpolating from the MetOcean coverage to each of the sampling points (see Figure 20). Note that the orientation of the vertical axis and its relationship to the path. Compare this with the next metghod.

Figure 20 — Corridor grid with vertical aligned with grid

The following Figure 21 shows an alternative view of Figure 20.

Figure 21 — Corridor grid with vertical aligned with grid

7.6.6.  Method 6 (Corridor grid perpendicular to the trajectory)

In method 6 the path is defined by a set of “way points” that are un-equally spaced, with a horizontal buffer region around the path (defined by a “horizontal buffer Extent”). The coverage returned in response to a successful GetCorridor request would have as its “domain set” each sample point (the points are shown in red). The difference in this example is the orientation of the points relative to the path, i.e. perpendicular to the path. The “result set” is calculated by interpolating from the MetOcean coverage to each of the sampling points (see Figure 22 and Figure 23).

Figure 22 — Corridor grid perpendicular to the trajectory

Figure 23 — Corridor grid perpendicular to the trajectory

This figure illustrates the orientation of the corridor axis relative to the path, i.e. it is perpendicular.

7.6.7.  Encoding the trajectory

Encoding of the trajectory using the CIS1.1 coverage model is quite straight forward and some examples have been included with this document. The alternative encodings, e.g. covJson are more limited, but will work for simple trajectories. Binary encoding e.g. NetCDF have been done, but until recently there was no standard way of organising the data. The latest CF standard for sampling may address the issue. The alternative encoding i.e. GRIB2 is not straightforward at all and not easy to interpret.

8.1.1.  Requirements class overview

The Get_Corridor requirements class defines the structure of the GetCorridor operation.

8.1.2.  Metoceancorridor::GetCorridor

The new operation GetCorridor allows for the extraction of a trajectory/corridor and has a number of options that have been described in section 7. The extra conformance classes ae used to further define the possible options outlined here in the getCorridor conformance class. The GetCorridor service is derived from wcs:GetCoverage and inherits the version and service elements.

Table 2 — METOCEANCORRIDOR::GetCorridor properties

8.1.3.  rsub::RangeSubset

Table 3 — RSUB::RangeSubset properties

8.1.4.  rsub::RangeSubset

Table 4 — RSUB::RangeItem properties

8.2.1.  Requirements class overview

This clause establishes the PathDescription conformance. Clients and servers supporting the requirements class support the extraction of a trajectory/corridor from a multidimensional data cube. This PathDescription is mandatory.

Figure 25 — CorridorPath UML class diagram

8.2.2.  PathDescription Properties

The path description is derived from CIS:GeneralGrid and is extended to include information regarding segmentation. Note that only those elements used by this conformance class are included.

Table 5 — METOCEANCORRIDOR::PathDescription properties

8.2.3.  SegmentDefinition Properties

The path (aka trajectory) may divided into segments (see Figure 4, Figure 5, Figure 6, Figure 7 and Figure 8. The description is given in section 7.5.

Table 6 — METOCEANCORRIDOR::SegmentDefinition properties

Table 7 — METOCEANCORRIDOR::cis:V properties

8.2.4.  DiscretisationMethodValue Properties

The path may be divided up into segments using one of two methods. The first by distance, the second method is similar, but the division is done equally in time.

Table 8 — METOCEANCORRIDOR::DiscretisationMethodValue Properties

8.2.5.  DisplacementAxisNest Properties

The CIS::DisplacementAxisNest combines several axes to a single “nest” where the coordinates are enumerated individually for each direct position (Note this come from CIS1.1).

Table 9 — CIS::DisplacementAxisNest

8.2.6.  GridLimits Properties

The limits of the underlying array are given by the CIS::gridLimits component (Note this come from CIS1.1)

Table 10 — CIS::GridLimits

8.2.7.  An example of a Path encoding

<metoceancorridor:path
xmlns:wcs="http://www.opengis.net/wcs/2.0"
 xmlns:metoceancorridor="http://www.opengis.net/wcs/metoceanProfile_getCorridor/1.0"
 xmlns:gml="http://www.opengis.net/gml/3.2"
 xmlns:scal="http://www.opengis.net/WCS_service-extension_scaling/1.0"
 xmlns:int="http://www.opengis.net/WCS_service-extension_interpolation/1.0"
 xmlns:cis="http://www.opengis.net/cis/1.1/gml"
 xmlns:rsub="http://www.opengis.net/wcs/range-subsetting/1.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<metoceancorridor:PathDescription srsName="http://www.opengis.net/def/crs-compound?
1=http://www.opengis.net/def/crs/EPSG/0/4326&amp;
2=http://http://www.opengis.net/def/crs/OGC/0/AnsiDate&amp;
3= http://codes.wmo.int/grib2/codeflag/4.5/_102/Specific_altitude_above_mean_sea_level"
axisLabels="Lat Lon Time Specific_altitude_above_mean_sea_level">
<cis:DisplacementAxisNest axisLabels="Lat Lon Time Specific_altitude_above_mean_sea_level" uomLabels="deg deg ISO8601 ft">
<cis:P><cis:C>45.0</cis:C><cis:C>5.0</cis:C><cis:C>2015-05-15T00:00:00Z</cis:C><cis:C>3600</cis:C></cis:P>
<cis:P><cis:C>46.0</cis:C><cis:C>0.0</cis:C><cis:C>2015-05-15T00:15:00Z</cis:C><cis:C>3500</cis:C></cis:P>
<cis:P><cis:C>47.0</cis:C><cis:C>-5.0</cis:C><cis:C>2015-05-15T00:30:00Z</cis:C><cis:C>34200</cis:C></cis:P>
<cis:P><cis:C>48.0</cis:C><cis:C>-10.0</cis:C><cis:C>2015-05-15T00:45:00Z</cis:C><cis:C>3400</cis:C></cis:P>
<cis:P><cis:C>49.0</cis:C><cis:C>-15.0</cis:C><cis:C>2015-05-15T01:00:00Z</cis:C><cis:C>3200</cis:C></cis:P>
<cis:P><cis:C>51.0</cis:C><cis:C>-20.0</cis:C><cis:C>2015-05-15T01:15:00Z</cis:C><cis:C>3000</cis:C></cis:P>
<cis:P><cis:C>52.0</cis:C><cis:C>-25.0</cis:C><cis:C>2015-05-15T01:30:00Z</cis:C><cis:C>2000</cis:C></cis:P>
</cis:DisplacementAxisNest>
<cis:GridLimits srsName="http://www.opengis.net/def/crs/OGC/0/Index1D" axisLabels="i">
<cis:IndexAxis axisLabel="i" lowerBound="0" upperBound="6"/>
</cis:GridLimits>

<metoceancorridor:SegmentDefinition>
<metoceancorridor:discretisationMethod>DISTANCE</metoceancorridor:discretisationMethod>
<metoceancorridor:segmentsPerSector>
<cis:V>3</cis:V>
<cis:V>5</cis:V>
<cis:V>4</cis:V>
<cis:V>6</cis:V>
<cis:V>4</cis:V>
<cis:V>5</cis:V>
</metoceancorridor:segmentsPerSector>
</metoceancorridor:SegmentDefinition>
</metoceancorridor:PathDescription>
</metoceancorridor:path>

8.3.1.  Requirements class overview

In this document a trajectory with a lateral and (Optional) vertical extent is known as a corridor. The CorridorExtent Properties define the corridor axes and therefore dimensionality. The corridor axis known as “Corridor_Width” is always in the horizontal whereas the “Corridor_Height” axis may either be perpendicular to the trajectory or aligned with the metocean cube vertical axis (see Figure 10 and Figure 11). The size of the corridor is specified by the AxisExtent element, see below for some examples.

8.3.2.  Examples of CorridorExtent

Example 1

In this example the corridor has two dimensions; the width is 10 Kilometres wide and the height is 20 Kilometres both dimensions are specified relative to the trajectory. Note that the vertical coordinate system i.e. EPSG:5703 is the vertical coordinate system for Mexico and the States (USA).

<metoceancorridor:corridorExtent
xmlns:wcs="http://www.opengis.net/wcs/2.0"
 xmlns:metoceancorridor="http://www.opengis.net/wcs/metoceanProfile_getCorridor/1.0"
 xmlns:gml="http://www.opengis.net/gml/3.2"
 xmlns:scal="http://www.opengis.net/WCS_service-extension_scaling/1.0"
 xmlns:int="http://www.opengis.net/WCS_service-extension_interpolation/1.0"
 xmlns:cis="http://www.opengis.net/cis/1.1/gml"
 xmlns:rsub="http://www.opengis.net/wcs/range-subsetting/1.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<metoceancorridor:CorridorExtent srsName="http://www.opengis.net/def/crs-compound?
1= http://www.opengis.net/def/crs/EPSG/0/4326 &amp;
2=http://http://www.opengis.net/def/crs/ EPSG/0/5703"
axisLabels="Lat Lon Corridor" srsDimension="3">
<cis:AxisExtent axisLabel="Corridor_Width" uomLabel="km" lowerBound="-5.0" upperBound="5.0"/>
<cis:AxisExtent axisLabel="Corridor_Height" uomLabel="km" lowerBound="-10.0" upperBound="10.0"/>
<scal:Scaling xmlns:scal="http://www.opengis.net/WCS_service-extension_scaling/1.0">
<scal:ScaleToSize>
<scal:TargetAxisSize>
<scal:axis>Corridor_Width</scal:axis>
<scal:targetSize>5</scal:targetSize>
</scal:TargetAxisSize>
<scal:TargetAxisSize>
<scal:axis>Corridor_Height</scal:axis>
<scal:targetSize>5</scal:targetSize>
</scal:TargetAxisSize>
</scal:ScaleToSize>
</scal:Scaling>
</metoceancorridor:CorridorExtent>
</metoceancorridor:corridorExtent>

Example 2

In this example vertical reference system for “Corridor_Height” uses the GRIB2 definition for isobaric surfaces. The unit of measure in is Hectopascals.

<metoceancorridor:corridorExtent
 xmlns:wcs="http://www.opengis.net/wcs/2.0"
 xmlns:metoceancorridor="http://www.opengis.net/wcs/metoceanProfile_getCorridor/1.0"
 xmlns:gml="http://www.opengis.net/gml/3.2"
 xmlns:scal="http://www.opengis.net/WCS_service-extension_scaling/1.0"
 xmlns:int="http://www.opengis.net/WCS_service-extension_interpolation/1.0"
 xmlns:cis="http://www.opengis.net/cis/1.1/gml"
 xmlns:rsub="http://www.opengis.net/wcs/range-subsetting/1.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<metoceancorridor:CorridorExtent srsName="http://www.opengis.net/def/crs-compound?
1= http://www.opengis.net/def/crs/EPSG/0/4326 &amp;
2=http://www.codes.wmo.int/GRIB2/table4.5/IsobaricSurface"
axisLabels=" Corridor_Width Corridor_Height " srsDimension="2">
<cis:AxisExtent axisLabel="Corridor_Width" uomLabel="m" lowerBound="-5.0" upperBound="5.0"/>
<cis:AxisExtent axisLabel="Corridor_Height" uomLabel="hPa" lowerBound="-1000.0" upperBound="1000.0"/>
<scal:Scaling>
<scal:ScaleToSize>
<scal:TargetAxisSize>
<scal:axis>Corridor_Width</scal:axis>
<scal:targetSize>5</scal:targetSize>
</scal:TargetAxisSize>
<scal:TargetAxisSize>
<scal:axis>Corridor_Height</scal:axis>
<scal:targetSize>5</scal:targetSize>
</scal:TargetAxisSize>
</scal:ScaleToSize>
</scal:Scaling>
</metoceancorridor:CorridorExtent>
</metoceancorridor:corridorExtent>

Example 3

In this example vertical reference system for “Corridor_Height” uses the GRIB2 definition for pressure altitude WMO GRIB2 table4.2-0-3. The unit of measure in this example is metres.

<metoceancorridor:corridorExtent
 xmlns:wcs="http://www.opengis.net/wcs/2.0"
 xmlns:metoceancorridor="http://www.opengis.net/wcs/metoceanProfile_getCorridor/1.0"
 xmlns:gml="http://www.opengis.net/gml/3.2"
 xmlns:scal="http://www.opengis.net/WCS_service-extension_scaling/1.0"
 xmlns:int="http://www.opengis.net/WCS_service-extension_interpolation/1.0"
 xmlns:cis="http://www.opengis.net/cis/1.1/gml"
 xmlns:rsub="http://www.opengis.net/wcs/range-subsetting/1.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<metoceancorridor:CorridorExtent srsName="http://www.opengis.net/def/crs-compound?
1= http://www.opengis.net/def/crs/EPSG/0/4326 &amp;
2=http://www.codes.wmo.int/GRIB2/table4.2-0-3/Pressure Altitude"
axisLabels="Corridor_Width Corridor_Height" srsDimension="2">
<cis:AxisExtent axisLabel="Corridor_Width" uomLabel="m" lowerBound="-5.0" upperBound="5.0"/>
<cis:AxisExtent axisLabel="Corridor_Height" uomLabel="m" lowerBound="-300.0" upperBound="300.0"/>
<scal:Scaling>
<scal:ScaleToSize>
<scal:TargetAxisSize>
<scal:axis>Corridor_Width</scal:axis>
<scal:targetSize>5</scal:targetSize>
</scal:TargetAxisSize>
<scal:TargetAxisSize>
<scal:axis>Corridor_Height</scal:axis>
<scal:targetSize>5</scal:targetSize>
</scal:TargetAxisSize>
</scal:ScaleToSize>
</scal:Scaling>
</metoceancorridor:CorridorExtent>
</metoceancorridor:corridorExtent>

8.3.3.  CorridorExtent Properties

Table 11 — METOCEANCORRIDOR::CorridorExtent Properties

8.3.4.  Requirements class overview

The Axis Extent comes from the Coverage Implementation Schema (CIS).

Table 12 — CIS::AxisExtent Properties

8.3.5.  Requirements class overview

The number of points defined in the corridor axes is set by using the scal:ScaleByFactor, element value.

Table 13 — SCAL::Scaling

8.3.6.  Requirements class overview

The number of points defined in the corridor axes is set by the scal:targetSize.

Table 14 — SCAL::ScaleToSize Properties

8.4.1.  Requirements class overview

The CorridorExtractionMethod requirements class defines the structure of the CorridorExtractionMethod.

8.4.2.  CorridorExtractionMethod Properties

These properties detail how the extraction of the data within the corridor is defined. The detailed description is given in section 7.

Table 15 — METOCEANCORRIDOR::CorridorExtractionMethod properties

8.4.3.  The CorridorExractionValue Properties

This table sets out the permitted values for the orientation of the corridor’s vertical axis with respect to the trajectory.

Table 16 — METOCEANCORRIDOR::CorridorOrientationValue Properties

8.4.4.  metoceancorridor::CorridorExractionMethodValue Properties

There are five GetCorridor extraction patterns and these are listed in Table 17. The requirements’ for each are listed separately.

Table 17 — METOCEANCORRIDOR::CorridorExractionMethodValue Properties

8.4.5.  int:Interpolation Properties

Any method that requires interpolation must set the following properties

Table 18 — INT::Interpolation Properties

8.4.6.  int:InterpolationPerAxis

Table 19 — INT::InterpolationPerAxis

<?xml version="1.0" encoding="UTF-8"?>
<metoceancorridor:GetCorridor xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:wcs="http://www.opengis.net/wcs/2.0"
xmlns:metocean="http://www.opengis.net/wcs/metoceanProfile/1.0"
xmlns:metoceancorridor="http://www.opengis.net/wcs/metoceanProfile_getCorridor/1.0"
xmlns:wcsCRS="http://www.opengis.net/wcs_service-extension_crs/1.0"
xmlns:scal="http://www.opengis.net/WCS_service-extension_scaling/1.0"
xmlns:int="http://www.opengis.net/WCS_service-extension_interpolation/1.0"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:cis="http://www.opengis.net/cis/1.1/gml"
xmlns:rsub="http://www.opengis.net/wcs/range-subsetting/1.0"
xmlns:gmlrgrid="http://www.opengis.net/gml/3.3/rgrid"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
service="WCS" version="2.1.0"
xsi:schemaLocation="http://www.opengis.net/wcs/metoceanProfile_getCorridor/1.0 http://schemas.opengis.net/wcs/metoceanProfile/1.0/wcsMetOceanGetCorridor.xsd">
<!-- =================================================================================-->
<!--This example illustrates how a 4D trajectory can be described e.g. a road, -->
<!--The road will have a width (in this case lateral extent of 5Km) and a centreline. -->
<!--In this example the corridor is divided into 500 segments of equal length from -->
<!--start to finish. The centre line is defined by the output feature with the way -->
<!--points being a set of latitudes and longitudes. The two axes are defined with one -->
<!--axis as being along the corridor path and the other perpendicular to it -->
<!--==================================================================================-->

<wcs:CoverageId>UK_GLOBAL_2017-05-15T00.00.00Z_ISBL</wcs:CoverageId>
<wcs:format>CovJSON/</wcs:format>
<wcs:mediaType>CovJSON/</wcs:mediaType>
<rsub:RangeSubset>
<rsub:RangeItem>
<rsub:RangeComponent>Temperature</rsub:RangeComponent>
</rsub:RangeItem>
<rsub:RangeItem>
<rsub:RangeComponent>Wind_Speed</rsub:RangeComponent>
</rsub:RangeItem>
<rsub:RangeItem>
<rsub:RangeComponent>Wind_Direction</rsub:RangeComponent>
</rsub:RangeItem>
</rsub:RangeSubset>


<!-- Define the corridor width, height and resolution. In this example the flight -->
<!-- is divided up timewise into 7 segments in time, Thus in this example the time -->
<!-- of the time is 2 hours or 120 minutes Thus each segment will be 12 minutes. Note there are 13 points-->


<metoceancorridor:path>
<metoceancorridor:PathDescription srsName="http://www.opengis.net/def/crs-compound?
1=http://www.opengis.net/def/crs/EPSG/0/4326&amp;
2=http://http://www.opengis.net/def/crs/OGC/0/AnsiDate&amp;
3= http://codes.wmo.int/grib2/codeflag/4.5/_102/Specific_altitude_above_mean_sea_level"
axisLabels="Lat Lon Time Specific_altitude_above_mean_sea_level">
<cis:DisplacementAxisNest axisLabels="Lat Lon Time Specific_altitude_above_mean_sea_level" uomLabels="deg deg ISO8601 ft">
<cis:P><cis:C>45.0</cis:C><cis:C>5.0</cis:C><cis:C>2015-05-15T00:00:00Z</cis:C><cis:C>3600</cis:C></cis:P>
<cis:P><cis:C>46.0</cis:C><cis:C>0.0</cis:C><cis:C>2015-05-15T00:15:00Z</cis:C><cis:C>3500</cis:C></cis:P>
<cis:P><cis:C>47.0</cis:C><cis:C>-5.0</cis:C><cis:C>2015-05-15T00:30:00Z</cis:C><cis:C>34200</cis:C></cis:P>
<cis:P><cis:C>48.0</cis:C><cis:C>-10.0</cis:C><cis:C>2015-05-15T00:45:00Z</cis:C><cis:C>3400</cis:C></cis:P>
<cis:P><cis:C>49.0</cis:C><cis:C>-15.0</cis:C><cis:C>2015-05-15T01:00:00Z</cis:C><cis:C>3200</cis:C></cis:P>
<cis:P><cis:C>51.0</cis:C><cis:C>-20.0</cis:C><cis:C>2015-05-15T01:15:00Z</cis:C><cis:C>3000</cis:C></cis:P>
<cis:P><cis:C>52.0</cis:C><cis:C>-25.0</cis:C><cis:C>2015-05-15T01:30:00Z</cis:C><cis:C>2000</cis:C></cis:P>
</cis:DisplacementAxisNest>
<cis:GridLimits srsName="http://www.opengis.net/def/crs/OGC/0/Index1D" axisLabels="i">
<cis:IndexAxis axisLabel="i" lowerBound="0" upperBound="6"/>
</cis:GridLimits>

<metoceancorridor:SegmentDefinition>
<metoceancorridor:discretisationMethod>DISTANCE</metoceancorridor:discretisationMethod>
<metoceancorridor:segmentsPerSector>
<cis:V>3</cis:V>
<cis:V>5</cis:V>
<cis:V>4</cis:V>
<cis:V>6</cis:V>
<cis:V>4</cis:V>
<cis:V>5</cis:V>
</metoceancorridor:segmentsPerSector>
</metoceancorridor:SegmentDefinition>
</metoceancorridor:PathDescription>
</metoceancorridor:path>

<metoceancorridor:corridorExtent>
<metoceancorridor:CorridorExtent srsName="http://www.opengis.net/def/crs-compound?
1=http://www.opengis.net/def/crs/EPSG/0/4326&amp;
2=http://http://www.opengis.net/def/crs/Corridor_Height"
axisLabels="Lat Lon Corridor" srsDimension="3">
<cis:AxisExtent axisLabel="Corridor_Width" uomLabel="deg" lowerBound="-5.0" upperBound="5.0"/>
<cis:AxisExtent axisLabel="Corridor_Height" uomLabel="ft" lowerBound="-1000.0" upperBound="1000.0"/>
<scal:Scaling>
<scal:ScaleToSize>
<scal:TargetAxisSize>
<scal:axis>Corridor_Width</scal:axis>
<scal:targetSize>5</scal:targetSize>
</scal:TargetAxisSize>
<scal:TargetAxisSize>
<scal:axis>Corridor_Height</scal:axis>
<scal:targetSize>5</scal:targetSize>
</scal:TargetAxisSize>
</scal:ScaleToSize>
</scal:Scaling>
</metoceancorridor:CorridorExtent>
</metoceancorridor:corridorExtent>

<metoceancorridor:corridorExtractionMethod>
<metoceancorridor:CorridorExtractionMethod>
<metoceancorridor:corridorExtractionMethodValue>Trajectory_Point_Interpolation</metoceancorridor:corridorExtractionMethodValue>
<metoceancorridor:corridorOrientationValue>VERTICAL</metoceancorridor:corridorOrientationValue>
<int:Interpolation>
<int:globalInterpolation>http://www.opengis.net/def/interpolation/OGC/1/linear</int:globalInterpolation>
<int:InterpolationPerAxis>
<int:axis>Corridor_Path</int:axis>
<int:interpolationMethod>http://www.opengis.net/def/interpolation/OGC/1/linear</int:interpolationMethod>
</int:InterpolationPerAxis>
<int:InterpolationPerAxis>
<int:axis>Corridor_Width</int:axis>
<int:interpolationMethod>http://www.opengis.net/def/interpolation/OGC/1/cubic</int:interpolationMethod>
</int:InterpolationPerAxis>
<int:InterpolationPerAxis>
<int:axis>Corridor_Height</int:axis>
<int:interpolationMethod>http://www.opengis.net/def/interpolation/OGC/1/barycentric</int:interpolationMethod>
</int:InterpolationPerAxis>
</int:Interpolation>
</metoceancorridor:CorridorExtractionMethod>
</metoceancorridor:corridorExtractionMethod>
</metoceancorridor:GetCorridor>