Coverages FAQ

What is the Authoritative Coverage Data Model Standard, and which Version?

The coverage data standards form an aligned set of specifications, each addressing a particular facet. Standards are organized along the common structure of conceptual, logical, and physical data levels (not sure what this is? see for example this introduction).

The table below explains this landscape; bear in mind that the granularity is: specification documents regularly contain conformance classes as building blocks - hence, the conformance classes need to be looked at, if existing.

Logical-level CIS historically has evolved over several steps (we look into grid coverages aka datacubes only):

• CIS 1.0 (aka ISO 19123-2:2018): GML-based Rectified Grid Coverages; CIS Extension for GML-based Referenceable Grid Coverages.
• CIS 1.1: adds General Grid Coverages, in addition to the existing coverage types (hence, backwards compatible).
• CIS 1.2 (aka ISO 19123-2:2026): re-integrates CIS 1.0 and 1.1 as well as the Referenceable Grid Extension into a single specification document. CIS 1.2 emphasizes the modern General Grid Coverage, which can model all previous coverage types plus further cases hitherto not addressed), deprecating Rectified and Referenceable Grid Coverage in an isolated annex.

On physical level,

• CIS 1.0 has defined a GML encoding, together with a series of extensions (i.e., separate specification documents) for GeoTIFF, NetCDF, JPEG2000, and more formats.
• CIS 1.1 General Grid has cautiously liberated itself from GML and offers conformance classes for XML, JSON, and RDF, in addition to the above encoding extensions.
• CIS 1.2 keeps the pre-existing encodings, but adds a modernized JSON Schema encoding.

In summary, the most recent versions are:

• ISO 19123-1:2023 (OGC AT6.1 adopted later, but with identical contents)
• ISO 19123-2:2026 (OGC CIS update under adoption)

WCS Extensions refer to WCS Core 2.0 - what about WCS 2.1?

Answer: all WCS 2.0 extensions apply equally to WCS 2.1, see the corresponding clarification in the WCS 2.1 Core specification. In other words: all WCS extension functionality work on CIS 1.1 coverages.

In more detail:

• WCS 2 Core is the successor of grandfathered WCS 1. The concept of modularity and extensions was introduced only in WCS 2, so there are no predecessor versions of the extensions, and consequently they all start with 1.0 despite they are children of WCS Core 2.0. (Fun fact: WCS was the first OGC specificationi implementing the core/extension structure.)
• WCS Core 2.0 makes use of CIS 1.0. When CIS 1.1 emerged, adding new coverage type GeneralGridCoverage, WCS had to be adjusted due to OGC formalities, leading to WCS 2.1. The only difference of WCS 2.1 over WCS 2.0 is that it additionally supports coverage type GeneralGridCoverage.
• Versioning of the extension standards is done in splendid isolation. For example, WCS Core 2.0 (and, by OGC rules, also WCS Core 2.1) has extension WCS-Interpolation 1.0. In 2025, WCS-Interpolation was enhanced leading to WCS-Interpolation 1.1, which still relates to WCS Core 1.1.
• In summary: WCS Core 2.x has extensions WCS 1.x, such as WCS-Transaction 1.x, WCS-Interpolation 1.x, etc.

How to represent a 0-dimensional coverage?

Related issues: What happens when all the CRS dimensions get sliced in a WCS request? How to encode the CIS/GMLCOV description?

Answer: As per CIS/GMLCOV, the domain set of a coverage cannot have 0 dimensionality: at least for the GML encoding, the //gml:domainSet/@dimension attribute shall be greater or equal than 1. There is no clear guidance on 0-D in the OGC standards, The recommended solution is to represent such a coverage by the single (atomic or composite) range value in the range set and an empty domain set.

Example: See the rasdaman WCS test oracle for 0-dimensional output rectified grids: browser:systemtest/testcases_services/test_wcs/oracle/18-get_coverage_0D.oracle.

Are time intervals closed or open?

Answer: Discussion on the TC Discussion listhas confirmed that time intervals represent left-closed, right-open intervals, often written as [a:b). This maintains clean interval arithmetics, such as avoiding duplicate values when combining two adjacent intervals.

Related: In its latest release, ISO 8601 seems to drop 24:00 as a valid timestamp as it is equivalent to 00:00 of the next day. This removes an ambiguity where two different notations indicated the same time.

How can I construct the URL of a CRS as needed for a coverage?

Answer: By definition, every coverage has one CRS attached; in case of a grid coverage, there is additionally the internal Cartesian coordinate system of the array representing the range set. Following OGC convention, there are two ways to express (simple or composite) CRSs:

- as URLs following ISO 19111 (powerful, long, complicated)

- as compact URIs aka CURIEs (simplified, compact)

CRS CURIEs

The long, hard-to-read URLs like https://www.opengis.net/def/crs/EPSG/0/4326 mostly are geared towards machine consumption – nevertheless, they were felt as unwieldy and so the rasdaman team at some time suggested a bracket notation as shorthand, following the CURIE standard, discussed in OGC for both atomic and composite CRSs. Meanwhile these shortcuts are adopted by the OGC Naming Authority and officially permitted as alternatives to the CRS URLs. Due to their simplicity they are recommended today. CURIE notation is registered in the Vocabulary Register (caveat: does not yet contain all CRSs).

CURIE syntax of [{authority}:{crs}] has been adopted where {authority} is the short name of the issuing body (eg, EPSG) and {crs} is the identifier (eg, 4326). Thus, [EPSG:4326] is an admissible CRS notation which can be used, eg, as the value of an srsName attribute in a coverage. Composite CRSs simply are written as comma-separated lists of CRS CURIEs, such as [EPSG:4326],[OGC:Gregorian].

Rules for constructing CURIEs are simple:

• A non-composite CRS URL of pattern https://www.opengis.net/def/crs/{authority}/{version}/{id} is identical to the shorthand [{authority}:{id}].
• Version number is 0 by definition, interpreted as "latest version available". For example, [EPSG:4326] expands to https://www.opengis.net/def/crs/EPSG/0/4326.
• A composite CRS URL is translated into a comma-separated sequence of the component CRSs, each of which is tran¬scrib¬ed individually as per the rule above. For example, [EPSG:4326],[OGC:AnsiDate] is equivalent to the long version https://www.opengis.net/def/crs-compound? 1=https://www.opengis.net/def/crs/OGC/0/AnsiDate&2=https://www.opengis.net/def/crs/EPSG/0/4326

Note that this CURIE notation allows only reference to the latest, current version, in OGC expressed as version 0 in URLs. Hence, the following lines are equivalent under this regime (at the time of this writing):

Note, however, that not all coverage implementations necessarily implement this feature; among the system understanding it is the rasdaman WCS reference imple-mentation.

Full CRS URLs

Such CRS CURIEs actually are abbreviations of the full URL, governed by the expansion pattern of https://www.opengis.net/def/crs/{authority}/0/{crs}. For example, [EPSG:4326] is equivalent to http://www.opengis.net/def/crs/EPSG/0/4326. Such a URL is unwieldy, but it can be resolved in the sense that the URL points to a definition of the CRS (currently: in XML), hence allowing a lookup at any time.

CRSs for higher-dimensional coverages can be composed from existing CRSs and axes, as described in the resolver wiki. Here is an example for image timeseries using WGS84:

https://www.opengis.net/def/crs-compound?
  1=https://www.opengis.net/def/crs/EPSG/0/4326 &
  2=https://www.opengis.net/def/crs/OGC/1.0/Gregorian-Date

There are several branches in the OGC CRS Resolver hosting CRSs, CSs, axes, etc. - see the OGC resolver wiki for details.

What is the correct uom (unit of measure) for hyperspectral satellite imagery?

Answer: As a common rule, UCUM should be used for uom. Specifically for optical / hyperspectral imagery, the correct uom is W.m-2 (Watt per square meter, integrated over all observed frequency range).

Notes:

• occasionally a uom of W.m-2.sr-1 is advertised which adds "per Steradian". This is generally not considered the correct option. [TODO: add technical rationale]
• occasionally W.cm-2 is advertised which uses "per square centimeter" instead of "per square meter". The difference is simply a factor of 100x100=10^4.

Bbox vs domain set

Sometimes it is said that the bounding box (bbox) defines the coverage placement in space/time. Actually, this concept is defined in ISO 19123-1 / OGC Abstract Topic 6.1 which clearly conveys: at the heart of the "location" part of a coverage structure is not the bbox, but the domain set. In this context, also ISO 19111 - Geographic information - Referencing by coordinates is relevant and will be addressed below.

• envelope: 19123-1 defines an optional envelope which serves for a quick position information: where is this coverage? To this end, the envelope can contain less (!) dimensions than the coverage with its domain set. For example, an envelope might be a 2D WGS84 bbox so that a map utility can draw a box even before/without reading the contents (ie, range set).
• bbox: 19123-1 does not use this term normatively, it just relates it in the descriptive text: "The coverage’s Extent gives a bounding box – i.e.: lower and upper bounds along every coordinate axis – within which all its Direct Positions are located. " (p 24, Subclause 5.4.1) So a bbox is described by an ordered list of [min,max] intervals, corresponding exactly to the axes of the coverage (ie: all axes).
• 19123-1 sees the bbox concept as just some auxiliary, derived information which is just a faceet of the domain set information: The extent of a coverage is the set of all direct positions = all locations where values are available (stored - not via interpolation). The bbox can be derived from this (as the smallest enclosing axis-parallel hyper-rectangle) but contains less information. For example, regular and irregular grids require extra information to determine the direct positions (obviously).

Re ISO 19111: coordinate is defined as "one of a sequence of n numbers designating the position of a point in n-dimensional space". Could be generalized to any totally ordered set (concerned about wraparound? see Table 29). This is the basis for "diagonal corners" used as bbox (although this term is not used in 19111).

Interestingly, 19111 refers to 19115 for geographic bounding box. That said, the basic ingredients are defined there: CRSs rely on axes, and an axis is defined numerically (cf. Table 27). In fact, this is one of the big discussion points between CRS.SWG / GML activists and Coverages.SWG because Coverages.SWG refused to only allow time coordinates in seconds since epoch, which CRS.SWG insisted on - one main reason (although not the only one) why coverages deviated from GML.