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.

An axis being part of a displacement grouping generalizes irregular axes further. Several axes together represent a grid where the individual direct positions of range values are situated arbitrary in space/time. The CIS::DisplacementAxisNest combines several axes to a single “nest” where the coordinates are enumerated individually for each direct pos­ition.

There­fore, the direct positions are no longer associated with individual axes, but collectively form an array (tensor) which is stored in the CIS::DisplacementAxisNest structure, associat­ed with the axes involved. The linearization scheme of this array is stated in the sequ­en­ceRule the same way as the linearization is described for the range set array.

Note 1       Not all axes of a coverage need to participate in such a displacement “nest”. For example, Lat and Long may form a surface in 3-D space whereas time axis is irregular. This is the case described in Figure 7 (right).

Note 2       The GML 3.3 type ReferenceableGridByArray resembles the special case that all axes form one nest – in other words, for each range value its direct position is explicitly listed in the domain set. This case is reflected in CIS through a CIS::GeneralGrid which has only axes of type CIS:: Dis­placement­Axis with one CIS::DisplacementAxisNest array (holding the direct position coordinates) associated with all these axes.

          “Strictly monotonic” means that the sequence of position values is either completely in increasing order, or decreasing. Neither are changes in direction is allowed, nor equality of any two positions. This is to ensure that applications will not run into singularities causing, e.g., a division by zero.
There is no corresponding monotonicity requirement on displaced axes (in the way Requirement 21 states for irregular axes). In practice, coverage generators should avoid grids that may lead to issues in coverage consumers - for example, singularities like neighboring points sharing the same coordinate could lead to a division by zero. Conversely, applications reading coverages should be ruggedized to cope with borderline cases in an appropriate way.

All combinations of axis types index and regular (from class grid-regular) as well as irregular and displaced (from class grid-irregular) are permitted. However, no two axes may have the same name (i.e., axis label).

Example    In a Lat/Long/t timeseries datacube, axes Lat and Long form a nest represented by two axes with axis name Lat and Long, resp., of type CIS::RegularAxis and one axis named t of type CIS ::IrregularAxis storing all the image acquisition timestamps.

9.    Class grid-transformation

9.1    Overview

Class grid-transformation establishes coverages with algorithmically defined grids. Currently one such transformation is defined which is based on SensorML 2.0 [5].

9.2    General

The cases currently supported by this standard – algorithmic transformation and specifically SensorML model – are defined in the Subclauses below.

9.3    Transformation

Grid definitions in the previous Clauses of this standard are defined through some well-known principle and (comparatively simple) computation methods. In the most general case, however, this is not the case, and only some special-built code – here called a “transformation” – with some particular variable instantiation can determine the direct positions of the grid. A special case of a transformation is provided by SensorML 2.0 [5], in CIS modelled through coverage type CIS::SensorModelCoverage.

          It is recommended to ensure that transformations are invertible (i.e., an inverse transformation exists) in order to support the determination of the associated grid location of a given direct position.

9.4    SensorML grid

Aside from the general definition, this standard supports one special case of such a transformation as defined by SensorML 2.0 [5]. Such a sensor model involves two inputs: a sensor model description containing free variables plus a separate set of variable instantiations (Table 17). As the sensor model defines the grid and its direct positions, this transformation effectively represents the coverage domain set.

The CIS::TransformationBySensorModel of the SensorML grid inherits attributes uomLabels and axisLabels that will be a directive to the sensor model software for the computed output geo locations.  In general, these attributes will have no effect whatever on sensor model calculations except for the last stage when the output geo locations will be trans­formed from the native units and CRS of the software to the specified units and CRS of the CIS::TransformationBySensorModel.

Example 1  The following XML fragment defines the DomainSet of a frame camera sensor image modelled as a CIS::TransformationBySensorModel.

<DomainSet>
     <GeneralGrid srsName="http://www.opengis.net/def/crs/EPSG/0/4326" 
             axisLabels="Lat Long">
         <GridLimits srsName=
                 "http://www.opengis.net/def/crs/OGC/0/Index2D" 
                 axisLabels="i j">
             <IndexAxis axisLabel="i" lowerBound="0" upperBound="1919"/>
             <IndexAxis axisLabel="j" lowerBound="0" upperBound="1079"/>
         </GridLimits> 
         <TransformationBySensorModel
                 uomLabels="deg deg" axisLabels="Lat Long">
             <SensorModel xlink:href=
                 "http://www.sensorml.com/csmFrame.html"/>
             <SensorInstance xlink:href=
                 "http://www.sensorml.com/myHDCamera.html"/>
         </TransformationBySensorModel>
     </GeneralGrid>
 </DomainSet>

Example 2  The following SensorML 2.0 defines parameters of a 2D electro-optical grid of a frame camera sensor, as part of a sensor model description referenced in the SensorModel subelement.

<SensorModel>
     <swe:field name="pixelGrid">
         <swe:DataRecord>
             <swe:label>Pixel Grid Characteristics</swe:label>
             <swe:field name="numberOfRows">
                 <swe:Count definition=
                       "http://sensorml.com/ont/csm/property/NROWS">
                     <swe:label>Number of Rows</swe:label>
                 </swe:Count>
             </swe:field>
             <swe:field name="numberOfColumns">
                <swe:Count definition=
                       "http://sensorml.com/ont/csm/property/NCOLS">
                     <swe:label>Number of Columns</swe:label>
                 </swe:Count>
             </swe:field>
             <swe:field name="rowSpacing">
                 <swe:Quantity definition=
                      "http://sensorml.com/ont/csm/property/ROW_SPACING">
                     <swe:label>Row Spacing</swe:label>
                     <swe:uom code="mm"/>
                 </swe:Quantity>
             </swe:field>
             <swe:field name="columnSpacing">
                 <swe:Quantity definition=
                      "http://sensorml.com/ont/csm/property/COL_SPACING">
                     <swe:label>Column Spacing</swe:label>
                     <swe:uom code="mm"/>
                 </swe:Quantity>
             </swe:field>
         </swe:DataRecord>
     </swe:field> 
</sensorModel>

Example 3  The following SensorML 2.0 fragment sets parameters of a 2D electro-optical grid of a frame camera sensor, as part of a sensor instance description referenced in the sensorInstance sub-ele­ment of CIS::TransformationBySensorModel, coherent with the parameter definitions of the previous example.

<sensorInstance>
     <sml:configuration>
         <sml:Settings>
             <sml:setValue ref="parameters/csm/pixelGrid/numberOfRows">
                 1080
             </sml:setValue>
             <sml:setValue ref="parameters/csm/pixelGrid/numberOfColumns">
                 1920
             </sml:setValue>
             <sml:setValue ref="parameters/csm/pixelGrid/rowSpacing">
                 0.0074
             </sml:setValue>
             <sml:setValue ref="parameters/csm/pixelGrid/columnSpacing">
                 0.0074
             </sml:setValue>
         </sml:Settings>
     </sml:configuration>
 <sensorInstance>

Example 4  The following SensorML 2.0 snippet defines a 2D grid of a sensor model image through a list of inputs con­sistent with the sensorModel and sensorInstance sub­elements above.

<sml:inputs>
   <sml:InputList>
     <sml:input name="pixelGridCoordinates">
       <swe:Vector referenceFrame=
             "http://www.opengis.net/def/crs/OGC/0/IndexCRS2D">
         <swe:coordinate name="r">
           <swe:Quantity definition=
               "http://sensorml.com/def/property/ImageRowPosition">
             <swe:label>Row Position</swe:label>
               <swe:uom xlink:href=
                   "http://sensorml.com/def/property/pixel"/>
           </swe:Quantity>
         </swe:coordinate>
         <swe:coordinate name="c">
           <swe:Quantity definition=
               "http://sensorml.com/def/property/ImageColumnPosition">
             <swe:label>Column Position</swe:label>
               <swe:uom xlink:href=
                   "http://sensorml.com/def/property/pixel"/>
           </swe:Quantity>
         </swe:coordinate>
       </swe:Vector>
     </sml:input>
   </sml:InputList>
 </sml:inputs>

10.    Class discrete-pointcloud

Class discrete-pointcloud defines coverages which represent sets of multi-dimensional points at arbitrary positions.

The domain set of a discrete coverage consists of spatial and/or temporal objects, finite in number. The range set is comprised of a finite number of attribute values each of which is associated to every direct position within any single spatiotemporal object in the domain. In other words, the range values are constant on each spatiotemporal object in the domain. This coverage function maps each element from the coverage domain to an element in its range.

          While this definition is based on GML it does not preclude a GML encoding (through class gml-coverage); the same structures may be represented in any other suitable format (using class other-format-coverage).

In a MultiPointCoverage the domain set is a GM_MultiPoint, that is a collection of arbitrarily distributed geometric points.

11.    Class discrete-mesh

This class discrete-mesh establishes those discrete coverages which have a non-zero topological dimension, thereby extending class discrete-pointcloud. As such, it defines coverages consisting of curve, surface, and solid bundles, resp.

          While this definition is based on the conceptual model of GML it does not preclude a GML encoding (through class gml-coverage); the same structures may be represented in any other suitable format (using class other-format-coverage).

12.    Class gml-coverage

12.1    Overview

Class gml-coverage establishes how coverages, as defined in this standard, are represented in the GML encoding format.

          To make the GML schema of CIS more lightweight and self-contained, several GML definitions have been migrated into the CIS schema, at the same time simplifying these very general definitions for the particular use with coverages. Further, highly repetitive elements have been given particularly short to keep file size low. Therefore, strictly speaking the GML conformance class of CIS 1.1 is not a GML Application Profile anymore in the sense as defined in the GML standard.

The following convention has been adopted throughout CIS 1.1 for gml-coverage:

• Element and type names are in camel case with first letter capitalized
• Attribute names are in camel case with first letter lowercase.

          This is a change over the corresponding schema definitions in GML 3.2.1 and GMLCOV/CIS 1.0 (which adheres to GML 3.2.1) where both lower and upper case can appear in element names, depending on their role in the schema. The reason for this change is to achieve coherent upper/lower case conventions across the XML, JSON, and RDF encoding of CIS as well as to simplify XML handling towards common XML Schema practices.

Note 1       The XML Schema contained in this standard does not copy the abstract class definitions of Figure 2; rather, it deviates by not defining namespaces for GMLCOV/CIS 1.0 and GML 3.3. This allows applications which utilize only CIS 1.1 coverages to avoid pulling massive additional GML Schema files during validation.

Note 2       Coverage identifiers, as per GML are represented as gml:id attributes of XML type NCName which has constraints in the characters allowed. Therefore, naming of coverages is constrained, too, to such identifiers when using GML encoding.

This GML encoding is prepared for split representations where different parts of a coverage reside in different objects (such as files or databases), individually encoded. For example, domain set, range type, and range set each can independently be given by a URL; the same is possible for metadata – although it does not contain a file reference explicitly, its <any> definition allows for a URL as well.

Each range value is either atomic or composed from atomic values, each individually enclosed in an element.

          Such values will normally be numbers, encoded dates (as per ISO 8601), etc. The exact type definition for each range value component is governed by the range type.

Example    The XML Schema being part of this specification contains several examples for different coverages encoded in XML.

References in GML are indicated through type xs:anyURI which specifies general syntax and semantics of URIs up to, and excluding, resolution of the fragment part (i.e., the URI part starting with a number sign, “#”). Fragment resolution is specified an­alogously to HTML:

Example    The following XML snippet demonstrates a possible way to incorporate a CRS definition within the coverage document:

<GeneralGridCoverage>
   <DomainSet>
     <GeneralGrid srsName="#myCrs"/>
     ...   </DomainSet>
   ...   <Metadata>
     <myLocalCrs gml:id="myCrs">
       here goes my CRS definition in GML, WKT, or otherwise
     </myLocalCrs>
   </Metadata>
 </GeneralGridCoverage>

12.2    Coverage representation

Coverages can be encoded in any suitable format. One such format is established in GML 3.2.1 [2] stating that domain set items are mapped to range set items in XML document order or file sequence order, respectively.

Note          As this statement above is not conformance testable no corresponding normative requirement is established.

13.    Class json-coverage

Class json-coverage establishes how coverages, as defined in this standard, are represented in the JSON encoding format.

Example    The following JSON snippet is an example of a JSON encoded coverage.

{    
	"type": "CoverageByDomainAndRangeType",
	"DomainSet":{
	        "type": "DomainSetType",
	        "generalGrid":{
           "type": "GeneralGridCoverageType",
	           "srsName":              "http://www.opengis.net/def/crs/OGC/0/Index2D",
	           "axisLabels": ["i",
	 "j"],
	           "axis": [{
               "type": "IndexAxisType",
	              "axisLabel": "i",
	              "lowerBound": 0,
	              "upperBound": 2
           }, {
              "type": "IndexAxisType",
	              "axisLabel": "j",
	              "lowerBound": 0,
	              "upperBound": 2
           }]
        }
    },
	    "RangeSet": {
        "type": "RangeSetType",
	        "dataBlock": {
           "type": "VDataBlockType",
	            "values": [1,2,3,4,5,6,7,8,9]
        }
    },
    "RangeType": {
         "type": "DataRecordType",
	       "field":[{
	            "type": "QuantityType",
	           "definition": "ogcType:unsignedInt",
	           "uom": {
	              "type": "UnitReference",
	              "code": "10^0"
           }
        }]
    }
   }
 

          The JSON Schema being part of this specification has been used to validate the examples for different coverages encoded in JSON also provided.

14.    Class rdf-coverage

Class rdf-coverage establishes how to represent coverages as Link­ed Data in RDF. This is done by providing a mapping between the JSON encoding and the RDF triples model using JSON-LD which allows that a JSON file with some additional content, defined in the W3C JSON-LD syntax [20], can be converted into RDF notation automatically using the W3C JSON-LD API [21].

          One implementation of this API is provided in the JSON-LD Playground (http://json-ld.org/playground/).

          This conformance class has a dependency on the json-coverage only if the RDF encoding is derived from JSON-LD. The dependency on this class is not normative as coverage instances of this class can be RDF encoded without any previous use of JSON or JSON-LD to derive the class.
Although this conformance class refers to class json-coverage it is not normatively dependent on this class as coverage instances of this class do not implement the JSON encoding, but RDF. Subsequent requirements detail the structure of a hypothetical JSON-LD coverage leading to the RDF coverage defined.

          Coverage components which are not in the above list of objects require personalized JSON-LD @context objects embedded or linked to allow mapping to the RDF models. One example for this is the metadata object.

          The JSON-LD @context documents being part of this specification have been used to validate that examples of the different coverages encoded in JSON-LD also provided can be successfully converted to RDF.

Example    The sample JSON code being part of this specification contains the necessary @context objects that can be linked or embedded in other JSON instances wanting to be conformant to this standard.

          This @context object is not included as a separated JSON-LD @context document because id namespaces are commonly responsibility of the data provider and should be provided by them. The provides can decide to provide a JSON-LD  @context document to include by reference to several coverages or can embed this definition directly in the coverage.

          Large lists of values or coordinates embedded in the document are likely to produce excessively large RDF encodings. Therefore, instead of including them in the JSON file directly it can be advantageous to store such parts in separate files and reference these instead.

Example 1  Some of the sample JSON files being part of this specification have the values embedded (in places where potentially large lists will be used in practice) instead of being factored out into separated files. This is for didactic purpose only, these values are not be mapped to RDF when using the JSON-LD @context documents provided.

Example 2  The following JSON snippet illustrates an example of a JSON-LD encoded coverage with links to the @context document provided by this standard.

{    "@context": ["http://schemas.opengis.net/cis/1.1/json/coverage-context.json",
         {"examples": "http://www.opengis.net/cis/1.1/examples/"}],
    "type": "CoverageByDomainAndRangeType",
    "id": "examples:CIS_05_2D",
    "DomainSet":{        
	"@context": 
		"http://schemas.opengis.net/cis/1.1/json/domainset-context.json",
        "type": "DomainSetType",
        "id": "examples:CIS_DS_05_2D",
        "generalGrid":{           "type": "GeneralGridCoverageType",
           "id": "examples:CIS_DS_GG_05_2D",
           "srsName": "http://www.opengis.net/def/crs/OGC/0/Index2D",
           "axisLabels": ["i",
 "j"],
           "axis": [{               "type": "IndexAxisType",
              "id": "examples:CIS_DS_GG_I_05_2D",
              "axisLabel": "i",
              "lowerBound": 0,
              "upperBound": 2
           }, {
              "type": "IndexAxisType",
              "id": "examples:CIS_DS_GG_J_05_2D",
              "axisLabel": "j",
              "lowerBound": 0,
              "upperBound": 2
           }]
        }
    },
    "RangeSet": {       
	 "@context": 
		"http://schemas.opengis.net/cis/1.1/json/rangeset-context.json",
        "type": "RangeSetType",
        "id": "examples:CIS_RS_05_2D",
        "fileReference": "http://myserver.com/fileref.tiff"    },
    "RangeType": {        
	 "@context": 
		"http://schemas.opengis.net/cis/1.1/json/rangetype-context.json",
        "type": "DataRecordType",
        "id": "examples:CIS_RT_05_2D",
        "field":[{            "type": "QuantityType",
           "id": "examples:CIS_RT_F_05_2D",
           "definition": "ogcType:unsignedInt",
           "uom": {              "type": "UnitReference",
              "id": "examples:CIS_RT_F_UOM_05_2D",
              "code": "10^0"
           }
        }]
    }
 }

Example 3  The following RDF triples representation corresponds to the JSON-LD encoded coverage  listed above:

<http://www.opengis.net/cis/1.1/examples/CIS_05_2D> 
	<http://www.w3.org/1999/02/22-rdf-syntax-ns#type> 
	<http://www.opengis.net/cis/1.1/CoverageByDomainAndRangeType> .
 
<http://www.opengis.net/cis/1.1/examples/CIS_05_2D> 
	<http://www.opengis.net/cis/1.1/DomainSet> 
	<http://www.opengis.net/cis/1.1/examples/CIS_DS_05_2D> .
<http://www.opengis.net/cis/1.1/examples/CIS_DS_05_2D> 
	<http://www.opengis.net/cis/1.1/generalGrid> 
	<http://www.opengis.net/cis/1.1/examples/CIS_DS_GG_05_2D> .
<http://www.opengis.net/cis/1.1/examples/CIS_DS_05_2D> 
	<http://www.w3.org/1999/02/22-rdf-syntax-ns#type> 
	<http://www.opengis.net/cis/1.1/DomainSetType> .
<http://www.opengis.net/cis/1.1/examples/CIS_DS_GG_05_2D> 
	<http://www.opengis.net/cis/1.1/axis> 
	<http://www.opengis.net/cis/1.1/examples/CIS_DS_GG_I_05_2D> .
<http://www.opengis.net/cis/1.1/examples/CIS_DS_GG_05_2D> 
	<http://www.opengis.net/cis/1.1/axis> 
	<http://www.opengis.net/cis/1.1/examples/CIS_DS_GG_J_05_2D> .
<http://www.opengis.net/cis/1.1/examples/CIS_DS_GG_05_2D> 
	<http://www.opengis.net/cis/1.1/axisLabels> 
	<http://www.opengis.net/cis/1.1/axisLabels0> .
<http://www.opengis.net/cis/1.1/axisLabels0> 
	<http://www.w3.org/1999/02/22-rdf-syntax-ns#first> "i" .
<http://www.opengis.net/cis/1.1/axisLabels0> 
	<http://www.w3.org/1999/02/22-rdf-syntax-ns#rest> 
	<http://www.opengis.net/cis/1.1/axisLabels1> .
<http://www.opengis.net/cis/1.1/axisLabels1> 
	<http://www.w3.org/1999/02/22-rdf-syntax-ns#first> "j" .
<http://www.opengis.net/cis/1.1/axisLabels1> 
	<http://www.w3.org/1999/02/22-rdf-syntax-ns#rest> 
	<http://www.w3.org/1999/02/22-rdf-syntax-ns#nil> .
<http://www.opengis.net/cis/1.1/examples/CIS_DS_GG_05_2D> 
	<http://www.opengis.net/cis/1.1/srsName> 
	<http://www.opengis.net/def/crs/OGC/0/Index2D> .
<http://www.opengis.net/cis/1.1/examples/CIS_DS_GG_05_2D> 
	<http://www.w3.org/1999/02/22-rdf-syntax-ns#type> 
	<http://www.opengis.net/cis/1.1/GeneralGridCoverageType> .
<http://www.opengis.net/cis/1.1/examples/CIS_DS_GG_I_05_2D> 
	<http://www.opengis.net/cis/1.1/axisLabel> "i" .
<http://www.opengis.net/cis/1.1/examples/CIS_DS_GG_I_05_2D> 
	<http://www.opengis.net/cis/1.1/lowerBound> 
	"0"^^<http://www.w3.org/2001/XMLSchema#integer> .
<http://www.opengis.net/cis/1.1/examples/CIS_DS_GG_I_05_2D> 
	<http://www.opengis.net/cis/1.1/upperBound> 
	"2"^^<http://www.w3.org/2001/XMLSchema#integer> .
<http://www.opengis.net/cis/1.1/examples/CIS_DS_GG_I_05_2D> 
	<http://www.w3.org/1999/02/22-rdf-syntax-ns#type> 
	<http://www.opengis.net/cis/1.1/IndexAxisType> .
<http://www.opengis.net/cis/1.1/examples/CIS_DS_GG_J_05_2D> 
	<http://www.opengis.net/cis/1.1/axisLabel> "j" .
<http://www.opengis.net/cis/1.1/examples/CIS_DS_GG_J_05_2D> 
	<http://www.opengis.net/cis/1.1/lowerBound> 
	"0"^^<http://www.w3.org/2001/XMLSchema#integer> .
<http://www.opengis.net/cis/1.1/examples/CIS_DS_GG_J_05_2D> 
	<http://www.opengis.net/cis/1.1/upperBound> 
	"2"^^<http://www.w3.org/2001/XMLSchema#integer> .
<http://www.opengis.net/cis/1.1/examples/CIS_DS_GG_J_05_2D> 
	<http://www.w3.org/1999/02/22-rdf-syntax-ns#type> 
	<http://www.opengis.net/cis/1.1/IndexAxisType> .
 
<http://www.opengis.net/cis/1.1/examples/CIS_05_2D> 
	<http://www.opengis.net/cis/1.1/RangeSet> 
	<http://www.opengis.net/cis/1.1/examples/CIS_RS_05_2D> .
<http://www.opengis.net/cis/1.1/examples/CIS_RS_05_2D> 
	<http://www.w3.org/1999/02/22-rdf-syntax-ns#type> 
	<http://www.opengis.net/cis/1.1/RangeSetRefType> .
<http://www.opengis.net/cis/1.1/examples/CIS_RS_DB_05_2D> 
	<http://www.opengis.net/cis/1.1/fileReference> 
	<http://myserver.com/fileref.tiff> .
 
<http://www.opengis.net/cis/1.1/examples/CIS_05_2D> 
	<http://www.opengis.net/cis/1.1/RangeType> 
	<http://www.opengis.net/cis/1.1/examples/CIS_RT_05_2D> .
<http://www.opengis.net/cis/1.1/examples/CIS_RT_05_2D> 
	<http://www.opengis.net/swe/2.0/field> 
	<http://www.opengis.net/cis/1.1/examples/CIS_RT_F_05_2D> .
<http://www.opengis.net/cis/1.1/examples/CIS_RT_05_2D> 
	<http://www.w3.org/1999/02/22-rdf-syntax-ns#type> 
	<http://www.opengis.net/swe/2.0/DataRecordType> .
<http://www.opengis.net/cis/1.1/examples/CIS_RT_F_05_2D> 
	<http://www.opengis.net/swe/2.0/definition> 
	<http://www.opengis.net/def/dataType/OGC/0/unsignedInt> .
<http://www.opengis.net/cis/1.1/examples/CIS_RT_F_05_2D> 
	<http://www.opengis.net/swe/2.0/uom> 
	<http://www.opengis.net/cis/1.1/examples/CIS_RT_F_UOM_05_2D> .
<http://www.opengis.net/cis/1.1/examples/CIS_RT_F_05_2D> 
	<http://www.w3.org/1999/02/22-rdf-syntax-ns#type> 
	<http://www.opengis.net/swe/2.0/QuantityType> .
<http://www.opengis.net/cis/1.1/examples/CIS_RT_F_UOM_05_2D> 
	<http://www.opengis.net/swe/2.0/code> "10^0" .
<http://www.opengis.net/cis/1.1/examples/CIS_RT_F_UOM_05_2D> 
	<http://www.w3.org/1999/02/22-rdf-syntax-ns#type> 
	<http://www.opengis.net/swe/2.0/UnitReference> .

15.    Class other-format-coverage

Class other-format-coverage establishes how coverages are represented in encoding formats other than those defined in this standard.

          Such formats may be able to encode only parts of a coverage (i.e., they are “informationally incomplete”), and they may be able to encode only specific categories of coverages (such as raster images, but not point clouds).

16.    Class multipart-coverage

16.1    Overview

Class multipart-coverage establishes how coverages can be packaged into multiple files, meaning that the coverage document (henceforth referred to as the “first part”) has one or more components shifted out into separate documents (henceforth called “further parts”). To maintain connection between the parts, the first part references all other parts through URLs (which may be local). Packaging can be done through any appropriate container format. Additionally, parts can be stored outside the package, referenced by URLs.

          Among the suitable container formats are multipart MIME [4], GMLJP2, zip, and tar. Out of those, MIME is normatively defined here.

Such a splitting is particularly useful for the range set so as to allow a different, possibly more efficient encoding of this (typically) bulk of information. However, with the same argument other parts of the coverage (such as a large domain set with displaced axes) can be shifted into further parts as well.

To achieve a complete representation of the coverage, the encoding used in the first part must be “informationally complete,” i.e.: able to hold the complete coverage information. Further, it must be allow expression of references (which replace the substructure – such as the range set – to be shifted into a separate part). Notably, the format used in the further parts does not need to be informationally complete with respect to coverage metadata; however, it must be able to represent the values factored out of the first-part document.

          Among the list of suitable formats for the first part are GML and JSON. Image/data formats like GeoTIFF and NetCDF are suitable formats for the further parts.

Note 1       The MIME type identifier of GML, for example, is “application/gml+xml”.

Note 2       In GMLCOV/CIS 1.0 a ContentDisposition parameter ofvalue “inline” was required. This is not required any more in CIS 1.1.

References used in coverage parts follow common URI standards for syntax [18] and semantics [12].

16.2    Root part

The root part of a multipart coverage consists of the top-level structure of the coverage. Each container format needs to individually determine how this root part is represented.

Example    In Multipart / MIME, this is the first item in the stream. In a zip file, it might be a manifest file. Each format needs establish unambiguous conventions, such as a particular file name in a zip archive.

Example    In a GML encoded coverage, a reference can be expressed through a fileReference element.

          Each part of the message can be encoded in different formats individually and independently.

Note 1   Generally, syntax and semantics of the reference may depend on the environments in which the coverage cont­aining the reference, on the one hand, and the item referenced, on the other hand, reside: in a multipart MIME message, this will be cid identifiers; in a zip file, identification will be done through file names and paths relative to the zip directory root; this hierarchical scheme would allow relative references. In a GMLJP2 file, identification will be done through XML identifiers, i.e., locally unique gml:id attributes. If keeping a sandboxed environment is important, e.g., for security reasons, the W3C app: URI scheme [13] might be used.

Note 2       A reference may be temporarily or permanently unresolvable. In case of an unresolvable reference, the coverage may still be reconstructable through other means – for example, treatment of CRSs given by some well-known URI may be hardwired in an application handling coverages.

16.3    Further parts

The root part may, instead of containing coverage constituents verbatim, shift such constituents into subsequent parts of the multipart document and reference them.

          In GMLCOV/CIS 1.0, only one extra part was foreseen exclusively for the range set. Starting with CIS 1.1 more than one coverage component can be extracted into a separate part. Besides the (often large) range set, another candidate for a separate part is the domain set in a coverage with displaced axes, as such a domain set may become just as large as the range set. In a Discrete Coverage, the domain set typically is even larger than the range set.

Example    The following  MIME message represents a valid multipart coverage structure with the root part encoded in GML and the second part encoded in TIFF (assuming all “…” substituted by proper XML and with a proper TIFF stream instead of “…binary TIFF data…”):

Content-Type: Multipart/Related; boundary=cis;
        start=“GML-Part”
        type=“application/gml+xml”
 
–cis
Content-type: application/gml+xml
Content-ID: GML-Part
 
<?xml version=“1.0” encoding=“UTF-8”?>
…GML data…
–cis
Content-Type: image/tiff
Content-Description: coverage data
Content-Transfer-Encoding: binary
Content-ID: grey.tif
Content-Disposition: inline

 …binary TIFF data…
–cis–

17.    Class coverage-partitioning

17.1    Overview

This class coverage-partitioning establishes an alternative representation for coverages through partitioning into sub-coverages or direct enumeration of position/value pairs.

17.2    Partitioning

With the coverage extensions provided by this class coverages can be composed from other coverages which are either copied in directly (“domain-and-range” variant), or referenced by coverage id (“partitioning” variant), or can contain single values per direct position (“position/value pair” variant, sometimes also called “geometry/value pair” or “interleaved”).

Coverages embedded (“sub-coverages”) can be of the same or lower dimension than the coverage embedding them (“super-coverage”). The part­ition element in the super-coverage, acting as a connection between sub- and super-cov­er­age, contains an envelope element de­termining the sub-coverage’s position relative to the super-coverage. A coverage can be part of several partitioned coverages simultaneously, thereby allowing shared regions. A partitioned coverage can itself be part of another partitioned coverage, there­by allowing trees of coverages to be built recursively.

In the position/value pair approach, single range values (which may be composite, such as RGB pixel values) are listed together with their direct position.

All of the above variants can be combined freely within a single coverage as per this standard. However, an implementation may constrain the partitioning choices available, such as to “partitioning only along time axis” or “only equi-sized sub-coverages”. Further, it may support selection of partitioned and “geometry/value pair” representation.

The partitioning mechanism effectively establishes a nesting of coverages. This nesting must be acyclic, i.e., a coverage cannot contain itself.

All “sub-coverages” participating in a partitioned coverage must lie inside the super-cover­age and additionally must fulfill homogeneity criteria to ensure that the resulting structure ad­heres to the definition of a coverage, as specified in the following Subclauses.

A coverage can act as sub-coverage in more than one coverages.

Sub-coverages can be stored directly as the value of coverage, or they can be given as some reference, such as coverage id or a URL.

          Support for these alternatives may vary across data format encodings. Further, as this is a normative requirement which a server must fulfill an implementation possibly will restrict the options for referencing coverages to those ones where it can control this acyclicity requirement.

17.3    CRS and partition envelope constraints

The sub-coverage CRS must allow that the coverage data can be embedded in the super-coverage referencing it.

          This definition enforces an identical axis order among those axes present in both the sub- and super-coverage CRSs.

Example    A timeseries datacube with CRS axes Lat/Long/t can contain sub-coverages whose CRS axes are given by Lat/Long, but not by Long/Lat. A datacube with axis order t/Lat/Long likewise can contain sub-coverages with a Lat/Long CRS.

Lower-dimensional sub-coverages are embedded as slices of thickness one into the super-coverage.

          This allows to “lift”coverage parts into higher-dimensional spaces in the super-coverage, such as embedding a 2-D Lat/Long timeslice into a 3-D Lat/Long/time datacube.

The CIS::partitionEnvelope element does not need to repeat coordinate axis values of the sub-coverage if they are identical in the context of the super-coverage.

          Axis identification and sequence is unambiguous even when axes are left out because part­itionEnvelope coordinates are expressed in terms of the super-coverages CRS which defines all axes and their sequence.

17.4    Domain set constraints

The sub-coverage domain sets, as well as single direct positions, must be non-overlapping (considering all axes plus the range components) and properly contained in the super-cover­age; missing boundary values are represented as a null value.

          Such null values can be used whenever the actual extent of the super-coverage is not known in the super-coverage itself, such as in timeseries where further timeslices can be appended at any time. The representation of such a null value is defined in the concrete encodings.

Example    Band-interleaved (BIL) representation can be achieved through multiple sub-coverages all registered to the same extent, but each one adding an individual band.

Note 1       Such “undefined areas” can only occur with coverages containing partitions (in a domain / range representation there must always exist a value for each direct position). This rule makes sure that “null values” exist when needed.

Note 2       Such “default” null values can differ among direct positions, an implementation is free to choose values non-deterministically. It is good practice, though, to use a single value whenever possible.

17.5    Range type constraints

Sub- and super-coverage must have compatible range types – either identical ones, or partitions contribute parts of the full super-coverage range component record.

          Sub-coverage bands are visible in the super-coverage under the name indicated in the range type translation list, which obviously must not lead to name clashes in the super-coverage (i.e., range component names still have to be pairwise distinct). Further, from the super-coverage perspective, all range components “imported” must adhere to the same range type definition to not violate the basic definition of range type coherence in a coverage.

Example    Band-interleaved storage of satellite imagery, as well as variables in climate model output can be accomplished this way: single bands, or combinations of bands, can go into separate sub-coverages which are linked together through a super-coverage.

If the partitions altogether are not commensurate to the complete range type structure then the range components not covered are equivalent to some null value (which must be defined in this case).

Example 1  Consider an RGB coverage where the color bands are factored out into partitions. Assume that there are only partitions for the red and green, but not for the blue band. In this case, the range type definition of the RGB coverage must provide a null value for the blue band so that an equivalent “flat” coverage can be constructed which contains null values in all direct positions for the missing blue band.

Example 2  Band interleaving combined with spatial partitioning (such as in mosaics) may lead to small islands of null values. For each of them, a proper null value definition must exist allowing an implementation to interpret the missing value as one of these null values.

18.    Class container

This class container, which is free-standing and not dependent on class coverage, establishes a general data type and format independent information unit. Such units are particularly useful when aggregating homogeneous information (such as several coverages) or heterogeneous information (such as coverages annotated with other coverages, features, and metadata).

          Container objects can be conveniently queried by XPath when encoded in XML, and by similar ex­ist­ing techniques when encoded in some other format like JSON. This notwithstanding, there is no restriction on the encoding – individual components of an object may be encoded individually in different formats.

The definition of the target structure, CIS::Object, is tentatively as general as ever possible. Applications will derive bespoke instantiable subclasses from this abstract class.

          This container approach is intended to align with related standards on heterogeneous data and services on them. Information from such objects can be extracted, for example, through the XPath-based retrieval defined in the OGC Web Information Service (WIS) [10].

Annex : Abstract Test Suite (Normative)

This Annex specifies an Abstract Test Suite which shall be passed in completeness by any implementation claiming conformance with this Application Schema.

The test approach conceptually consists of two steps:

• Transcode the coverage from its original format into one of the formats directly addressed by this standard[4], following the mapping rules defined for the particular original format on hand[5].
• Perform all conformance tests on this transcoded coverage representation. Tests fail/succeed if they fail/succeed, resp., on this transcoded representation.

A concrete test implementation may choose a different strategy (may be for efficiency reasons) as long as the tests behave as indicated in this Abstract Test Suite.

A.1  Conformance Test Class: coverage

A.2  Conformance Test Class: grid-regular

A.3  Conformance Test Class: grid-irregular

A.4  Conformance Test Class: grid-transformation

A.5  Conformance Test Class: discrete-pointcloud

A.6  Conformance Test Class: discrete-mesh

A.7  Conformance Test Class: gml-coverage

A.8  Conformance Test Class: json-coverage

A.9  Conformance Test Class: rdf-coverage

A.10 Conformance Test Class: other-format-coverage

A.11  Conformance Test Class: multipart-coverage

A.12  Conformance Test Class: coverage-partitioning

A.13  Conformance Test Class: container

Annex : Revision History (Non-Normative)

Annex : Complete CIS::AbstractCoverage UML diagram collection (Non-Normative)

This Annex summarizes the UML diagrams presented in the normative part. For the reader’s convenience, they are split into coverage types, coverage structure, and grid coverages.

Annex : Relation to Other Standards (Non-Normative)

D.1   Abstract Topic 6 / ISO 19123

ISO 19123 (which is identical to OGC Abstract Topic 6 [1]) defines an abstract coverage model. This model tentatively is general and abstract; as a consequence, different and incompatible coverage implementations are possible. The OGC Coverage Implementation Schema, therefore, complements it with a concrete coverage structure definition which can be conformance tested and allows for interoperable implementations.

The following table correlates ISO 19123 and GMLCOV/CIS 1.0 and CIS 1.1 coverage types. Note that continuous coverages are modelled separately in ISO 19123 whereas in CIS they consist of discrete coverages together with some interpolation method; typically, this will be specified in the interpolation method associated with the range type (starting CIS 1.1); alternatively, the coverage function can express interpolation (starting GMLCOV/CIS 1.0).

Those coverage types which represent point clouds and general meshes (i.e., all non-gridded coverages) are consistent with the modelling introduced by GML 3.2.1, Consequently, all corresponding ISO 19123 types are implemented by CIS types MultiPointCoverage, MultiCurveCoverage, MultiSurfaceCoverage, and MultiSolidCoverage.

D.2   GML 3.2.1

In GML 3.2.1 [2], all coverage types are derived from the abstract Coverage data type containing a DomainSet and a RangeSet component. The OGC coverage implementation schema, CIS, extends this with two additional components, a mandatory RangeType and optional metadata, an extensible slot for individual, application-specific metadata structures.

The GMLCOV/CIS 1.0 changes which apply over GML 3.2.1 are detailed in [5].

The following CIS 1.1 changes apply over GML 3.2.1 [2]:

• There are several extra concepts not present in GML 3.2.1, ranging from model (grid definition by axis rather than by grid type, SensorML domains, etc.) over representation (partitioning and geometry/value pairs) to encoding (addition of JSON and RDF).
• Coordinates are not required to be numeric only, but can also contain strings such as ISO 8601 date/timestamps or categorical values. This is instrumental for general multi-dimensional coverages.
• A point cloud coverage type, MultiPointCoverage, is provided which semantically is equivalent to GML 3.2.1 and GMLCOV/CIS 1.0, but allows string coordinates as described above.

  GMLCOV/CIS 1.0 coverage types MultiCurveCoverage, MultiSurface­Cover­age, and MultiSolidCoverage are not addressed by CIS 1.1, the original GMLCOV/CIS 1.0 definitions remain valid.

D.3   GML 3.3

GML 3.3 [3] adds several grid types to GML 3.2.1. However, given the OGC modular specification rules these are not automatically available for GMLCOV/CIS 1.0. Further, these grid types resemble only special cases omitting, for example, combinations of regular and irregular axes in the same datacube. The CIS 1.1 model encompasses and generalizes GML 3.3. In the CIS 1.1 XML encoding, the GML 3.3 schema is included.

D.4   SWE Common

The RangeType element of a coverage describes the coverage’s range set data structure (see Clause 6). This range value structure description is adopting the SWE Common [4] Data­Record.

D.5   Further Standards

The OGC standards WaterML 2 [OGC 10-126r4], TimeseriesML 1 [OGC 15-043rX], and OM-JSON [OGC 15-100r1] represent domain-specific standards for which the OGC Coverage Implementation Schema establishes a domain-neutral basic data structure which can be used whenever a coverage-like structure occurs; such standards, while retaining interoperability by using the common coverage model, will likely extend coverages with domain specific metadata, such as done in TimerseriesML.

[1] www.opengeospatial.org/cite

[2] {req#} denotes the requirement number in decimal notation, without leading zeroes.

[3] In the standards numbering scheme x.y.z, x is called major release number, y minor, and z corrigendum. Revisions of a standard where only the minor release number changes are backwards compatible. A major release number change signals possibly incompatible changes over the previous edition.

[4] Currently, this is GML; in future, JSON will be added.

[5] At the time of this writing, such OGC coverage mapping standards exist for GeoTIFF, GMLJP2, and NetCDF; GRIB is under construction.

[6] In case of a GML encoding, the corresponding Schematron rule provided with the XML Schema checks this.