Answer: 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.
| level | standard / conformance class | definition method |
|---|---|---|
| conceptual level: concepts and terminology |
ISO 19123-1 / OGC AT6.1 | UML abstract interfaces |
| logical level: (encoding-independent) data structures |
ISO 19123-2 / OGC Coverage Implementation Schema (CIS) Clauses 5 - 10 | UML object classes |
| physical level: concrete encoding (text or binary) |
ISO 19123-2 / OGC Coverage Implementation Schema (CIS) Clauses 11 and 12 | encodings, such as XML, JSON, GeoTIFF |
Logical-level CIS historically has evolved over several steps (we look into grid coverages aka datacubes only):
On physical level,
In summary, the most recent versions are:
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:
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 WCS test oracle for 0-dimensional output rectified grids in rasdaman
Answer: Discussion on the TC Discussion list has 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.
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:
Details below:
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:
https://www.opengis.net/def/crs/{authority}/{version}/{id} is identical to the shorthand [{authority}:{id}].[EPSG:4326]
expands to
https://www.opengis.net/def/crs/EPSG/0/4326.[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 three lines are equivalent under this regime (at the time of this writing):
[EPSG:4326]https://www.opengis.net/def/crs/EPSG/0/4326https://www.opengis.net/def/crs/EPSG/9.9.1/4326
Such CRS shorthand can be used, e.g., in the srsName attribute of a coverage domain set:
srsname="[EPSG:4326],[OGC:AnsiDate]"
Note, however, that not all coverage implementations necessarily implement this feature; among the system understanding it is the open-source rasdaman WCS reference implementation.
Full CRS URLs
CRS CURIEs, as we have seen, 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 (linebreaks introduced only for a better read):
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.
Answer: For optical / hyperspectral imagery, the correct uom is Watt per square meter per steradian per nanometer.
Note:
As a common rule, UCUM (Unified Code for Units of Measure) should be used for uom.
In this syntax, the above uom is expressed as W.m-2.sr-1.nm-1.
Answer: 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.
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).
Re GML: Due to limitations in GML, only numerical coordinates are allowed. This is insufficient, e.g., with temporal axes where common date notations as per ISO 8601 (like "2022-10-02T15:33") are required. While coverages commonly use such date formats for time coordinates this will lead to XML validation errors. GML has signalled to not enhance its coordinate representations. For this and a few more reasons, CIS 1.1 departs from GML in coordinate modeling, thereby avoiding these issues.