Approved

OGC Standard

•
OGC MetOcean Application profile for WCS2.1: Part 1 MetOcean GetCorridor Extension
Peter Trevelyan Editor Paul Hershberg Editor Steve Olson Editor
Submission Date: 2017-08-19 Approval Date: 2019-02-04 Publication Date: 2021-03-22 External identifier of this OGC® document: http://www.opengis.net/doc/IS/WCS_application-profile_metocean_corridor/1.0 Internal identifier of this OGC® document: 15-108r3
Version: 1.0
Additional Formats: XML PDF DOC
OGC Standard

Approved

Warning

This document is an OGC Member approved international standard. This document is available on a royalty free, non-discriminatory basis. Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

Document number:15-108r3
Document type:OGC Standard
Document subtype:Implementation
Document stage:Approved
Document language:English

Copyright notice

Copyright © 2021 Open Geospatial Consortium
To obtain additional rights of use, visit http://www.ogc.org/legal/

Note

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.

 


License Agreement

Permission is hereby granted by the Open Geospatial Consortium, (“Licensor”), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

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

Suggested additions, changes and comments on this standard are welcome and encouraged. Such suggestions may be submitted using the online change request form on OGC web site: http://portal.opengeospatial.org/public_ogc/change_request.php

 



I.  Abstract

This document defines an extension to WCS2.1, namely the extraction of data along a corridor defined by a path and corridor extent consisting of an information model and an XML encoding for the following two operations:

  1. GetCapabilities — a WCS function that describes the services and operations via a GetCapabilities document.

  2. GetCorridor —  a WCS function that supports this operation to extract data from a multidimensional cube along a path, or corridor.

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

II.  Keywords

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

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


III.  Preface

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

IV.  Security Considerations

No security considerations have been made for this standard.

V.  Submitting Organizations

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

VI.  Submitters

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

Name Affiliation
Peter Trevelyan Met Office, UK
Paul Hershberg

National Oceanic and Atmospheric Administration (NOAA)

National Weather Service (NWS)
Steve Olson

National Oceanic and Atmospheric Administration (NOAA)

National Weather Service (NWS)

OGC MetOcean Application profile for WCS2.1: Part 1 MetOcean GetCorridor Extension

1.  Scope

The purpose of the GetCorridor operation is to extract a corridor based on a trajectory from a multidimensional coverage. The need for the getCorridor operation stems from active members of the OGC MetOcean Domain Working Group (DWG) who saw a manifest need for extraction of such information from gridded datasets. This work has been done by members of the OGC MetOcean Domain Working Group.

2.  Conformance

This standard defines:

Conformance with this standard shall be checked using all the relevant tests specified in Annex A (normative) of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site1.

In order to conform to this OGC™ interface standard, a software implementation shall choose to implement: http://cite.opengeospatial.org/

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: http://www.opengis.net/spec/WCS_application-profile_metocean_corridor/1.0/

This document establishes the following requirements and conformance classes:

The corresponding conformance class is getCorridor with URI http://www.opengis.net/spec/WCS_application-profile_metocean_corridor/1.0/conf/getCorridor See A.1

The corresponding conformance class is PathDescription with URI http://www.opengis.net/spec/WCS_application-profile_metocean_corridor/1.0/conf/PathDescription . See A.2

The corresponding conformance class is CorridorExtent with URI http://www.opengis.net/spec/WCS_application-profile_metocean_corridor/1.0/conf/CorridorExtent . See A.3

The corresponding conformance class is CorridorExtractionMethod with URI http://www.opengis.net/spec/WCS_application-profile_metocean_corridor/1.0/conf/CorridorExtractionMethod . See A.4

The corresponding conformance class is offering with URI http://www.opengis.net/spec/WCS_application-profile_metocean_corridor/1.0/conf/getCorridor-post-xml . See A.5

The corresponding conformance class is offering with URI http://www.opengis.net/spec/WCS_application-profile_metocean_corridor/1.0/conf/getCorridor-simple See A.6

The corresponding conformance class is offering with URI http://www.opengis.net/spec/WCS_application-profile_metocean_corridor/1.0/conf/getCorridor-simple-get-kvp See A.7

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

Peter Baumann, Jinsongdi Yu: OGC 12-039, OGC® Web Coverage Service Interface Standard —  Scaling Extension. Open Geospatial Consortium (2014). https://portal.ogc.org/files/?artifact_id=54504

Peter Baumann, Jinsongdi Yu: OGC 12-049, OGC® Web Coverage Service Interface Standard —  Interpolation Extension. Open Geospatial Consortium (2014). https://portal.ogc.org/files/?artifact_id=54502

Peter Baumann, Jinsongdi Yu: OGC 11-053r1, OGC® Web Coverage Service Interface Standard — CRS Extension. Open Geospatial Consortium (2014). https://portal.ogc.org/files/?artifact_id=54209

Peter Trevelyan, Paul Hershberg, Steve Olson: OGC 15-045r7, OGC MetOcean Application profile for WCS2.1: Part 0 MetOcean Metadata. Open Geospatial Consortium (2020)

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-121r9, 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.

4.1. 

numerical weather prediction model

A Numerical Weather Prediction (NWP) model is 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 for numerical weather prediction model: forecast model, NWP Model, simulation

An Example of a numerical weather prediction model: The ECMWF model that runs twice per day and creates a ten day prediction of the global atmosphere.

4.2. 

reference time

Reference time is 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. Synonym for reference time: model run time.

An example of reference time: 2017-12-12T00.00.00Z

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.

4.3. 

validity time

Validity time is 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.

Synonyms for validity time: verification time.

An example of validity time 2017-12-12T12.00.00Z

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.

4.4. 

GRIB

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

4.5. 

Web Coverage Service 2.1 (WCS2.1)

Web Coverage Service (WCS) is an OGC standard that refers to the exchange of geospatial information as ‘coverages’: digital geospatial information representing space-varying phenomena.

4.6. 

GetCapabilities operation

The getCapabilities is a WCS operation involving a machine to machine communication. A getCapabilities request to a WCS server returns a a list of what operations and services (“capabilities”) are being offered by that server.

4.7. 

DescribeCoverage

A DescribeCoverage is a WCS operation involving a machine to machine communication. A DescribeCoverage request to a WCS server returns additional information about a coverage that a client wants to query. Generally speaking, a DescribeCoverage response includes information about the 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.

4.8. 

path

The path is simply the route or course along which something travels or moves, for example the path of an aeroplane.

4.9. 

Corridor

A Corridor, in this document, is a trajectory (aka path) with a lateral and vertical extent. The corridor may be multi-dimensional, and in the case of aviation is often four dimension, i.e. x, y, z, t.

4.10. 

GetCorridor operation

The GetCorridor is a newly proposed MetOcean operation involving a machine to machine communication. A GetCorridor request to a WCS server returns a corridor coverage based on a trajectory path with a lateral and vertical extent (the corridor).

5.  Conventions

This sections provides details and examples for any conventions used in the document. Examples of conventions are symbols, abbreviations, use of XML schema, or special notes regarding how to read the document.

5.1.  Abbreviated terms

GML Geography Markup Language

O&M Observations and Measurements

OGC Open Geospatial Consortium

MetOcean Meteorological/Oceanographic

NWP Numerical Weather Prediction

SWE OGC Sensor Web Enablement

UML Unified Modelling Language

WCS2.0 OGC Web Coverage Service version 2.0

WCS2.1 OGC Web Coverage Service version 2.1

WMO World Meteorological Organization

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 in which the class exists. This is just for informative purposes.

Blue: WCS2.1 plus extensions (rsub, scal, int and crs)

Orange: CIS (Coverage Implantation Schema 1.1)

Green: This standard

Tan: WCS2.1

6.  Vocabularies

This standard defines a number of properties that require the use of codes or vocabulary items. In some cases a list of terms is provided. The MetOcean Profile, on which this builds, has a specific vocabulary provided by the WMO (World Meteorological Office). These vocabularies are concerned with the naming of parameters (variables) used in the rsub:RangeSubset element, the coordinate reference systems (aka fixedSurfacetypeAndUnits) used in the srsName attribute, the units of measure, and the significance of time codes. The following table lists the references used within this document.

Table 1 — Summary of vocabularies within this standard

Code list Code reference
GRIB edition 2 http://codes.wmo.int/_grib2
Discipline http://codes.wmo.int/grib2/codeflag/_0.0
Fixed surface types and units http://codes.wmo.int/grib2/codeflag/_4.5
Parameter category http://codes.wmo.int/grib2/codeflag/_4.1
Parameter number http://codes.wmo.int/grib2/codeflag/_4.2

7.  Non-Normative (Informative) Material

The GetCorridor extension for WCS2.1 is an initiative of the MetOcean DWG to enhance the WCS2.1 core profile to extract coverages other than those extracted using the simple SLICE and TRIM methods provided by the core GetCoverage operation see Figure 1. See the OGC® Web Coverage Service 2.1 Interface Standard — Core (OGC 17-089r1). This specific extension is designed specifically to extract corridors from multidimensional cubes such as those created by numerical simulations (i.e. NWP) commonly found in the MetOcean community.

image

Figure 1 — WCS GetCoverage operation UML class diagram

The need for this work arises out of the growing need to transfer increasing amounts of data across networks. This can, and should, be done more efficiently by sub-setting (in this case corridors) data on the server and transferring the relevant data to the client. The obvious candidate for this service is the OGC’s WCS2.1 and it is therefore logical to extend this standard to include an additional GetCorridor extension. The advent of the Coverage Implementation Schema (CIS1.1) has made this much easier through the use of axis specific definitions.

7.1.  WCS2.1

The WCS2.1 files (see https://portal.opengeospatial.org/files/?artifact_id=67116&version=1) form the core standard and the extensions (see below) describe the GetCapabilities, DescribeCoverage and GetCoverage operations. The GetCorridor extension will use the following extensions to WCS core:

The main benefit of WCS2.1 to the MetOcean Profile and specifically the getCorridor operation is that it allows the description of a CIS 1.1 Coverage (see Figure 2). This is important in that CIS 1.1 supports multi-dimensional coverages and the encoding of coverage types such as corridors.

image

Figure 2 — UML Diagram representing the coverage model (CIS 1.1)

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

A “coverage” contains a “DomainSet” component describing the coverage’s domain (i.e. the locations for which values are stored in the coverage) and a “Range­Set” component containing the values of the coverage. In addition, a “coverage” also contains a RangeType element that describes the coverage’s range set data structure that consists of one or more fields (also referred to as parameters) that uses the SWE Common [OGC 08-094] Data­Record. The metadata component represents an extensible slot for metadata. The CIS1.1 UML diagram is shown in ) Figure 2.

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.4.  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 ISO 19156:2011, Geographic information — Observations and measurements. ISO 19156:20011 refers to the applicability of the data using a chronological Gregorian calendar.

Furthermore, data are temporally dependent relative to some reference time instant. Examples include:

  • Observations with an accession time into a data repository.

  • Numerical weather forecasts with a nominal time where observations have been assimilated to initialize the calculation.

  • Alerts with a time denoting when they are issued or published.

The diversity of such reference times precludes defining a dimension type with explicit semantics, although the need for a mechanism to distinguish data based on some temporal referent is widely shared. Thus, the definition of a generic dimension, named 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 time stamp string representation is built from both time components and specific separators. A full time stamp string representation has the following format:

“YYYY-MM-DDThh:mm:ss.SSSZ”

Where:

  • 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 expressed as tmin/tmax/r, where tmin and tmax are timestamps that define the lower and upper bounds of the interval and r is the resolution. The interval contains all timestamps tmin + i * r, i >= 0, that are lower or equal than tmax. A resolution r is represented by the format P [n1Y] [n2M] [n3D] [T [n4H] [n5M] [n6S]] where:

  • P is a starting character.

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

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

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

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

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

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

Some examples of time:

1- A Time stamp

2015-05-15T00:00:00Z

2- A list of time stamps

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

3- A start and end time

2015-05-15T00:00:00Z/2015-05-17T12:00:00Z

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

2015-05-15T00:00:00Z/2015-05-17T00:00:00Z/PT12H

Note that time duration refers to a span of time relative to the reference time. Reference time is specified using the following construct

<om:parameter
    xmlns:om="http://www.opengis.net/om/2.0"
    xmlns:gml="http://www.opengis.net/gml/3.2"
    xmlns:xlink="http://www.w3.org/1999/xlink">
<om:NamedValue>
<om:name xlink:href="http://codes.wmo.int/grib2/codeflag/1.2/
significanceOfReferenceTime" xlink:title="Start of Forecast"/>
<om:value xsi:type="gml:TimeInstantType" gml:id="referenceTime">
<gml:timePosition>2015-05-15T03:30:00Z</gml:timePosition>
</om:value>
</om:NamedValue>
</om:parameter>

Examples of time duration include PT0H, PT6H, PT12H. Consequently, PT12H denotes a time duration of 12 hours relative to the reference time.

When no reference time is specified, but the times are relative to a starting and end point then a recurring time interval can be used. An example of this is:

2015-05-15T00:00:00Z/2015-05-17T00:00:00Z/PT12H

When no reference time is specified, a set of timestamps may also be used. An example of this is: 2015-05-15T00:00:00Z, 2015-05-15T12:00:00Z, 2015-05-15T18:00:00Z/ Note where times are irregular, the form start/end/interval is not appropriate.

7.5.  Trajectories and corridors:

In this document a trajectory with a lateral and vertical extent is known as a corridor. The corridor may be multi-dimensional, as in the case of aviation that has four dimension, i.e. x, y, z, t). A typical flight path is shown in Figure 3.

Figure 3 — A typical flight path

It will be constructive to present some scenarios and how they can be used to extract a trajectory/corridor. These examples are based on MetOcean use cases, but can be easily extended to other communities of interest. It is not expected that all scenarios will be available on the server, and it will be necessary to advertise different levels of server capability via the GetCapabilities response document.

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.  Methods of extraction

There are a number of extraction patterns and those that are considered to be most relevant are listed below. The diagrams are mainly in 2D, but are detailed enough to convey the concepts being described.

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