i. Abstract

Coverages represent homogeneous collections of values located in space/time, such as spatio-temporal sensor, image, simulation, and statistics data. Common examples include 1-D timeseries, 2-D imagery, 3-D x/y/t image timeseries and x/y/z geophysical voxel models, as well as 4-D x/y/z/t climate and ocean data. Generally, coverages encompass multi-dimen­sional regular and irregular grids, point clouds, and general meshes.

This Coverage Implementation Schema (CIS) specifies the OGC coverage model by establishing a concrete, interoperable, conformance-testable coverage structure. It is based on the abstract concepts of OGC Abstract Topic 6 [1] (which is identical to ISO 19123) which spec­i­fies an abstract model which is not per se interoperable – in other words, many different and incompatible implementations of the abstract model are possible. CIS, on the other hand, is interoperable in the sense that coverages can be conformance tested, regardless of their data format encoding, down to the level of single “pixels” or “voxels.”

Coverages can be encoded in any suitable format (such as GML, JSON, GeoTIFF, or Net­CDF) and can be partitioned, e.g., for a time-interleaved representation. Coverages are independent from service definitions and, therefore, can be accessed through a variety of OGC services types, such as the Web Coverage Service (WCS) Standard [8]. The coverage structure can serve a wide range of coverage application domains, thereby contributing to harmon­ization and interoperability between and across these domains.

ii. Keywords

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

Ogcdoc, coverage, gridded data, datacube, timeseries, sensor model, point cloud, mesh

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 re­levant 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.

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

Jacobs University Bremen

Envitia Ltd

European Union Satellite Center

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

1.    Scope

1.1    Overview

This document specifies the concrete, implementable, conformance-testable coverage structure to be used by OGC standards.

Coverages represent homogeneous collections of values located in space/time, such as spatio-temporal sensor, image, simulation, and statistics data. Common examples include 1-D timeseries, 2-D imagery, 3-D x/y/t image timeseries and x/y/z geophysical voxel models, as well as 4-D x/y/z/t climate and ocean data. Generally, coverages encompass multi-dimen­sional regular and irregular grids, point clouds, and general meshes.

This Coverage Implementation Schema (CIS) specifies the OGC coverage model by establishing a concrete, interoperable, conformance-testable coverage structure. It is based on the abstract concepts of OGC Abstract Topic 6 [1] (which is identical to ISO 19123) which specifies an abstract model which is not per se interoperable – in other words, many different and incompatible implementations of the abstract model are possible. CIS, on the other hand, is interoperable in the sense that coverages can be conformance tested, regardless of their data format encoding, down to the level of single “pixels” or “voxels.”

Coverages can be encoded in any suitable data format, including formats as GML, JSON, GeoTIFF, and NetCDF. Further, coverages can be represented by a single document (stream or file) or by a hierarchically organized set of documents, each of which can be encoded individually – for example, the domain set, range type, and metadata may be encoded in easily parseable GML, JSON, or RDF while the range set is encoded in some compact binary format like NetCDF or JPEG2000. Such partitioning allows for coverages tiled in space, time, or mixed, thereby enabling mosaics, time-interleaved coverages, and efficiently subsettable datacubes.

Coverages are independent from service definitions and, therefore, can be accessed through a variety of OGC services types, such as the Web Coverage Service (WCS) Standard [8]. The coverage structure can serve a wide range of coverage application domains, thereby contributing to harmonization and interoperability between and across these domains.

1.2    Compatibility

1.2.1    OGC Abstract Topic 6 / ISO 19123

The OGC coverage model introduced with GMLCOV/CIS 1.0 and extended with CIS 1.1 is based on the abstract coverage specification of OGC Abstract Topic 6 (which is identical to ISO 19123) and harmonized with the GML coverage model [GML3.2.1] and the SWE sensor type description [SWE Common Data Model]. By way of normatively including GMLCOV/CIS 1.0 in CIS 1.1, every GMLCOV/CIS 1.0 coverage is a valid CIS 1.1 coverage. See Annex D.1 in CIS 1.1 for details.

1.2.2    GML

Like in GML, all coverage types in CIS 1.1 (as in GMLCOV/CIS 1.0) are derived from a common AbstractCoverage type. GMLCOV/CIS 1.0 is strictly derived from the corresponding GML type, so it is a GML Application Profile. CIS 1.1 is structurally equivalent, but embodies novel concepts which do not allow a formal derivation in all cases; further, modeling has been simplified over GML to make coverages easier to handle. Further, having JSON and RDF next to GML had a design impact. As a consequence, CIS 1.1 formally speak­ing is not a GML Application Profile. See Annexes D.2 and D.3 for details.

1.2.3    SWE Common

The coverage RangeType component (see Clause 6) utilizes the SWE Common [4] Data­Record. Consequently, the semantics of sensor data acquired through SWE standards can be carried over into coverages without information loss. See also Annex D.4.

1.2.4    Extensions over previous version of this standard

This document is the successor version of GML 3.2.1 Application Schema – Coverages version 1.0.1 [5], abbreviated GMLCOV 1.0. This standard was renamed to Coverage Implementation Schema (CIS) in 2015 to remedy misunderstandings caused by the initial title, such as that only a GML encoding is defined (whereas, in fact, a format-independent implementable coverage model is established). Therefore, GMLCOV 1.0 is identical to CIS 1.0.

This document augments GMLCOV/CIS 1.0 as a backwards-compatible extension: any valid GMLCOV/CIS 1.0 coverage is also valid in CIS 1.1. This is accomplished through Requirement 1 which declares any valid GMLCOV/CIS 1.0 coverage to also be a valid CIS 1.1 coverage; on XML Schema level, the CIS 1.1 schema explicitly includes the GMLCOV/CIS 1.0 schema (although, given Requirement 1, this is not strictly necessary).

CIS 1.1 adds further coverage types over GMLCOV/CIS 1.0 – in particular, for more grids – and encoding options.

• CIS 1.1 adds comprehensive definitions for all possible types of irregular grids, which has been left unspecified in the previous version. As such, CIS 1.1 also incorporates and generalizes the grid coverage concepts established in GML 3.3 [3].
• CIS 1.1 extends the physical representation schema of gridded coverages by allowing an internal partitioning to accommodate different access patterns. One special case is time-interleaved where a coverage is represented by a list of pairs (timestamp, time slice). However, the partitioning schemes are not constrained and may include both spatial and temporal axes.
• CIS 1.1 complements the GML coverage representation with equivalent JSON and RDF representation.

To achieve this, CIS implements the following Change Requests on GMLCOV 1.0 [5]:

• Support for more general grid identifiers (with punctuation, national character sets, etc.) [OGC 15-086];
• Support for general non-regular grids [OGC 15-088];
• Clear regulation for interpolation methods associated with grid coverages, thereby also clarifying a long-standing confusion between discrete and continuous grid coverages [OGC 15-087];
• Introduction of EnvelopeByAxis, an envelope type which allows for a convenient handling of any type of coordinates together with a single CRS [OGC 15-093];
• Partitioned (“tiled”) coverages, allowing – among others – “interleaved representations” of coverages [OGC 15-091] and datacubes tiled for efficient subsetting;
• Renaming from the confusing title “GML 3.2.1 Application Schema – Coverages” to “Coverage Information Schema” [OGC 15-094];
• Adding support for non-regularly gridded sensor models [OGC 15-092];
• Distinguish between grid dimension and the CRS dimension [OGC 15-089]; and
• Removal of a namespace ambiguity in Reference­able­Grid­Cov­er­age [OGC 15-090] (resolved by introduction of CIS::GeneralGridCover­age).

Further, some GML 3.2.1 schema definitions whose generality complicates coverage understanding unnecessarily have been extracted and condensed into the pertaining CIS 1.1 GML schema. This remedies an often heard complaint about the complexity not of the coverage model, but the underlying GML. As a consequence, the GML encoding of CIS 1.1 is not a GML application schema any longer, but a compact, freestanding definition. Nevertheless, by way of integrating GMLCOV/CIS 1.0 it is possible for implementers to remain in the realm of a GML application schema.

Finally, as the new features make CIS substantially more expressive, not all implementers will want to support all functionality. Therefore, a further subdivision into separate requirements classes has been performed isolating, for example, discrete and grid coverages.

In summary, CIS 1.1 is a backwards compatible extension of GMLCOV/CIS 1.0, also merging in GML 3.3 grid types. Note that irregular grid types in both GMLCOV and GML in future may get deprecated in favor of the general grid type in CIS 1.1 which is more concise, better to analyze by applications, and support cases not addressed by the previous grid approaches.

2.    Conformance

This standard defines: coverages.

Standardization target of this document are concrete coverage instance documents, as generated by some service and/or consumed by some client.

This document contains requirements for the following standardization target types (cf. Figure 1).

•   The core class coverage (in red). This is the only abstract class – it establishes the basic framework, while the concrete conformance classes listed below define how concrete coverage instances can be built.
•   The grid coverage classes (in green):
  • Class grid-regular establishes multi-dimensional unreferenced and regular referenced grids; in particular, GridCoverage and Rectified­Grid­Coverage are provided here for backwards compatibility with version 1.0 of this standard;
  • Class grid-irregular establishes multi-dimensional irregular referenced grids; and
  • Class grid-transformation establishes multi-dimensional referenced grids defined by algorithmic transformations.
•   The discrete coverage classes (in blue):
  • Class discrete-pointcloud establishes point clouds; and
  • Class discrete-mesh establishes general multi-dimensional meshes.
•   The format encoding classes (in yellow):
  • Class json-coverage establishes JSON encoding of coverages;
  • Class rdf-coverage establishes RDF encoding of coverages;
  • Class gml-coverage establishes GML encoding of coverages;
  • Class other-format-coverage establishes further encodings of coverages; and
  • Class multipart-coverage establishes a multipart encoding of coverages.
•   Class coverage-partitioning (in grey) establishes coverages composed from several sub-coverages.
•   Class container (in white) establishes a general object capable of holding coverages and any other structure.

          Classes coverage, grid-regular, grid-irregular, grid-transformation, discrete-pointcloud, and discrete-mesh together establish the conceptual coverage implementation model whereas classes gml-coverage, json-coverage, rdf-coverage, other-format-coverage, multipart-coverage, and coverage-partitioning establish encoding and representation schemes.

Figure 1 show the requirements class dependencies depicted as a UML package diagram: each package represents one class, the depends-on relationship represents the OGC requirements class dependency relationship.

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 site^[1].

In order to conform to this OGC™CISinterface standard, a software implementation shall choose to implement:

• the core class coverage plus
• at least one of the discrete or grid coverage classes plus
• at least one of the encoding classes json-coverage, gml-coverage and other-format-coverage.

Further classes can be implemented optionally as long as the dependencies set forth by this standard are respected.

Each requirements class in this standard corresponds to a single conformance class. Abstract conformance tests are listed in Annex A, whereby each test references back the requirement it assesses. Concrete implementations of these tests shall be exercised on any software artefact claiming to implement a conformance class of this standard.

Requirements and conformance tests are identified through URLs. Table 1 summarizes the respective URLs. As a rule, requirements and conformance class URLs defined in this document are relative to http://www.opengis.net/spec/CIS/1.1/.

All requirements-classes and conformance-classes described in this document are owned by the standard(s) identified.

This OGC Coverage Implementation Schema consists of the UML diagrams and textual requirements classes established in this document as well as an external file bundle consisting of the corresponding XML Schema including Schematron constraints. The complete specification is identified by OGC URI http://www.opengis.net/spec/CIS/1.1, the document has OGC URI http://www.opengis.net/doc/AppSchema/CIS/1.1.

The complete standard is available at http://www.opengeospatial.org/standards/cis. The XML Schema is posted online at http://schemas.opengis.org/cis/1.1 as part of the OGC schema repository.

3.    References

The following normative documents contain provisions that, through reference in this text, constitute provisions of this document. The latest edition with the same major release number[3] as the document referred below applies.

[1]       OGC: OGC 07-011,Abstract Specification Topic 6: The Coverage Type and its Subtypes, version 7.0 (identical to ISO 19123:2005), 2007

[2]       OGC: OGC 07-036, Geography Markup Language (GML) Encoding Standard, version 3.2.1, 2007

[3]       OGC: OGC 10-129r1, OGC^® Geography Markup Language (GML) – Extended schemas and encoding rules(GML 3.3), version 3.3, 2012

[4]       OGC: OGC 08-094, OGC^® SWE Common Data Model Encoding Standard, version 2, 2011

[5]       OGC: OGC 12-000, OGC® SensorML: Model and XML Encoding Standard, version 2, 2014

[6]       OGC: OGC 09-146r2, GML 3.2.1 Application Schema – Coverages, version 1.0.1, 2012

[7]       OGC: OGC 16-083, Coverage Implementation Schema – ReferenceableGridCoverage Extension, version 1, 2017

[8]       OGC: OGC 09-110r4, Web Coverage Service (WCS) Core Interface Standard, version 2, 2012

[9]       OGC: OGC 13-102r2, Name type specification – Time and index coordinate reference system definitions (OGC Policy Document), version 1, 2014

[10]    OGC: OGC 14-121, Web Information Service (WIS), version 1 (unpublished)

[11]    W3C: W3C Recommendation, XML Path Language (XPath), version 2, 2007

[12]    W3C: W3C Recommendation, XML Linking Language (XLink), version 1, 2001

[13]    W3C: W3C Working Draft, The app: URI scheme, 2013

[14]    ISO/IEC: ISO/IEC 19757-3:2006 Information technology – Document Schema Definition Languages (DSDL) – Part 3: Rule-based validation – Schematron, 2006

[15]    IETF: RFC 2183, 1997

[16]    IETF: RFC 2387, 1998

[17]    IETF: RFC 2392, 1998

[18]    IETF: RFC 3986, 2005

[19]    IETF: RFC 7159, The JavaScript Object Notation (JSON) Data Interchange Format. https://www.ietf.org/rfc/rfc7159.txt, 2014

[20]    W3C: W3C JSON-LD 1.0, A JSON-based Serialization for Linked Data. http://www.w3.org/TR/json-ld/, 2014

[21]    W3C: W3C JSON-LD 1.0 Processing Algorithms and API.
 http://www.w3.org/TR/json-ld-api, 2014

[22]    W3C: W3C RDF 1.1 Concepts and Abstract Syntax.
https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/, 2014

4.    Terms and definitions

This document uses the specification terms defined in Subclause 5.3 of OGC Web Service Commons [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.

For the purposes of this document, the terms and definitions given in the above references apply. In addition, the following terms and definitions apply.

4.1       coverage

feature that acts as a function to return values from its range for any direct position within its spatiotemporal domain, as defined in OGC Abstract Topic 6 [1]

4.2       Regular grid

grid whose grid lines have a constant distance along each grid axis

4.3       Irregular grid

Grid whose grid lines have individual distances along each grid axis

4.4       Displaced grid

grid whose direct positions are topologically aligned to a grid, but whose geometric positions can vary arbitrarily

4.5       Mesh

coverage consisting of a collection of curves, surfaces, or solids, respectively

4.6       Partition [of a coverage]

separately stored coverage acting, by being referenced in the coverage on hand, as one of its components

4.7       Sensor model

mathematical model for estimating geolocations from  recorded sensor data such as digital imagery

4.8       Transformation grid

grid whose direct positions are given by some transformation algorithm not further specified in this standard

5.    Conventions

5.1    UML notation

Diagrams using the Unified Modeling Language (UML) static structure diagram, as described in Subclause 5.2 of OGC Web Service Commons [OGC 06-121r9], adhere to the following conventions:

• UML elements having a package name of “GML” are those defined in the UML model of GML 3.2.1 [2];
• UML elements having a package name of “SWE Common” are those defined in the UML model of SWE Common 2.0 [4]; and
• UML elements not qualified with a package name, or with “CIS”, are those defined in this standard.

Further, in any class where an attribute name or association role name is identical to a name in some superclass the local definition overrides the superclass definition.

5.2    Namespace prefix conventions

UML diagrams and XML code fragments adhere to the namespace conventions shown in Table 2. The namespace prefixes used in this document are notnormative and are merely chosen for convenience. The namespaces to which the prefixes correspond are normative, however.

Whenever a data item from a CIS-external namespace is referenced this constitutes a normative dependency on the data structure imported together with all requirements defined in the namespace referenced.

6.    Class coverage

6.1    Overview

Class coverage lays the foundation for the coverage implementation schema. It is the core class of CIS, meaning that every coverage instance must conform to the requirements stated here. Class coverage does not allow creating coverage instances, but rather provides the fundament for the further classes (see next Clauses) which define various specializations of which instance documents can be created.

          Clause 6 establishes a concrete conceptual model of a coverage which is independent from any particular encoding. While, in addition to UML, GML sometimes is used for establishing this (in particular when concepts and definitions from GML 3.2.1 [2] are used where a UML representation is not provided by that standard), CIS does not anticipate a GML encoding. Various encodings are established in Clauses 12 onwards.

This CIS 1.1 standard unifies OGC’s coverage implementation model. It does so by extending CIS 1.0 (also known as GMLCOV 1.0) with further ways to model and represent coverages, and by integrating the GML 3.3 grid types.

With the introduction of the CIS GeneralGridCoverage type and its unified modelling of all grid types, the gridded types of GMLCOV/CIS 1.0 [5], GML 3.3 [3], and ReferenceableGridCoverage Extension [7] may get deprecated in future.

6.2    Coverages

Coverages are represented by some binary or ASCII serialization, specified by some data (en­coding) format. Coverage encoding is governed by specific standards. Some such encodings are defined as part of this standard in the classes gml-coverage, json-coverage and rdf-coverage; further formats are allowed through class other-format-coverage. In any case, for an instantiation of the general coverage definition given in this Clause 6 a concrete encoding needs to be available in the implementation on hand.

With the introduction of the CIS GeneralGridCoverage type and its unified modelling of all grid types, the gridded types of GMLCOV/CIS 1.0 [5], GML 3.3 [3], and ReferenceableGridCoverage Extension [7] may get deprecated in future.

          Not all encodings may be able to represent the full information making up a coverage, i.e.: not all encodings are informationally complete.

A coverage contains a DomainSet component describing the coverage’s domain (the set of “direct positions”, i.e., the locations for which values are stored in the coverage) and a RangeSet component containing these stored values (often referred to as “pixels”, “voxels”) of the coverage. Further, a coverage contains a RangeType element which describes the coverage’s range set data structure (in the case of images usually called the “pixel data type”). Such a type often consists of one or more fields (also referred to as bands or channels orvariables), however, much more general definitions are possible. For the description of the range value structure, SWE Common [OGC 08-094] Data­Record is used. The metadata component, finally, represents an extensible slot for metadata. The intended use is to hold any kind of application-specific metadata structures.

          In this requirements class, coverage, a domain set invariably consists of a domain/range representation; requirements class coverage-partitioning (Clause 17) will add partitioning and position/value pair list as alternatives. This is why coverage subtype CoverageByDomainAndRange is introduced in Figure 2; while it may seem artificial in this requirements class, it will allow modelling the alternative representations in the future.

          The Envelope item may be modelled differently in different encodings. In GML, for example, the Envelope element is enclosed in a boundedBy element.

The id attribute is the same as in GML and GMLCOV, but its type is extended from NC­Name to string to achieve a more human-readable style allowing for whitespace, special characters, globally unique naming schemes, etc.

Coverages make heavy use of n-dimensional coordinates in a space that may be made up from spatial and/or temporal and/or “abstract” (i.e., non-spatio/temporal) axes. For representing direct positions of coverages, such n-dimensional coordinates are modelled through type CIS::DirectPosition. Each coordinate component is of the general type any­Simple­Type (in analogy to XML Schema) as it must accommodate data types as diverse as numbers (such as 1.23 degrees), dates (such as “2016-03-08”), and abstract categorical values (such as “orange”, “apple”). The order of the coordinates is given by the axis order of the CRS defined in the context in which the direct position is used.