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.

6.3    CoverageFunction

The coverageFunction component is identical in its syntax and meaning to the corresponding element defined in GML 3.2.1 [2] Subclause 19.3.11. It describes the mapping function from the domain to the range of the coverage. For a grid coverage, it specifies the serialization of the multi-dimensional grid in the range set.

Note 1       This becomes particularly relevant when defining encoding formats, such as GML or JSON.

Note 2       For the reader’s convenience, the default is copied from GML 3.2.1: If the gml:cover­age­Function property is omitted for a gridded coverage (including rectified gridded coverages) the gml:startPoint is assumed to be the value of the gml:low property in the gml:Grid geometry, and the gml:sequenceRule is assumed to be linear and the gml:axisOrder property is assumed to be “+1 +2”.

6.4    Envelope and DomainSet

The domain set determines the exact locations of a coverage overall and its set of direct positions. The domain set is defined through an ordered list of axes whose lower and upper bounds establish the extent along each axis. The axis sequence and their meaning is defined by the CRS which is given by a GML::SRSReferenceGroup consisting of the URI identifying the CRS. This domain set CRS is called the coverage’s Native CRS.

Additionally, some redundant information is present in the domain set for efficiency reasons: the number of dimensions, axis labels, and UoM (Unit of Measure) labels simplify parsing the coverage as the parser does not have to retrieve the CRS definition, such as from the OGC CRS resolver at http://www.opengis.net/def/crs and http://www.opengis.net/def/crs-compound.

The optional CIS::Envelope component helps applications in gaining a quick overview on the coverage’s location. The location information does not need to use the same CRS as the domain set, therefore the bounding box may not always be the minimal.

          Particularly in presence of displaced axes, transformation axes, and discrete coverages the domain set can quickly become hard to oversee.

          As in GML 3.2.1, the envelope of a  coverage, if present, encloses the entire coverage instance; it does not have to be minimal, though (for example, if the envelope is in a different – possibly easier to evaluate – CRS such as WGS84 a minimal bounding box normally cannot be expressed exactly).

As the envelope coordinate values refer to a CRS and its axes it is necessary to link to those references. To this end, a CRS identifier is provided through a URL referencing its definition. Axes used by the coverage are identified by their position in the (ordered) list of axes given in the CRS. In the axisLabels string, alias names are established for the axes used in the axis­Ex­tent components, matched with the axis through their position in the sequence. Additionally, the units of measure are indicated for each axis.

          This definition relaxes the axisLabels handling as per GMLCOV/CIS 1.0 where the identifiers referenced in axisLabels had to be identical to the corresponding axisAbbrev value in the CRS definition. In CIS 1.1, coverage axisLabels and CRS axisAbbrev are decoupled so that there is no such dependency any longer. This definition is backwards compatible, i.e., coverages can continue to use CRS axisAbbrev values; note, though, that axisAbbrev values in subsequent versions of a CRS may change without notice, so the correspondence may get lost over time.

Example    The following envelope, encoded in XML, utilizes EPSG 4326 with two axis labels, “Lat” and “Long.” These labels correspond to the CRS axis abbreviations of EPSG v8.5, but not to EPSG v8.9.2 where the axis abbreviation for Longitude has been changed to “Lon”. In CIS 1.1, this is not an issue because (i) CRS axes are ordered and (ii) values in axisLabels are matched by position, so axis label “Long” is unambiguously associated with CRS axis abbreviated as “Lon.”

<Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326"
     axisLabels="Lat Long" srsDimension="2">
     <AxisExtent axisLabel="Lat"
        uomLabel="deg"
        lowerBound="-80"
        upperBound="-70"/>
     <AxisExtent axisLabel="Long"
        uomLabel="deg"
        lowerBound="0"
        upperBound="10"/>
 </Envelope>

Actually, a coverage is completely free to use any identifier whereby the syntax of identifiers is given by the encoding used; in GML, for example, it is NCName. The following version is semantically identical to the above:

<Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326"
     axisLabels="a1 a2" srsDimension="2">
     <AxisExtent axisLabel="a1"
        uomLabel="deg"
        lowerBound="-80"
        upperBound="-70"/>
     <AxisExtent axisLabel="a2"
        uomLabel="deg"
        lowerBound="0"
        upperBound="10"/>
 </Envelope>

This demonstrates that an axis label may be identical to the axis­Abbrev value in CRS definition, but does not have to.

          At the time of this standard’s writing the widely used EPSG database – which forms the basis also for the OGC CRS resolver, http://www.opengis.net/def/crs/ - does not have unit symbols, only non-nor­mative names. Therefore, in general it is currently not possible to auto­matically deduce the unit of measure of an axis. Instead is recommended as a Best Practice to use the unit strings as defined by UCUM (http://unitsofmeasure.org). All examples used in this standard utilize UCUM.

          In other words: the bounding box given by the domain set must be fully enclosed in the bounding box as defined in the envelope. This requirement follows already from GML 3.2.1 Subclause 9.3.1, but is repeated here as GML does not have a uniform treatment of spatial, temporal, and other dimensions.

While the envelope can be approximate, the domain set is exact in its boundaries.

Coverages are assumed to have a 1:1 correlation between the axis names given in axis­Labels and gridLabels, i.e.: they shall relate pairwise, given by their sequence position. For example, axis­Labels= “Lat Long h date” and gridLabels={i j k l} implies a correspondence of Lat with i, Long with j, h with k, and date with l. On coverage instance level, though, this cannot be conformance tested, therefore this is not a formal requirement.

6.5    RangeType

6.5.1    Overview

The RangeType component adds a structure description and technical metadata required for an appropriate (however, application independent) understanding of a coverage. For this structure description, the SWE Common Data­Record­ is used. Optionally, interpolation directives can be added.

6.5.2    Range data type specification

Specification of the common data type all range values share is done through the Data­Record part of the coverage’s RangeType component. Atomic data types available for range values are those given by the SWE Common data type Abstract­Simple­Com­pon­ent. As a range structure contains only structure definitions, but not the values themselves (these sit in the coverage range set component), the optional Abstract­SimpleComponent component value is suppressed in coverages.

          Following  [4], omission of the value component implies that in a Data­Array there is no encoding component either.

Range values can be structured as records or arrays. Both structuring principles can be nested (and mixed) to any depth for a concrete coverage range structure definition.

Note 1       These subtypes are not allowed: DataChoice, Vector, Matrix.

Note 2       As array-valued ranges (i.e., nested arrays) can always be represented in a “flat” way by a single-level array with extra dimension(s) the use of such array-valued range types is discouraged as it adds complexity without additional value. Effectively, only DataRecord should be used.

Within a DataRecord contained in a concrete range structure, each of its record components is locally uniquely identified by the record component’s field attribute, in accordance with the “soft-typing” property introduced by SWE Common.

Example    The following XML fragment represents a valid range structure; it models the red, green, and blue channel of a Landsat scene. Pixels are defined as unsigned 8-bit quantities where 0 and 255 denote null values, representing radiance values measured in W/cm²:

<RangeType>
     <swe:DataRecord>    
      <swe:field name="red">
         <swe:Quantity definition="http://opengis.net/def/property/OGC/0/Radiance">
             <swe:uom code="W/cm2"/>
         </swe:Quantity>
     </swe:field>
     <swe:field name="green">
          <swe:Quantity definition="http://opengis.net/def/property/OGC/0/Radiance">
              <swe:uom code="W/cm2"/>
          </swe:Quantity>
     </swe:field>
     <swe:field name="blue">
         <swe:Quantity definition="http://opengis.net/def/property/OGC/0/Radiance">
             <swe:uom code="W/cm2"/>
         </swe:Quantity>
     </swe:field>
    </swe:DataRecord>    
 </RangeType>

          While SWE Common is confined to XML, a coverage can be encoded in any suitable format. Therefore, the GML examples are of informative nature only, but not constraining to this format.

6.5.3    Interpolation and continuous coverages

A continuous (grid) coverage as defined in Abstract Topic 6 [1] has values not only at the direct positions themselves, but also in between those positions – in other words, it is valid to apply interpolation to obtain values between direct positions.

Technically, a continuous grid coverage consists of a grid coverage with an interpolation method associated. Notably, often there is more than one interpolation method which can be applied meaningfully.

Example    A satellite image can be interpolated by nearest neighbor, linear, quadratic, and several more methods. A land use map, on the other hand, can only be interpolated using nearest-neighbor.

In the CIS::allowedInterpolation element an application can specify which interpolation methods are meaningful (hence, allowed) on the coverage on hand. Without such an element, any interpolation is admissible on the coverage.

The InterpolationRestriction element is meant to be interpreted as follows:

·      If no interpolationRestriction element is present, then any interpolation method is applicable to the coverage on hand; or

·      In presence of an interpolationRestriction element, only those interpolation meth­ods may be meaningfully applied whose identifiers appear in an allow­ed­Inter­pol­ation element; in case of an empty list this means that no interpolation is applicable at all.

          As selection of a particular interpolation method is at the discretion of the application processing a coverage, the interpolation behavior is not testable on the level of coverage definition and, therefore, cannot be put into a formal, testable requirement.

Example    In a XML encoding, the following constitutes a valid interpolation restriction (using OGC-defined URLs for identifying interpolation methods as defined in ISO 19123) indicating that nearest-neighbor and linear interpolation are admissible on the coverage on hand:

<InterpolationRestriction>
    <AllowedInterpolation>
      http://www.opengis.net/def/interpolation/OGC/1/nearest-neighbor
    </AllowedInterpolation>
    <AllowedInterpolation>
      http://www.opengis.net/def/interpolation/OGC/1/linear
   </AllowedInterpolation>
 </InterpolationRestriction>

6.6    RangeSet

The range set contains the actual values, each of which is associated with one direct position as defined in the domain set.

Both DomainSet and RangeType describe the coverage values given in the RangeSet. Hence, consistency must be enforced between them. The pertaining requirements are listed below.

There must be a 1:1 correspondence between direct positions and range values. Neither duplicates nor values omitted are allowed.

          For range values not known null values can be used.

          For each of the coverage subtypes the number of direct positions in the domain set is determined individually, as this varies greatly across the types.

          This applies to CIS::IrregularAxis, the CIS::Displacement, and the CIS:: TransformationModel.

The data type of all range values is the same, it is given by the range type defined through a SWE::DataRecord. In particular, in a coverage instantiating class coverage, atomic values inside a composite value shall be listed exactly in the same sequence as the range type components whereby arrays are treated like records, serialized in their natural ascending sequence.

          This last sentence is not conformance testable on this standardization target (coverage instance), therefore not expressed as a requirement. However, at service level this requirement may be testable indeed.

6.7    Metadata

The metadata component is a carrier for any kind of application dependent metadata. Hence, no requirements are imposed here.

          Implementations may impose restrictions on metadata stored (such as their sheer volume).

7.    Classgrid-regular

7.1    Overview

This class grid-regular establishes coverages with regular grid types, both referenced and non-referenced. For backwards compatibility, CIS10::GridCoverage and CIS10:: RectifiedGridCoverage are kept from GMLCOV/CIS 1.0 [5]; additionally, a new structure CIS::GeneralGridCoverage is added.

7.2    General grid coverages

CIS::GeneralGridCoverage lays foundation for the modelling of all possible grid types in CIS. While in class grid-regular only regular grids are defined, classes grid-irregular and grid-transformation extend this framework successively with additional grid types.

          Skewed and rotated grids are not modelled explicitly; they can be represented by making the grid’s CRS a concatenation of any given CRS with an Engineering CRS describing, e.g., any affine transformation of the original grid.

7.2.1    General Grid

7.2.1.1    Overview

Gridded coverages have a grid as their domain set describing the direct positions in multi-dimensional coordinate space, depending on the type of grid. In this class grid-regular, simple equidistant grids are established.

          Such a General Grid does not contain global offset vectors because these are available with the axis subtypes where appropriate. It does not contain a rotation vector as this can be modelled by concatenating the CRS with an appropriate Engineering CRS for general affine transformations.

A CIS::Axis item contains information about a particular axis: its axis name, unit of measure along the axis, and further information depending on the axis type.

Except for an index axis (which is a bare array grid), coordinates in an axis are expressed in some geodetic CRS or similar. Correspondingly, the grid limits in the CIS::Axis structure contains information about the grid boundaries in the coverage’s CRS.

In addition, the limits of the underlying array are given by the CIS::gridLimits component. This structure is optional because it is not needed when all coverage axes are of type CIS::indexAxis, in which case the boundary information is redundant.

Example    The Index CRS for a 2-D grid is http://www.opengis.net/def/crs/OGC/0/In­dex­2D. It defines axis names i and j.

In this regular-grid class, two subtypes of axes are defined, characterized by their axis type and CRS used: index and regular axis.

7.2.1.2    Index Axis

Axis type CIS::IndexAxis requires an Index CRS as its CRS, as defined in the OGC Name Type Specification for Index CRSs [9]. An Index CRS allows only integer coordinates with spacing (“resolution”) of 1, hence resembling Cartesian coordinates; therefore, there is no resolution value.

          A grid coverage containing exclusively axes of type IndexAxis technically corresponds to a CIS10::Grid­Coverage, however, with a slightly differing schema.

7.2.1.3    Regular Axis

Axis type CIS::RegularAxis has no restriction on the CRS used; as it is regularly spaced it contains the common distance, i.e.: resolution, as a part of the axis definition.

          The type is string to accommodate any potential resolution specification, such as “100” for degrees or meters, “2015-07-30T23Z” for a 1-hour duration in Gregorian calendar, and potential future calendar types.

The set of direct positions in a grid is given by the number of grid points. In the simplest case of a grid with index axes only, this is the product of the axis extents. For more complex grid types this computation gets more involved.

For some CIS::GeneralGrid g, let n_x be the number of CIS::IndexAxis elements, n_r the number of CIS::RegularAxis elements, n_i the number of CIS::Irregular axis elements, n_d the number of CIS::DisplacementAxisNest elements associated with any of the CIS::DisplacementAxis items, and n_t be the number of CIS::Trans­format­ion­Model elements associated with any of the CIS::TransformationAxis items.

Let the following positive integer numbers be defined for the number of direct position coordinates along axes or axis combinations:

• IndexAxis:
  px_a := g.a.upperBound – g.a.lowerBound + 1 for a∈ g.CIS::IndexAxis;
• RegularAxis:
  pr_a := ⌊(g.a.upperBound–g.a.lowerBound+1)/resolution⌋ (i.e., rounded down) for a∈ g.CIS::RegularAxis;
• IrregularAxis:
  pi_a := card(g.a.directPositions) for a∈ g.CIS::IrregularAxis;
• DisplacementAxis:
  pd_d := card(g.d.directPositions) for d∈ g.displacement;
• TransformationAxis:
  pt_m := card( f(g) ) for m∈ g.model where f is a function on g delivering all direct positions (such as a sensor model);

Then, the number n_p of direct positions in g is given by the product of all the above items:

n_p := Π px_a * Π pr_a * Π pi_a * Π pd_d * Π pt_m 

              _{a                  a                 a                 d                  m}

where a partial product is 1 if no such item exists._.

8.    Class grid-irregular

8.1    Overview

This class grid-irregular adds coverages of irregular axis types to the GeneralGrid­Cov­er­age introduced with class grid-regular. Figure 6 shows some common 2-D grid types tractable with class grid-irregular.

The concept builds upon axis types with individual characteristics, such as non-referenced, referenced-equidistant, referenced-nonequidistant, etc. from which CRSs and, hence, grids are assembled. All axis types can be combined freely in a grid. This model includes the GML 3.3 [3] grid types Refe­ren­ceableGridByVector and Reference­able­GridBy­Array as special cases and allows representing all grid types.

Skewed and rotated grids such as shown in Figure 6 can be represented by making the grid’s CRS a concatenation of any given CRS with an Engineering CRS describing, e.g., any affine transformation of the original grid.

8.2    Irregular independent grid axes

The first extension over regular axes consists of irregular axes where spacing along an axis can have any positive increment. Graphically, this can be represented by straight lines (but consider that existence of values between direct positions is possibly guided by interpolation restrictions). Such axes are modelled by type CIS::IrregularAxis.

Example    This allows grid representations like swath data, but also mixes like Lat/Long/t datacubes over orthorectified imagery where Lat and Long are equidistant while acquisition time, hence t, is irregular. This is schematically shown in Figure 7 (left).

8.3    Irregular correlated grid axes

The second extension consists of building axis groups, informally called "nests", within which the coordinates of direct positions are not tied to the crossing points of "straight" grid lines. Instead, coordinates can vary freely; however, the topological neighborhood relationship is retained. This leads to “displaced grids” as shown in Figure 6 far right (but consider that the curves drawn suggest a particular interpolation scheme which may or may not be allowed as per interpolation restrictions).

Not all axes in a grid need to participate in a nest, and a grid may contain several disjoint nests (although this case is unlikely).

Example    A grid displaced in Lat/Long may also contain a time axis not involved in this nest. This situation is shown in Figure 7 where the vertical axis is not involved in the displacement field. Further, a grid may contain several nests, which, however, need to be disjoint in their participating axis sets.

Class grid-irregular extends class grid-regular with further axis types, hence it requires implementation of that class.

The new axis types require storage of additional information. While for a regular axis a single resolution value is sufficient per axis, irregular grids require a sequence of direct positions along the axis (axis type CIS::IrregularAxis).

Nests require an n-D tensor, i.e., an array which stores the coordinates of each direct position for the axes participating in the nest (cf. CIS::Dis­place­mentAxisNest).

An irregular axis abandons the equidistant spacing of a regular axis. Therefore, all direct positions along such an axis must be enumerated explicitly which is achieved by replacing the lower bound / resolution / upper bound scheme by an ordered list of direct positions.

          GML 3.3 type ReferenceableGridByVector resembles the special case that all axes are irregular, but independent. In CIS, this is modelled through a CIS::GeneralGrid that has only axes of type CIS::IrregularAxis.