Open Geospatial Consortium Interface:
Web Coverage Processing Service (WCPS)

1 Scope

This document defines a protocol-independent language for retrieving and processing geospatial coverage datacubes. Version 1.1 keeps version 1.0 and adds handling of the coverage tpes defined in the OGC Coverage Implementation Schema (CIS) 1.0 [09-146r2] and 1.1 [09-146r6]. Further, this version 1.1 takes into account changed and new rules OGC has established since the original version 1.0 adoption.

NOTE Due to OGC’s rules of compatibility among minor release numbers this WCPS 1.1 standard actually applies to all CIS 1.x versions.

2 Compliance

Annex A (normative) specifies compliance tests which shall be tested by any service claiming to implement WCPS.

3 Normative references

The following normative documents contain provisions that, through reference in this text, constitute provisions of this standard. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.

IETF RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1

ISO 8601:2000, Data elements and interchange formats — Information interchange — Representation of dates and times

OGC 09-146r6, Coverage Implementation Schema (CIS), version 1.1

OGC 17-089r1, OpenGIS^®Web Coverage Service (WCS) Core, version 2.1

NOTE The WCS standard cited contains a list of normative references that are also applicable to this extension standard.

OGC 07-092r1, Definition identifier URNs in OGC namespace, version 1.1.2

OGC 08-059r4, WCS Processing Extension, version 2.0

W3C XQuery 3.1. W3C Recommendation 21 March 2017, https://www.w3.org/TR/2017/REC-xquery-31-20170321/

W3C XML Path Language (XPath) Version 3.1. W3C Recommendation 21 March 2017, http://www.w3.org/TR/xpath/

4 Terms and definitions

For the purposes of this document, the terms and definitions given in the above references (in particular: WCS [OGC 17-089r1]) apply.

5 Conventions

5.1 Symbols (and abbreviated terms)

Most of the abbreviated terms listed in Subclause 5.1 of the OWS Common Standard [OGC 06-121r3] also apply to this document.

Further, this document assumes familiarity with the terms and concepts of the Web Coverage Service Standard [OGC 07-067r5].

5.2 UML notation

All the diagrams that appear in this standard are presented using the Unified Modeling Language (UML) static structure diagram, as described in Subclause 5.2 of the OGC Web Services Common Standard [OGC 06-121r3].

5.3 Platform-neutral and platform-specific specifications

In terms of Clause 10 of OGC Abstract Specification Topic 12 “OpenGIS Service Architecture” (which contains ISO 19119), this document includes only Distributed Computing Platform-neutral specifications. This document specifies each operation request and response in platform-neutral fashion. This is done using a semi-formal approach to recursively specifying the language syntax and semantics. The specified platform-neutral data could be encoded in many alternative ways, each appropriate to one or more specific DCPs. One service embedding and encoding is defined in the WCS Processing Extension [08-059r4]. Other encodings may specify an API (Application Programming Interface approach) with actually no networks communication involved between “client” and “server”.

6 Conceptual coverage model

The coverage model of WCPS relies on OGC CIS and formalizes it in a way which is suitable for expressing the semantics of the operations in Section 7.1. Subclause 6.2 describes the constituents of a WCPS coverage by defining a set of coverage probing functions. Some restrictions that apply with regard to general coverages are listed in Section 6.3.

6.1 Coverage model

NOTE At the time of the initial writing of WCPS the current OGC Coverage Implementation Schema (CIS) 1 and Web Coverage Service (WCS) 2 was not yet available. Meantime CiS and WCS provide a comprehensive coverage data and service model which should be used with WCPS as well.

6.1.1 Coverages

A coverage consists of a set of locations bearing some value. Following the mathematical notion of a function that maps elements of a domain (here: spatio-temporal[1] coordinates) to a range (here: “pixel”, “voxel”, … values), the set of coverage locations bearing values is called the coverage domain while the set of possible values, i.e., the coverage value data type, is called the coverage range.

A coverage domain with its set of locations (or coordinates) is aligned along some d-dimensional grid where d>0 is called the coverage’s dimensionality. The coordinate space, i.e. the set of all possible coordinates, is spanned by d independent dimension axes. A dimension axis (abbreviated also as dimension or as axis) is identified by its name which is unique within the coverage. The set of all dimension axis names of a coverage C is obtained via the function dimensionNameSet(C).

6.1.2 Dimensions

Each dimension has a dimension type (also referred to as dimension name in this standard) associated, which is one of the elements listed in Table 1. A coverage shall have at least one dimension and can have at most one x, y, r, phi, z, and t dimension. A coverage must not combine x or y with r or phi axes. Function dimensionNameSet(C) denotes the set of dimension types of coverage C.

NOTE 1 Obviously, the dimensionality of some coverage C is given by | dimensionNameSet(C) |.

NOTE 2 In future it is intended to allow further, so-called “abstract” axes. This requires an extension of WCS to allow for more general coordinate reference systems.

Table 1 – Coverage domain dimension types[2].

INSERT_TABLE_08-068r3_0003

NOTE 1 An image CRS always allows to address a coverage in all dimensions. For the other CRSs, however, several CRSs together may be necessary to fully address a coverage – for example, Gauss-Krüger only knows x and y and thus does not allow to specify z and t coordinates in a 4-D x/y/z/t climate model.

NOTE 2 Aside from the ImageCRS which is “canonical” to a coverage there may be more, differing ImageCRSs ontained in crsSet(C,a). However, these do not play the prominent role the “canonical” ImageCRS have in this standard.

For the purpose of this standard, CRSs shall be identified by URLs.

The WCPS service does not need to publish the mapping between coordinates of the different supported CRSs.

6.1.3 Locations

A location L is a set

LC = { (a,c,p) | adimensionNameSet(C), ccrsSet(C,a),
pDimensionPointValues^d }

consisting of dimension names, per dimension the coordinate system used, and a coordinate relative to this dimension and CRS; each of the coverage’s dimension name shall appear exactly once in this set. The set DimensionPointValues^d is a generalization of numeric and string values that allows expressing all kind of d-dimensional coordinate locations, including geographic floating-point coordinates and date/time strings.

Example For dimension type t, encoding follows [ISO 8601:2000] as described in WCS [OGC 07-067r5] Table 16, 17 and owsTime (that is, the possible values are ASCII strings). For an image CRS, encoding will be integer for all dimension types, and for x/y type geographic coordinates it will usually be float.

On each dimension a total ordering relation “” shall be available under all CRSs used.

Example On a t dimension, this ordering relation will yield true for the following comparison:

“Sun Jan 1 23:59:59 CET 2006”
 “Tue Dec 5 22:17:48 CET 2006”

6.1.4 Domain

The set of all locations contained in a coverage forms its domain. A domain’s location set is non-empty. It can be described, for each dimension, by a lower and upper bound (lo,hi) expressed in one of the coverage’s CRSs applicable for this dimension where lohi.

For a coverage C, with dimension(C)=d, function domain() describes its domain structure, which is a set of dimension descriptions consisting of dimension name, dimension type, CRS used, and the lower and upper bound of the coverage domain expressed in the CRS at hand:

domain( C ) = { (a,c,lo,hi) | adimensionNameSet(C),
ccrsSet(C,a), lo,hiDimensionPointValues^d, lohi }

A location L is inside the domain of a coverage C if its coordinates are inside the domain extent under all CRSs supported:

Let

C be a coverage,
LC be a location wrt. coverage C
       with LC = { (a,c,p) | adimensionNameSet(C) where each a occurs exactly
                          once, ccrsSet(C,a), pDimensionPointValues¹ },
GC be the domain of coverage C
       with GC = { (a,c,lo,hi) | adimensionNameSet(C) where each a occurs
                          exactly once,
                          ccrsSet(C,a), lo,hiDimensionPointValues¹, lohi }.

Then,

LC inside GC
if and only if
       for all (a,c,p)LC
       there is some lo,hiDimensionPointValues such that:
              (a,c,lo,hi)GC and lop hi relative to CRS c

NOTE As can be seen from the “” operators, border values are part of the coverage extent.

6.1.5 Range values and types

The value associated with a particular location within a coverage, in short: its point value, can be obtained with probing function value(C,lC) which is defined for every location lC imageCrsDomain(C) and lC inside domain(C).

All grid point values of a coverage share the same type, the coverage’s range type. Admissible types consist of named components called fields; each field is identified by a field name unique for the coverage on hand and bears one of the (atomic) numeric or Boolean types enumerated in the set RangeFieldTypes (see Table 2):

RangeFieldTypes = { boolean, char, unsigned char, short, unsigned short, int, unsigned int, long, unsigned long, float, double, complex, complex2 }

NOTE 2 It is not required that all range fields within a coverage are of the same type.

NOTE 3 Range fields are also known as “bands” or “channels”.

A coverage’s range type description can be obtained by function rangeType() which delivers a set of pairs of field names and field type:

rangeType(C) = { (f,t) | f  rangeFieldNames(C), t  RangeFieldTypes }

Table 2 – Coverage range field data types.

INSERT_TABLE_08-068r3_0004

6.1.6 Null and interpolation

The set of a coverage’s values to be interpreted as null is obtained via probing function nullSet(). This set can be empty.

Probing function interpolationSet(C) returns a set of pairs (im,nr) where im indicates the interpolation type and nr the null resistance employed. This set can be empty.

Interpolation method defaults associated with a coverage can be obtained through probing function interpolationDefault().

6.2 Coverage probing functions summary

A set of so-called probing functions allows to extract the constituents listed above from a given coverage. These functions are not part of the WCPS interface standard, but serve for the sole purpose of defining the semantics of ProcessCoverages requests in Clause 7.1.

Table 3 lists the probing functions provided.

For notational convenience in this document, on the list and set valued items the usual list and set functions are assumed for extraction and manipulation, such as union, intersection. Further, application of some function to a list or set which is defined on the elements denotes simultaneous application of this function to all list or set elements.

Table 3 – Coverage probing functions.

INSERT_TABLE_08-068r3_0005

Example    For a set of numbers {-1, 0, 1} the abs() function produces:
                abs( {-1, 0, 1} ) = { abs(-1), abs(0), abs(1) } = { 0, 1 }
…while for a list (-1, 0, 1) the abs() function produces:
                abs( (-1, 0, 1) ) = ( abs(-1), abs(0), abs(1) ) = ( 1, 0, 1 )

NOTE Operations in WCPS rely solely on the structural information when performing semantic checks, i.e., on structural compatibility in operations. Ensuring semantic interoperability of coverage domains and ranges is not within the current scope of WCPS.

7 WCPS coverage processing language

The WCPS coverage processing language allows WCPS clients to request processing of one or more coverages available on a WCPS server. A WCPS server evaluates an expression and returns an appropriate response to the client. The result returned to the client upon a successful request consists of an ordered sequence of one or more coverages or scalar values.

A WCPS processing request consists of a processCoveragesExpr (see Subclause 7.1.1). Each WCPS server shall implement the coverage processing operation as specified in the following subclauses.

NOTE 1 While the WCS GetCoverage operation allows retrieval of a coverage from a coverage offering, possibly modified through operations like spatial, temporal, and band subsetting and coordinate transformation, the WCPS language extends this functionality through more powerful processing capabilities. This includes, on the one hand, further coverage processing primitives and, on the other hand, nesting of function application, thereby allowing for arbitrarily complex requests.

NOTE 2 WCPS has been designed so as to be “safe in evaluation” – i.e., implementations are possible where any valid WCPS request can be evaluated in a finite number of steps, based on the operation primitives. Hence, WCPS implementations can be constructed in a way that no single request can render the service permanently unavailable. Notwithstanding, it still is possible to send requests that will impose high workload on a server.

NOTE 3 Data items within a WCPS response list can be heterogeneous in size and structure. In particular, the coverages within a response list can have different dimensions, domains, range types, etc. However, a response always consists of either coverages or scalar values.

NOTE 4 As the functionality of WCPS centers around coverage processing, metadata are considered only to the extent necessary for a coherent service. This way WCPS keeps orthogonal to other OGC standards.

7.1 Expression syntax

The WCPS primitives plus the nesting capabilities form an expression language, which is independent from any particular encoding, and collectively is referred to as WCPS language. In the following subsections the language elements are detailed. The complete syntax is listed in Appendix B.

A WCPS expression is called admissible if and only if it adheres to the WCPS language definition. WCPS servers shall return an exception in response to a WCPS request that is not admissible.

Example The coverage expression fragment

$C * 2

is admissible as it adheres to WCPS syntax whereas

$C $C

seen as part of a coverage expression violates WCPS syntax and, hence, is not admissible.

The semantics of a WCPS expression is defined by indicating, for all admissible expressions, the value of each coverage constituent as defined in Subclause 6.2.

An expression is valid if and only if it is admissible and it complies with the conditions imposed by the WCPS language semantics.

Example The coverage expression following is valid if and only if the WCPS offers a coverage, in the processing expression bound to variable $C, that has a numeric field named red.

$C.red * 2.5

NOTE In the remainder of this section, tables are used to describe the effect of an operation on each coverage constituent. For the reader’s convenience an extra column “Changed?” is provided containing an “X” character whenever the operation changes the resp. constituent, and left blank whenever the operation does not affect the resp. constituent.

7.1.1 processCoveragesExpr

The processCoveragesExpr element processes a list of coverages in turn.

Each coverage is optionally checked first for fulfilling some predicate, and gets selected – i.e., contributes to an element of the result list – only if the predicate evaluates to true. Each coverage selected will be processed, and the result will be appended to the result list. This result list, finally, is returned as the ProcessCoverages response unless no exception was generated.

Let

v1, … vn be n pairwise different iteratorVars (n 1),
L1, … Ln be n coverageLists (n 1),
b be a booleanScalarExpr possibly containing occurrences of one or more vi (1in),
P be a processingExpr possibly containing occurrences of vi (1in).

Then,

for any processCoveragesExpr E,
where
            E = for v1 in ( L1 ),
             v2 in ( L2 ),
             … ,
             vn in ( Ln )
         where b
         return P

the result R of evaluating processCoverageExpr E is constructed as follows:

Let R be the empty sequence;
while L1 is not empty:
{     assign the first element in L1 to iteration variable v1;
       while L2 is not empty:
       {     assign the first element in L2 to iteration variable v2;
              …
                    while Ln is not empty:
                    {     assign the first element in Ln to iteration variable vn;
                           evaluate b and P, substituting any occurrence of iteration
                           variable vi by the corresponding coverage;
                           if (b)
                           then
                                  append evaluation result to R;
                                  remove the first element from Ln;
                    }
              …
              }
              remove the first element from L2;
       }
       remove the first element from L1;
}

The elements contained in the coverageList clause, constituting coverage identifiers, are taken from the coverage identifiers advertised by the server.

NOTE In a WCS framework such information can be obtained via a GetCapabilities request.

Coverage identifiers may occur more than once in a coverageList. In this case the coverage shall be inspected each time it is listed, respecting the overall inspection sequence.

Example Assume a WCPS server offers coverages A, B, and C. Then, the server may execute the following WCPS request:

for $c in ( A, B, C )
return tiff( $c )

to produce a result list containing three TIFF-encoded coverages tiff(A), tiff(B), tiff(C).

Example Assume a WCPS server offers satellite images A, B, and C and a coverage M acting as a mask (i.e., with range values between 0 and 1). Then, masking each satellite image can be performed with a request like the following:

for $s in ( A, B, C ),
$m in ( M )
return tiff( $s * $m )

7.1.2 processingExpr

The processingExpr element is either a encodedCoverageExpr (which evaluates to an encoded coverage; see Subclause 7.1.4), or a storeCoverageExpr (see Subclause 7.1.3), or a scalarExpr (which evaluates to coverage description data or coverage summary data; see Subclause 7.1.5).

7.1.3 storeCoverageExpr

The storeCoverageExpr element specifies that an encoded coverage result as described by its E sub element is not to be delivered immediately as response to the request, but to be stored on server side for subsequent retrieval. The result of the storeCoverageExpr expression is the URL under which the result is provided by the server, and the server returns only the XML response part with the URL(s) being in place of the coverage(s) generated.

Let

E be an encodedCoverageExpr.

Then,

for any URI U
where
U = store ( E )

U is defined as that URI at which the coverage result is made available by the server.

Example The following expression will deliver the URL under which the server stores the TIFF-encoded result coverage C:

store( encode( C, “TIFF” ) )

NOTE It is not specified in this standard for how long server-side stored coverages remain available; usually they will be deleted after some implementation dependent time to free server space. Future versions of this standard may offer means to address this.

7.1.4 encodedCoverageExpr

The encodedCoverageExpr element specifies encoding of a coverage-valued request result by means of a data format and possible extra encoding parameters.

Data format encodings should, to the largest extent possible, materialise the coverage’s metadata. A service may store further information as part of the encoding.

Example For a georeferenced coverage, a GeoTIFF result file should contain the coverage’s geo coordinate and resolution information.

NOTE For materialization of the coverage grid values, the coverage’s image CRS shall be used by default. See crsTransformExpr (Subclause 7.1.28) for controlling coverage grid values via other CRSs.

Let

C be a coverageExpr,
f be a string,
where
f is the name of a data format allowed for C,
the data format specified by f supports encoding of a coverage of C’s domain and range.

Then,

for any byteString S
where S is one of
Se = encode ( C , f )
See = encode ( C , f, extraParams )
with extraParams being a string enclosed in double quotes (‘”’)

S is defined as that byte string which encodes C into the data format specified by formatName and the optional extraParams. Syntax and semantics of the extraParams are not specified in this standard.

NOTE 1 In a WCS framework, the data encoding formats supported can be obtained from the supportedFormats list contained in the response to a GetCapabilities request.

NOTE 2 Some format encodings may lead to a loss of information.

NOTE 3 The extraParams are data format and implementation dependent.

Example The following expression specifies retrieval of coverage C encoded in HDF:

encode( C, ”application/x-hdf” )

Example A WCPS implementation may encode a JPEG quality factor of 50% as the string “.50”.

Usage of formats shall adhere to the regulations set forth in OGC 07-067r5 Subclause 9.3.2.2. The sequence of axes used for linearizing arrays for encoding shall be done as governed by some corresponding data format encoding specification.

Example A data format may specify that x and y axes are linearized to achieve a row-major ordering of coverage cells.

7.1.5 scalarExpr

The scalarExpr element is either a getMetaDataExpr (see Subclause 7.1.10) or a booleanScalarExpr (see Subclause 7.1.6) or a numericScalarExpr (see Subclause 7.1.7) or a stringScalarExpr (see Subclause 7.1.7).

NOTE As such, such an expression returns a result which is not a coverage.

NOTE A future version of WCPS may support further scalar operations.

7.1.6 booleanScalarExpr

The booleanScalarExpr element is a scalarExpr (see Subclause 7.1.5) whose result type is Boolean.

Operations provided are the well-known Boolean functions and, or, xor, and not , arithmetic comparison (>, <, >=, <=, =, !=) on strings and numbers, and parenthesing, all bearing the well-known standard semantics.

NOTE The grammar in Annex B additionally uses the non-terminals booleanScalarTerm and booleanScalarFactor to achieve the well-known precedence rules.

7.1.7 numericScalarExpr

The numericScalarExpr element is a scalarExpr (see Subclause 7.1.5) whose result type is numeric (i.e., an integer, float, or complex number).

Example Numeric constants and numerically-valued metadata retrieval functions deliver numbers.

Operations provided are the well-known arithmetic (+, -, *, /) operations bearing the standard mathematical semantics. The rounding function, round(), rounds a real (not complex) number to the next integer number towards zero. A condenseExpr (see Subclause 7.1.31) derives a summary value from a coverage expression.

NOTE The grammar in Annex B additionally uses the non-terminals numericScalarTerm and numericScalarFactor to achieve the well-known precedence rules.

7.1.8 stringScalarExpr

The stringScalarExpr element is a scalarExpr (see Subclause 7.1.5) whose result type is character string of length greater or equal to zero.

Example IdentifierExprs deliver strings.

7.1.9 coverageExpr

The coverageExpr element is either a coverageIdentifier (see Subclause 7.1.12), or setMetaDataExpr (see Subclause 7.1.11), or an inducedExpr (see Subclause 7.1.13), or a subsetExpr (see Subclause 7.1.23), or a crsTransformExpr (see Subclause 7.1.28), or a scaleExpr (see Subclause 7.1.27), or a coverageConstructorExpr (see Subclause 7.1.29), or a coverageConstantExpr (see Subclause 7.1.30).

A coverageExpr always evaluates to a single coverage.

NOTE In the grammar in Annex B, binary induced operations are represented by the non-terminals coverageLogicTerm, coverageLogicFactor, coverageArithmTerm, and coverageArithmFactor. At the bottom of the hierarchy introduced by these non-terminals, coverageValue and coverageAtom connect to the elements described in the subsequent subclauses. This has been done to achieve the desired syntax preference rules (including parentheses) in the syntax.

7.1.10 getMetaDataExpr

The getMetaDataExpr element extracts a coverage description element from a coverage.

NOTE The grid point value sets (“pixels”, “voxels”, …) can be extracted from a coverage using subsetting operations (see Subclause 7.1.22).

Let

C be a coverageExpr.

Then,

The following metadata extraction functions are defined, whereby the result is specified in terms of the coverage’s probing functions as defined in Table 3:

INSERT_TABLE_08-068r3_0006

NOTE Not all information about a coverage can be retrieved this way. In a WCS framework, adding the information supplied in a GetCapabilities and DescribeCoverage response provides complete information about a coverage.

Example For some stored coverage named “iamacoverage” addressed by variable $c, the following expression evaluates to “iamacoverage”:

identifier( $c )

7.1.11 setMetaDataExpr

The setMetaDataExpr element allows to derive a coverage with modified metadata, leaving untouched the coverage range values and all metadata not addressed.

NOTE As WCPS focuses on the processing of the coverage range values, advanced capabilities for manipulating a coverage’s metadata are currently not foreseen.

Let

C₁ be a coverageExpr,
s be a stringConstant,
m, n, p be integers with m0 and n0 and p0,
null be a rangeExpr with nullnullSet(C₁),
null1, …, nullm be rangeExprs which are cast-compatible with type rangeType(C₁),
f be an fieldName it an interpolationType, nr a nullResistance with frangeFieldNames(C₁) and (im,nr)interpolationSet(C₁,f),
it1, ..., itn be interpolationTypes, and nr1, ..., nrn be nullResistances with firangeFieldNames(C₁) and imiinterpolationSet(C₁,f_i) for 1in,
crs1, …, crsp be crsNames.

Then,

for any coverageExpr C₂
where C₂ is one of
            C_id          = setIdentifier( C₁, s )
            C_null        = setNullSet( C₁, { null1, …, nullm } )
            C_intDef     = setInterpolationDefault( C₁, f, (im ,nr) )
            C_int         = setInterpolationSet( C₁, f,
                              { (im1,nr1),... , (imn,nrn) } )
            C_crs         = setCrsSet( C₁, { crs1,... , crsp }, a )

C₂ is defined as follows:

INSERT_TABLE_08-068r3_0007

Example The following coverage expression evaluates to a coverage that, in its data, resembles C , but has no interpolation method available on its range field landUse, allows linear interpolation with full null resistance, and quadratic interpolation with half null resistance on C’s range field panchromatic:

setInterpolation( setInterpolation( C, landUse, { } ), panchromatic, { linear:full, quadratic:half } )

The setNullSet() operation shall not change any preexisting value in the coverage (such as in an attempt to adapt old null values to the new ones).

NOTE Obviously changing a coverage’s null values can render its contents inconsistent.

A server may respond with an exception if it does not support a CRS specified in a setCrsSet() call.

7.1.12 coverageIdentifier

The coverageIdentifier element represents the name of a single coverage offered by the server addressed. It is represented by a coverage variable indicated in the processCoveragesExpr clause (see Subclause 7.1.1).

Let

id be a variableName bound to a coverage C₁ offered by the server.

Then,

for any coverageExpr C₂,
where
C₂ = id

C₂ is defined as follows:

INSERT_TABLE_08-068r3_0008

Example The following coverage expression evaluates to the complete, unchanged coverage C, assuming that coverage iteration variable $c is bound to it at the time of evaluation:

7.1.13 inducedExpr

The inducedExpr element is either a unaryInducedExpr (see Subclause 7.1.14) or a binaryInducedExpr (see Subclause 7.1.21) or a rangeConstructorExpr (see Subclause 7.1.22).

Induced operations allow to simultaneously apply a function originally working on a single value to all grid point values of a coverage. In case the range type contains more than one component, the function shall be applied to each point simultaneously.

Whenever a numeric argument is expected (such as a coverage with numeric range fields), Boolean false and true shall be interpreted as 0 and 1, resp. Conversely, whenever a Boolean argument is expected (such as a coverage with numeric range fields), then 0 and 1 shall be interpreted as Boolean false and true, resp.

Whenever one of the point values (“pixels”, etc.) participating in an induced operation is equal to one of the null values of its coverage then the result of the value combination shall be one of the values in the participating coverage’s null value set (for a unary induced operation) or one of the values in the null value set intersection of both participating coverages (for a binary induced operation) if said intersection is not empty. If no null value is available (for a unary induced operation) or the intersection of both input coverages’ null values is empty (for a binary induced operation) then the server shall respond with a service exception.

The result coverage has the same domain, but may change its range type.

NOTE The idea is that for each operation available on the range type, a corresponding coverage operation is provided (“induced from the range type operation”) [1] [2].

Example Adding two RGB images will apply the “+” operation to each pixel, and within a pixel to each range field in turn.

7.1.14 unaryInducedExpr

The unaryInducedExpr element specifies a unary induced operation, i.e., an operation where only one coverage argument occurs.

NOTE The term “unary” refers only to coverage arguments; it is well possible that further non-coverage parameters occur, such as an integer number indicating the shift distance in a bit() operation.

A unaryInducedExpr is either a unaryArithmeticExpr, or trigonometricExpr, or exponentialExpr (in which case it evaluates to a coverage with a numeric range type; see Subclauses 7.1.15, 7.1.16, 7.1.17), a booleanExpr (in which case it evaluates to a Boolean expression; see Subclause 7.1.18), a castExpr (in which case it evaluates to a coverage with unchanged values, but another range type; see Subclause 7.1.19), or a fieldExpr (in which case a range field selection is performed; see Subclause 7.1.20).

7.1.15 unaryArithmeticExpr

The unaryArithmeticExpr element specifies a unary induced arithmetic operation.

Let

C₁ be a coverageExpr

Then,

for any coverageExpr C₂
where C₂ is one of
            C_plus   = + C₁
            C_minus = - C₁
            C_sqrt   = sqrt( C₁ )
            C_abs    = abs( C₁ )

C₂ is defined as follows:

INSERT_TABLE_08-068r3_0009

The server shall respond with an exception if one of the coverage’s grid point values or its null values is negative.

Example The following coverage expression evaluates to a float-type coverage where each range value contains the square root of the sum of the corresponding source coverages’ values.

sqrt( $c + $d )

7.1.16 trigonometricExpr

The trigonometricExpr element specifies a unary induced trigonometric operation.

Let

C₁ be a coverageExpr

Then,

for any coverageExpr C₂
where C₂ is one of
            C_sin      = sin( C₁ )
            C_cos      = cos( C₁ )
            C_tan      = tan( C₁ )
            C_sinh     = sinh( C₁ )
            C_cosh     = cosh( C₁ )
            C_arcsin   = arcsin( C₁ )
            C_arccos   = arccos( C₁ )
            C_arctan   = arctan( C₁ )

C₂ is defined as follows:

INSERT_TABLE_08-068r3_0010

The server shall respond with an exception if one of the coverage’s grid point values or its null values is not within the domain of the function to be applied to it.

Example The following expression replaces all values of the coverage addressed by $c with their sine:

sin( $c )

Example To enforce a complex result for real-valued arguments the input coverage can be cast to complex:

arcsin( (complex) $c )

7.1.17 exponentialExpr

The exponentialExpr element specifies a unary induced exponential operation.

Let

C₁ be a coverageExpr,
p be a floatConstant

Then,

for any coverageExpr C₂
where C₂ is one of
            C_exp = exp( C₁ )
            C_log = log( C₁ )
            C_ln   = ln( C₁ )
            C_pow = pow( C₁, p )

C₂ is defined as follows:

INSERT_TABLE_08-068r3_0011

The server shall respond with an exception if one of the coverage’s grid point values or its null values is not within the domain of the function to be applied to it.

Example The following expression replaces all (nonnegative numeric) values of coverage C with their natural logarithm:

ln( $c )

7.1.18 booleanExpr

The booleanExpr element specifies a unary induced Boolean operation.

Let

C₁ be a coverageExpr

Then,

for any coverageExpr C₂
where C₂ is one of
C_not = not C₁
C_bit = bit( C₁ , n )
where n is an expression evaluating to a nonnegative integer value

C₂ is defined as follows:

INSERT_TABLE_08-068r3_0012

Example The following expression inverts all (assumed: Boolean) range field values of coverage $c:

not $c

NOTE The operation bit(a,b) extracts bit position b (assuming a binary representation) from integer number a and shifts the resulting bit value to bit position 0. Hence, the resulting value is either 0 or 1.

7.1.19 castExpr

The castExpr element specifies a unary induced cast operation, that is: to change the range type of the coverage while leaving all other properties unchanged.

NOTE Depending on the input and output types result possibly may suffer from a loss of accuracy through data type conversion.

Let

C₁ be a coverageExpr,
t be a range field type name.

Then,

for any coverageExpr C₂
where
C₂ = ( t ) C₁

C₂ is defined as follows:

INSERT_TABLE_08-068r3_0013

The server shall respond with an exception if one of the coverage’s grid point values or its null values cannot be cast to the type specified (see Subclause 7.2.5).

Example the result range type of the following expression will be char, i.e., 8 bit:

(char) ( $c / 2 )

7.1.20 fieldExpr

The fieldExpr element specifies a unary induced field selection operation. Fields are selected by their name, in accordance with the WCS range field subsetting operation.

NOTE Due to the current restriction to atomic range fields, the result of a field selection has atomic values too.

Let

C₁ be a coverageExpr,
f be a fieldName appearing in rangeFieldNames(C₁).

Then,

for any coverageExpr C₂
where
C₂ = C₁. f

C₂ is defined as follows:

INSERT_TABLE_08-068r3_0014

Example Let $c refer to a coverage with range type integer. Then the following request snippet describes a single-field, integer-type coverage where each grid point value contains the difference between red and green band:

$c.red - $c.green

7.1.21 binaryInducedExpr

The binaryInducedExpr element specifies a binary induced operation, i.e., an operation involving two coverage-valued arguments.

Both participating coverages must have the same number of range components; otherwise the server shall respond with a service exception.

The coverage range types shall be numeric.

Let

C₁, C₂ be coverageExprs,
S₁, S₂ be scalarExprs,
where
            imageCrsDomain(C₁,a) = imageCrsDomain(C₂,a),
            imageCrs(C₁,a) = imageCrs(C₂,a),
            domain(C₁,a) = domain(C₂,a),
            crsSet(C₁,a) = crsSet(C₂,a) for all a  dimensionList(C₂),
            rangeFieldNames(C₁) = rangeFieldNames(C₂),
            rangeType(C₁,f) is cast-compatible with rangeType(C₂,f) or
               rangeType(C₂,f) is cast-compatible with rangeType(C₁,f)
               for all f  rangeFieldNames(C₁),
            nullSet(C₁)  nullSet(C₂)  {}.

Then,

for any coverageExpr C₃
where C₃ is one of
     C_plusCC = C₁ + C₂
    C_minCC = C₁ - C₂
    C_multCC = C₁ * C₂
    C_divCC   = C₁ / C₂
    C_andCC = C₁ and C₂
    C_orCC    = C₁ or C₂
    C_xorCC = C₁ xor C₂
    C_eqCC   = C₁ = C₂
    C_ltCC    = C₁ < C₂
    C_gtCC    = C₁ > C₂
    C_leCC    = C₁ <= C₂
    C_geCC   = C₁ >= C₂
    C_neCC   = C₁ != C₂
    C_ovlCC   = C₁ overlay C₂

          C_plusSC      = S₁ + C₂
    C_minSC       = S₁ - C₂
    C_multSC      = S₁ * C₂
    C_divSC        = S₁ / C₂
    C_andSC       = S₁ and C₂
    C_orSC         = S₁ or C₂
    C_xorSC       = S₁ xor C₂
    C_eqSC        = S₁ = C₂
    C_ltSC         = S₁ < C₂
    C_gtSC         = S₁ > C₂
    C_leSC         = S₁ <= C₂
    C_geSC        = S₁ >= C₂
    C_neSC        = S₁ != C₂
    C_ovlSC        = S₁ overlay C₂

          C_plusCS      = C₁ + S₂
    C_mincS       = C₁ - S₂
    C_multCS      = C₁ * S₂
    C_divCS        = C₁ / S₂
    C_andCS       = C₁ and S₂
    C_orCS         = C₁ or S₂
    C_xorCS       = C₁ xor S₂
    C_eqCS        = C₁ = S₂
    C_ltCS         = C₁ < S₂
    C_gtCS         = C₁ > S₂
    C_leCS         = C₁ <= S₂
    C_geCS        = C₁ >= S₂
    C_neCS        = C₁ != S₂
    C_ovlCS        = C₁ overlay S₂

C₃ is defined as follows:

INSERT_TABLE_08-068r3_0015

Example The following expression describes a coverage composed of the sum of the red, green, and blue fields of the coverage referred to by $c:

$c.red + $c.green + $c.blue

7.1.22 rangeConstructorExpr

The rangeConstructorExpr, an n-ary induced operation, allows to build coverages with compound range structures. To this end, coverage range field expressions enumerated are combined into one coverage.

All input coverages must match wrt. domains and CRSs. An input coverage range field may be listed more than once.

The names of the range fields generated by the operation shall be given by the names prefixed to each component expression.

Let

n be an integer with n1,
C₁, …, C_n be coverageExprs,
f₁, …, f_n be fieldNames
where, for 1i,jn,
            fi  rangeFieldNames(C_i),
            imageCrs(C_i) = imageCrs(C_j),
            imageCrsDomain(C_i) = imageCrsDomain(C_j),
            crsSet(Ci) = crsSet(Cj),
            domain(Ci,ai,ci) = domain(Cj,aj,cj)
               for all aidimensionList(Ci), ajdimensionList(Cj), cicrsSet(Ci), cjcrsSet(Cj).

Then,

for any coverageExpr C’
where C’ is one of
{ f₁ : C₁ ; … ; f_n : C_n }
struct { f₁ : C₁ ; … ; f_n : C_n }

C’ is defined as follows:

INSERT_TABLE_08-068r3_0016

Example 1: The expression below does a false color encoding by combining near-infrared, red, and green bands into a 3-band image of 8-bit channels each, which can be visually interpreted as RGB:

struct
{ red: (char) $l.nir;
green: (char) $l.red;
blue: (char) $l.green
}

Example 2: The following expression transforms a greyscale image referred to by variable $g containing a range field panchromatic into an RGB-structured image:

struct
{ red: $g.panchromatic;
green: $g.panchromatic;
blue: $g.panchromatic
}

7.1.23 subsetExpr

The subsetExpr element specifies spatial and temporal domain subsetting. It encompasses spatial and temporal trimming (i.e., constraining the result coverage domain to a subinterval, Subclause 7.1.24), slicing (i.e., cutting out a hyperplane from a coverage, Subclause 7.1.26), extending (Subclause 7.1.25), and scaling (Subclause 7.1.27) of a coverage expression.

All of the subsetExpr elements allow to make use of coordinate reference systems other than a coverage’s image CRS. A coverage’s individual mapping from some supported CRS coordinates to its ImageCRS coordinates does not need to be disclosed by the server, hence coordinate transformation should be considered a “black box” by the client.

NOTE 1 The special case that subsetting leads to a single point remaining still resembles a coverage by definition; this coverage is viewed as being of dimension 0.

NOTE 2 Range subsetting is accomplished via the unary induced fieldExpr (cf. Subclause 7.1.20).

7.1.24 trimExpr

The trimExpr element extracts a subset from a given coverage expression along the dimension indicated, specified by a lower and upper bound for each dimension affected. Interval limits can be expressed in the coverage’s image CRS or any CRS which the the coverage supports.

Lower as well as upper limits must lie inside the coverage’s domain.

For syntactic convenience, both array-style addressing using brackets and function-style syntax are provided; both are equivalent in semantics.

Let

C₁ be a coverageExpr,
n be an integer with 0n,
a1,…,an be pairwise distinct dimensionNames with ai  dimensionNameSet(C₁) for 1in,
crs1,…,crsn be crsNames with crsi  crsList(C₁) for 1in,
(lo1:hi1),…,(lon:hin) be dimensionIntervalExprs with loihii for 1in.

Then,

for any coverageExpr C₂
where C₂ is one of
            C_bracket = C₁ [ p1, …, pn ]
            C_func     = trim ( C₁, { p1, …, pn } )
with
     pi is one of
     pimg,i = ai ( loi : hii )
     pcrs,i = ai : crsi ( loi : hii )

C₂ is defined as follows:

INSERT_TABLE_08-068r3_0017

NOTE 1 It is possible to mix different CRSs in one trim operation, however each dimension must be addressed in exactly one CRS (either image CRS or another supported CRS).

NOTE 2 A trim operation might simultaneously perform x/y trimming expressed in some geographic coordinate CRS and time trimming in a time CRS.

Example The following are syntactically valid, equivalent trim expressions:

$c[ x : ” EPSG:4326” (-120 : -80),
y : ”EPSG:4326” (-10 : +10) ]

trim( $c,
      { x: ”EPSG:4326” (-120 : -80),
        y: ”EPSG:4326” (-10 : +10)
      }
    )

7.1.25 extendExpr

The extendExpr element extends a coverage to the bounding box indicated. The new grid points are filled with one of the coverage’s null values. If the coverage’s null value set is empty then the server shall throw an exception.

There is no restriction on the position and size of the new bounding box; in particular, it does not need to lie outside the coverage; it may intersect with the coverage; it may lie completely inside the coverage; it may not intersect the coverage at all (in which case a coverage completely filled with null values will be generated).

NOTE In this sense the extendExpr is a generalization of the trimExpr; still the trimExpr should be used whenever the application needs to be sure that a proper subsetting has to take place.

Let

Then,

for any coverageExpr C₂
where
            C₂ = extend ( C₁, { p1, …, pn } )
with
     pi is one of
     pimg,i = ai ( loi : hii )
     pcrs,i = ai : crsi ( loi : hii )

C₂ is defined as follows:

INSERT_TABLE_08-068r3_0018

NOTE A server may decide to restrict the CRSs available on the result, as not all CRSs may be technically appropriate any more.

Example The following is a syntactically valid extend expression:

extend( $c, { x ( -200 : +200 ) } )

7.1.26 sliceExpr

The sliceExpr element extracts a spatial slice (i.e., a hyperplane) from a given coverage expression along one of its dimensions, specified by one or more slicing dimensions and a slicing position thereon. For each slicing dimension indicated, the resulting coverage has a dimension reduced by 1; its dimensions are the dimensions of the original coverage, in the same sequence, with the section dimension being removed from the list. CRSs not used by any remaining dimension are removed from the coverage’s CRS set.

The slicing coordinates shall lie inside the coverage’s domain.

For syntactic convenience, both array-style addressing using brackets and function-style syntax are provided; both are equivalent in semantics.

Let

Then,

for any coverageExpr C₂
where C₂ is one of
            C_bracket = C₁ [ S1, …, Sn ]
            C_func     = slice( C₁, , { S1, …, Sn } )
with
     Si is one of
     Simg,i = ai ( si )
     Scrs,i = ai : crsi ( si )

C₂ is defined as follows:

INSERT_TABLE_08-068r3_0019

NOTE 1 A server may decide to restrict the CRSs available on the result, as not all CRSs may be appropriate any more.

NOTE 2 In a future version of this document this function is likely to be .extended with multi-dimensional slicing.

Example The following are syntactically valid, equivalent slice expressions:

$c[ x ”EPSG:4326” ( 120 ) ]

slice( $c, { x ”EPSG:4326” ( 120 ) } )

7.1.27 scaleExpr

The scaleExpr element performs scaling along a subset of the source coverage’s dimensions. For each of the coverage’s range fields, an interpolation method can be chosen from the coverage’s interpolation method list. If no interpolation is indicated for a field, then this field’s default interpolation method shall be used.

A service exception shall be raised if for any of the coverage’s range fields no appropriate interpolation method is available for the resampling/interpolation performed in the course of the transformation.

Let

C₁ be a coverageExpr,
m, n be integers with 0m and 0n,
a1,…,am be pairwise distinct dimensionNames with ai  dimensionNameSet(C₁) for 1im,
Ii be intervalExprs for 1im which evaluate to pairs loi, hii with loi  hii,
f1, ..., fn be pairwise distinct fieldNames, it1, ..., itn be interpolationTypes, nr1, ..., nrn be nullResistances with firangeFieldNames(C₁)
and (iti,nri)interpolationSet(C₁,f_i) for 1in.

Then,

For any coverageExpr C₂,
where
            C₂ = scale (
                  C₁,
                  { a1 ( I1 ), …, am ( Im ) } ,
                  { f1(it1,nr1), ..., fn(itn,nrn) }
            )

C₂ is defined as follows:

INSERT_TABLE_08-068r3_0020

NOTE Scaling regularly involves range interpolation, hence numerical effects have to be expected.

Example The following expression performs x/y scaling of some coverage– which has one single range field, temperature – referenced by variable $c using interpolation type cubic and null resistance full in both x and y dimension, assuming that the range field supports this method:

scale(
    $c,
    { x ( lo_x: hi_x) , y ( lo_y: hi_y) },
    { red ( cubic , full ), nir ( linear, half ) }
)

If the default interpolation method is undefined and no interpolation method is indicated expressly then the server shall respond with a runtime exception.

7.1.28 crsTransformExpr

The element performs reprojection of a coverage. For each dimension, a separate CRS can be indicated; for any dimension for which no CRS is indicated, no reprojection will be performed. For the resampling which usually is incurred the interpolation method and null resistance can be indicated per range field; for fields not mentioned the default will be applied.

NOTE 1 This changes the range values (e.g., pixel radiometry).

NOTE 2 A service may refuse to accept some CRS combinations (e.g., different CRSs handling for x and y dimension).

NOTE 3 As any coverage bearing a CRS beyond its image CRS is stored in some CRS, there will normally be a parameter combination which retrieves the coverage as stored, without any reprojection operation required.

Let

C₁ be a coverageExpr,
m, n be integers with 1m and 0n,
a1,…,am be pairwise distinct dimensionNames with ai  dimensionNameSet(C₁) for 1im,
crs1,…,crsm be pairwise distinct crsNames with crsi  crsList(C₁) for 1im,
f1, ..., fn be pairwise distinct fieldNames,
it1, ..., itn be interpolationTypes,
nr1, ..., nrn be nullResistances with firangeFieldNames(C₁)
and (iti,nri)  interpolationSet(C₁,f_i) for 1in.

Then,

for any coverageExpr C₂
where
     C₂ = crsTransform(
                             C₁, ,
            { a1 : crs1 , …, am : crsm } ,
            { f1 ( it1 , nr1 ) , ..., fn ( itn , nrn ) }
          )

C₂ is defined as follows:

INSERT_TABLE_08-068r3_0021

Example The following expression transforms coverage $c (which is assumed to have x and y dimensions) into the CRS identified by urn:ogc:def:crs:EPSG:6.6:63266405. Linear interpolation with null resistance “none” is applied to range field red if necessary, to all other range fields the default itenrpolation and null resistance is applied.

crsTransform( $c,
              { x: “EPSG:3035”,
                y: “EPSG:3035”
              },
              { red(linear,none) }
            )

7.1.29 coverageConstructorExpr

The coverageConstructorExpr element allows to create a d-dimensional coverage for some d1.

NOTE To fully exploit the opportunities of CIS 1.1 it is recommended to instead use the modern xWCPS coverage constructor (see Subclause 8.3.4).

The domain definition consists, for each dimension, of a unique dimension name plus lower and upper bound of the coverage, expressed in a fixed image CRS and using integer coordinates; for this image CRS one of the identifiers listed in [05-096r1] Table 1 shall be used.

The coverage’s content is defined by an expression whose type defines the coverage range type.

This coverage has no other CRS associated beyond the abovementioned image CRS; further, it has no null values and interpolation methods associated. Finally, all other metadata are undefined. To set specific metadata for this new coverage the setMetadataExpr (Subclause 7.1.11) is available.

NOTE This constructor is useful

§ whenever the coverage is too large to be described as a constant or

§ when the coverage's range values are derived from some other source (such as in the course of a histogram computation, see example below).

Let

f be a fieldName,
d be an integer with d>0,
axisi be pairwise distinct axisNames for 1id[6],
namei be pairwise distinct variableNames for 1id, which additionally, in the request on hand, are not used already as a variable in this expression’s scope,
Ii be intervalExprs for 1id which evaluate to pairs loi, hii with loi  hii,
V be a scalarExpr possibly containing occurrences of namei.

Then,

For any coverageExpr C
where
            C = coverage f
         over    name1 axis1 ( I1 ),
                 …,
                 named axisd ( Id )
         values V

C is defined as follows:

INSERT_TABLE_08-068r3_0022

Example The expression below represents a 2-D greyscale image with a diagonal shade from white to black (the cast operator forces the floating point division result into an integer):

coverage greyshade
over px x ( 0 : 255 ),
py y ( 0 : 255 )
values (unsigned char) ( px + py ) / 2

Example The expression below computes a 256-bucket histogram over band b some coverage $c of unknown domain and dimension[8]:

coverage histogram
over bucket x ( 0 : 255 )
values count( $c.b = bucket )

NOTE In future, WCPS is expected to support “abstract” axes with non-spatiotemporal semantics, which is the better choice for a histogram. Until then, some existing axis type like “x” is recommended.

7.1.30 coverageConstantExpr

The coverageConstantExpr element allows to create a d-dimensional coverage, for some d1, having one range field component with point values immediately given in the expression.

The coverage’s content is defined by a sequence of values. The narrowest range type encompassing all values encountered shall be its range type.

If the number of range components or their type turns out incompatible for any two points, or if the number of point values provided does not match with the domain extent specified, then the server shall respond with an exception.

NOTE This constructor is useful for supplying a moderately sized coverage,e.g., as filter kernel.

Let

f be a fieldName,
d be an integer with d>0,
axisi be pairwise distinct axisNames for 1id[9],
Ii be intervalExprs for 1id which evaluate to pairs loi, hii with loi  hii,
c₁,…, c_m be constants where m is the product of all d axis extents.

Then,

For any coverageExpr C
where
            C = coverage f
         over   axis1 ( I1 ),
                …,
                axisd ( Id )
         values < S >

     where Ii is one of
            Ii´    =     loi : hii
            Ii´´   =     imageCrsDomain( Ci , namei )

C is defined as follows:

INSERT_TABLE_08-068r3_0023

Example For a Sobel filter, a 3x3 filter kernel can be provided by the expression below. The range value of matrix element (-1/-1) is 1, the value at position (0/-1) is 2, etc.

coverage Sobel3x3
over     px x ( -1 : +1 ),
         py y ( -1 : +1 )
values   < 1; 2; 1;
            0; 0; 0;
           -1; -2; -1
         >

7.1.31 condenseExpr

A condenseExpr is either a reduceExpr (see Subclause7.1.33) or a generalCondenseExpr (see Subclause 7.1.32). It takes a coverage and summarizes its values using some summarization function. The value returned is scalar.

Whenever one of the point values (“pixels”, etc.) participating in a condense operation is equal to one of the null values of its coverage then the result of the operation shall be one of the values in the coverage’s null value set. If no null value is available then the the server shall respond with a service exception.

7.1.32 generalCondenseExpr

The general generalCondenseExpr consolidates the grid point values of a coverage along selected dimensions to a scalar value based on the condensing operation indicated. It iterates over a given domain while combining the result values of the scalarExprs through the condenseOpType indicated. Admissible condenseOpTypes are the binary operations +, *, max, min, and, and or.

Let

op be a condenseOpType,
n be some integer with n0,
d be some integer with d>0,
axisi be dimensionNames for 1id,
namei be pairwise distinct variableNames for 1id which, in the request on hand, are not used already as a variable in this expression’s scope,
Ii be intervalExprs for 1id which evaluate to pairs loi, hii with loi  hii,
Cj be coverageExprs for 1jn,
P be a booleanExpr possibly containing occurrences of namei and Cj,
V be a scalarExpr possibly containing occurrences of namei and Cj
where
1id.

Then,

For any scalarExpr S
where S is one of
     S’    =     condense op
            over name1 axis1 ( I1 ),
                 …,
                 named axisd ( Id )
            using V
     S” =    condense op
            over name1 axis1 ( I1 ),
                 …,
                 named axisd ( Id )
            where P
            using V

S is constructed as follows:

Let S = neutral element of type(V);
for all name1  {lo1,… ,hi1}
       for all name2  {lo2,… ,hi2}
              …
         for all named  {lod,… ,hid}
                           if (expression P is present)
                           then
                                  let predicate P’ be obtained from evaluating expression
                                  P by substituting all occurrences of namei by its current
                                  value where namei occurring in a coordinate
                                  position of Cj is interpreted as coordinates in the image
                                  CRS of Cj;
                           else
                                  P’ = true;
                           if (P’)
                           then
                                  let V’ be obtained from evaluating expression V
                                  by substituting all occurrences of namei by its current
                                  value where namei occurring in a coordinate
                                  position of Cj is interpreted as coordinates in the image
                                  CRS of Cj;
                                  S := S op value(V’);
return S

NOTE 1 Condensers are heavily used, among others, in these two situations:

§ To collapse Boolean-valued coverage expressions into scalar Boolean values so that they can be used in predicates.

§ In conjunction with the coverageConstructorExpr (see Subclause 7.1.29) to phrase high-level imaging, signal processing, and statistical operations.

NOTE 2 The additional expressive power of condenseExpr over reduceExpr is twofold:

§ A WCPS implementation may offer further summarisation functions, as long as these are commutative and associative.

§ The condenseExpr gives explicit access to the coordinate values; this makes summarisation considerably more powerful (see example below).

Example For a filter kernel k, the condenser must summarise not only over the grid point under inspection, but also some neighbourhood. The following applies a 3x3 filter kernel to band b of some coverage $c with extent x0…x1/y0…y1; note that the result image is defined to have an x and y dimension.

coverage filteredImage
over     px x ( x0 : x1 ),
         py y ( y0 : y1 )
values   condense +
         over   kx x ( -1 : +1 ),
                 ky y ( -1 : +1 )
         using   $c.b[ kx + px , ky + py ] * k[ kx , ky ]

where k is a 3x3 matrix like

INSERT_TABLE_08-068r3_0024

NOTE See coverageConstantExpr for a way to specify the k matrix.

7.1.33 reduceExpr

A reduceExpr element derives a summary value from the coverage passed; in this sense it “reduces” a coverage to a scalar value. A reduceExpr is either an add, avg, min, max, count, some, or all operation.

Table 4 – reduceExpr definition via generalCondenseExpr

INSERT_TABLE_08-068r3_0025

7.2 Expression evaluation

This Sublause defines additional rules for ProcessCoverages expression evaluation.

7.2.1 Evaluation sequence

A Web Coverage Processing Server shall evaluate coverage expressions from left to right.

7.2.2 Nesting

A Web Coverage Processing Server shall allow to nest all operators, constructors, and functions arbitrarily, provided that each sub-expression's result type matches the required type at the position where the sub-expression occurs. This holds without limitation for all arithmetic, Boolean, String, and coverage-valued expressions.

7.2.3 Parentheses

A Web Coverage Processing Server shall allow use of parentheses to enforce a particular evaluation sequence.

Let

C₁ and C₂ be coverageExprs

Then,

For any coverageExpr C₂where
C₂ = ( C₁ )

C₂ is defined as yielding the same result as C₁.

Example $c * ( $c > 0 )

7.2.4 Operator precedence rules

In case of ambiguities in the syntactical analysis of a request, operators shall have the following precedence (listed in descending strength of binding):

§ Range field selection, trimming, slicing

§ unary –

§ unary arithmetic, trigonometric, and exponential functions

§ *, /

§ +, -

§ <, <=, >, >=, !=, =

§ and

§ or, xor

§ : (interval constructor), condense, marray

§ overlay

In all remaining cases evaluation is done left to right.

7.2.5 Range type compatibility and extension

A range type t1 is said to be cast-compatible with a range type t2 iff the following conditions hold:

§ Both range types, t1 and t2, have the same number of field elements, say d;

§ For each range field element position i with 1id, the ith range field type f1,i of t1 is cast-compatible with the ith range field type f2,i of t2.

A range field type f1 is said to be cast-compatible with a range field type f2 iff f2 can be cast to f1, whereby casting of f2 to f1 is defined as looking up f2 in Table 5 and replacing it by its right-hand neighbour type or, if it is the last type in line, by the first type of the next line. This is repeated until either f1 is matched, or the end of the Table 5 is reached. Type f1 can be cast to type f2 if the casting procedure terminates with finding t2, otherwise the cast is not possible.

Extending boolean to (signed or unsigned) short shall map false to 0 and true to 1.

On both arguments to binary operations casting shall be attempted until both argument types are equal; if such a common type can be found, then this shall be the binary operation result type; otherwise, an exception shall be thrown.

Example For three single-field coverages F, I, and B with range types float, integer, and boolean, resp., the result type of the following expression is float:

F + I + B

Table 5 – Type extension sequence.

INSERT_TABLE_08-068r3_0026

The type of each of the operands of a multiplicative operator (+, -, *, /) shall be a type that can be extended to a numeric numeric type, or an exception occurs. The type of a multiplicative expression is the extended type of its operands. If this promoted type is an integer type, then integer arithmetic shall be performed; if this promoted type is a floating-point type, then floating-point arithmetic shall be performed; if this promoted type is a complex type, then complex arithmetic shall be performed.

NOTE Explicit and implicit casts should be used with caution, as unintended consequences can arise. Data can be lost when floating-point representations are converted to integral representations as the fractional components of the floating-point values will be truncated (rounded down). Conversely, converting from an integral representation to a floating-point one can also loose precision, since the floating-point type may be unable to represent the integer exactly (for example, float might be an IEEE 754 single precision type, which cannot represent the integer 16777217 exactly, while a 32-bit integer type can). This can lead to situations such as storing the same integer value into two variables of type int and type float which return false if compared for equality.

Whenever rounding from floating-point to integer numbers is required, rounding towards zero shall be applied.

Example For a Boolean single-field coverage $b, and an integer single-field coverage $i, the following expression will evaluate to some integer value:

count( $i * $b )

Before executing any binary operation where the two operands are of different type a cast operation shall be attempted to achieve equal types. The result type of each of the binary induced operations (see Section 7.1.21) addition, subtraction, multiplication, and division shall be equal to the common type of the input operands.

If a cast is attempted or implicitly needed, but not possible according to the above rules, then an exception shall be reported.

NOTE The cast operation is similar to that found in many programming languages, such as C/C++.

7.3 Evaluation exceptions

Whenever a coverage expression cannot be evaluated according to the rules specified in Clauses 7.1 and 7.2, a Web Coverage Processing Server shall respond with an exception.

Example The following expressions will lead to an exception when used in a ProcessCoverages request (reasons: division by zero; square root of a negative number):

$c / 0

sqrt( - abs( $c ) )

7.4 processCoveragesExpr response

The response to a request sending a processCoveragesExpr is one of the following:

Depending on its result type, the normal response to a valid ProcessCoverages request shall consist of one of the following alternatives:

A (possibly empty) list of coverages.
A (possibly empty) list of scalars (where scalar summarizes all non-coverage type data, such as numbers, strings, URLs) or of records of scalars.
An exception.

Encoding of single coverages is governed by the encodeCoverageExpr (see Section 7.1.4). Encoding of scalar structures and exceptions as well as the representation of the overall response shall be governed by a separate, additional protocol specification.

NOTE WCS [OGC 08-059r3] specifies a response protocol suitable for WCPS results. An embedding of WCPS into WPS, including its specific request and delivery structures, has been shown.

8 xWCPS

8.1 Overview

This Clause defines further WCPS functionality for OGC CIS 1.1 coverages. Due to the wide range of coverage types CIS 1.1 supports (such as: GeneralGridCoverage, RectifiedGridCoverage, ReferenceableGridCoverage, and subtypes thereof) a generic mechanism is established for extracting components from such coverages, as well as composing such coverages. This mechanism is based on XPath expressions operating on the structure of a coverage as defined in its XML schema.

NOTE Due to the schema agnostic nature of XPath it is not tied to any particular XML schema, and not even to XML itself. Based on these capabilities it is planned in future to support XPath operations also on the JSON schema, and on other suitable encodings of coverages.

An xWCPS expression may coverage, metadata, or combined expressions by integrating XPath into WCPS. This allows serving and querying data assets combined from data and metadata, even “reverse lookups” where the server evaluates predicates on coverage data and returns only pertaining metadata requested.

8.2 xWCPS language elements

An xWCPS query consists of an xWcpsExpr.

Requirement 1 – Syntax and semantics of a xWcpsExpr shall be given by a WCPS processCoverageExpr potentially in addition containing letExprs, xpathExprs, xWcpsCoverageConstructorExprs, decodeCoverageExprs, switchExprs.

NOTE Requirement counting starts with 1 because at the time of WCPS 1.0 writing the requirements scheme was not yet established. In this WCPS 1.1 document, all normative language is considered a formal requirement.

8.2.1 letExpr

The xWCPS let clause, adopted from W3C XQuery, declares a named constant (in XPath, not quite correctly, named variable) and gives it a value. In most cases, named constants are used purely for convenience, to simplify the expressions and make the code more readable.

Example The following statement defines a constant of name $timeAxis with value “date”.

let $timeAxis := “date”

In a let clause the named constant only takes one value. This can be a single item or a sequence (there is no real distinction — an item is just a sequence of length one), and the sequence can contain nodes, or atomic values, or (beware!) a mixture of the two.

NOTE Named constants cannot be updated – something like let $x:=$x+1 is not allowed. More specifically, it will not lead to an evaluation error, but the result will not be as expected (cf. XPath laterature). This rule might seem very strange if you are expecting WCPS to behave in the same way as procedural languages such as JavaScript or python. But WCPS isn't that kind of language, it's a declarative language and works at a higher level. This constraint is essential to give optimizers the chance to find execution strategies that can search vast databases in fractions of a second. SQL, XSLT, and XQuery users have found that this declarative style of programming grows on you. You start to realize that it enables you to code at a higher level: you tell the system what results you want, rather than telling it how to go about constructing those results.

A xWCPS expression can have any number of let clauses, and they can be in any order except that variables have to be defined before used. If a let clause contains multiple variables, it is semantically equivalent to multiple let clauses, each containing a single variable.

Example The following statement:

let $timeAxis := “date”
let $latAxis := “Lat”

is equivalent to:

let $timeAxis := “date”, $latAxis := “Lat”

Requirement 2 – Syntax and semantics of a letExpr shall be given as follows.

Let

e1, … en be n optional coverageExprs or scalarExprs (n 1),
c1, … cn be n pairwise different variableNames,
c be a coverageExpr or scalarExpr,
where every ci must be defined before used in an expression.

Then,

for any xWcpsExpr X
where
            X = [ let e1 := c1, …, en := cn ]
         for v1 in ( L1 ),
             v2 in ( L2 ),
             … ,
             vn in ( Ln )
         where b
         return P

the result of evaluating X is defined by substituting all occurrences of ei in the for expression by ci and then evaluating the resulting for expression.

Example The following xWCPS query:

let $factor := 10
for $c in ( myCoverage )
return encode( scale( $c, $factor ), “image/tiff” )

…is equivalent to:

for $c in ( myCoverage )
return encode( scale( $c, 10 ), “image/tiff” )

8.2.2 xpathExpr

General W3C XPath 3.1 expressions are syntactically allowed at any position. Semantically, the result of evaluating the expression must match with the context requirements.

Requirement 3 – An xWCPS query consists of WCPS express may contain occurrences of variables defined in the scope of the XPath expression.

Requirement 4 – An XPath expression in an xWCPS query may contain occurrences of variables defined in the scope of the XPath expression.

Example The following interleaving of WCPS and XPath is valid assuming $Lat is an axis of $C: $C/domainSet/$Lat

Requirement 5 – In a context requiring coverages or constituents thereof the result of evaluating an XPath expression in an xWCPS query shall be interpreted as given by the CIS XML schema pertaining to the particular coverage type on hand.

Example For composing some CIS 1.1 GeneralGridCoverage through an xWCPS coverage constructor an XPath expression may contribute the range set; in this case, the result of the XPath evaluation must be a valid CIS 1.1 GeneralGridCoverage range set as per the XML schema.

A WCPS server may refuse to evaluate some expressions, in particular if the volume of intermediate or result data would exceed some internal limits. A typical example is retrieval of the complete range set.

Example For some coverage $C, the XPath expression $C/GeneralGrid/@srsName evaluates to the contents of the srsName attribute in the coverage’s domain set.

NOTE The XPath feature obsoletes the WCPS 1.0 probing functions. For example, the following expressions evaluate to components of coverage $C:

                $C/domainSet
                $C/rangeType
                $C/rangeSet
                $C/metadata

8.2.3 xWcpsCoverageConstructorExpr

The xWcpsCoverageConstructorExpr element allows creating a d-dimensional coverage for some d1.

The coverage’s domain set, range type, range set, and metadata are defined by expressions.

NOTE This constructor is adjusted to CIS coverages, as opposed to the original coverage constructor (Subclause 7.1.29).

A domainSetExpr creates the coverage domain set. This involves setting a Coordinate Reference System (CRS) defining the multi-dimensional axes and the meaning of coordinates, including units of measure; defining the grid type based on the CIS types RectifiedGridCoverage, ReferenceableGridCoverage, and GeneralGridCoverage; indicating the coordinates of the direct positions, i.e., the points where values sit.

The axis names can be chosen freely, although it is recommended to use the terms defined in the axis labels of the corresponding CRS definition. Indicative mapping of axes in the CRS and axes in the domain set constructed is given by their sequence, matched pairwise.

NOTE Coordinates do not need to be numeric (see, e.g., date and time coordinates), but a total ordering must be defined on them; this is accomplished by the corresponding CRS definition.

Requirement 6 – A domainSetExpr shall describe a valid coverage domain set following the rules defined in OGC CIS whereby domainSetExpr establishes the following domain set constituents:

Let

d be an integer with d>0,
c be a nameOrString representing a d -dimensional CRS,
axisi be pairwise distinct nameOrStrings for 1id,
iei,1, iei,2 be integer-valued indexExprs for 1id with iei,1 ≤ iei,2
cei,1, cei,2 be indexExprs for 1id, which are valid coordinates for axis i as per CRS c with cei,1 ≤ cei,2,
resi be differential positive indexExprs for 1id valid for axis i as per CRS c,
ui be nameOrStrings for 1id indicating the unit of measure for axis i as per CRS c,
xei,1 , … , xei,n be indexExprs for 1id, which are valid coordinates for axis i as per CRS c with xei,1 ≤ … ≤ cei,n for some n>0.

Then,

For any domainSetExpr D
where
                  D = domain set
                           crs c with
                           axis1 axisdef1 ,
                           … ,
                           axisd axisdefd
and axisdefi is one of
                  axisdefi = index ( iei,1 : iei,2 )
                  axisdefi = regular ( cei,1 : cei,2 ) uom ui resolution resi
                  axisdefi = irregular ( xei,1 , … , xei,n ) uom ui

D is defined as a domain set of CRS c with axis types as indicated and axis extents per CRS axis as indicated. Axis names used in the domainSetExpr shall be matched pairwise against the CRS axes based on their order of occurrence.

The axis names are made available in the current context for use, eg., as iteration variables in the range set computation where coordinate values get bound to each direct position in turn allowing to inspect each direct position of the coverage.

NOTE 1 Coordinates do not need to be numeric (see, e.g., date and time coordinates), but a total ordering must be defined on them; this is accomplished by the corresponding CRS definition.

NOTE 2 While uom can be deduced from the CRS definition its indication in the expression helps avoiding errors, and implementations may choose to not look up the CRS definition for performance reasons (although this is not recommended).

Example The following domain set establishes a 4D georeferenced timeseries datacube with a spectral dimension, regular in Lat/Long and irregular in time (given the varying number of days a month has and based on the daily resolution specified).

domain set
  crs “EPSG:4326+OGC:date” with
Lat regular (10:30) uom degree resolution 0.5,
Long regular (10:30) uom degree resolution 0.5,
date irregular ( “2017-01-01”, “2017-02-01”,
                  “2017-03-01”, “2017-04-01”,
                  “2017-05-01”, “2017-06-01”,
                   “2017-07-01”, “2017-08-01”,
                   “2017-09-01”, “2017-10-01”,
                   “2017-11-01”, ”2017-12-01”) uom d,
band index (1:32)

NOTE The above example uses “Long” for Longitude which is valid even though EPSG at some time has changed the axis abbreviation for Longitude from “long” to “Lon”.

A rangeTypeExpr creates the coverage range type. In the scope of the embedding xWcpsCoverageConstructorExpr or WCPS condensers this expression defines the range component names as known (immutable) variables. In a rangeSetExpr values derived for some such range component will automatically be cast to the target type (in SWE Common terminology: “quantity”) of that range component.

Requirement 7 – Syntax and semantics of a rangeTypeExpr shall be given as follows.

Let

n be an integer with d>0,
q be a rangeType,
nil₁,…, nil_n be constants for 1in with n>0 compatible with tape q,
int₁,…, int_m be interpolationMethods for 1im with m>0.

Then,

For any rangeTypeExpr T
where
                  T = range type
            quantity q
            [ nil nil₁, …, nil_n ]
            [ interpolation int₁,…, int_m ]

T evaluates to a range type over quantity (i.e.: data type) q with nil values nil₁, …, nil_n and int₁,…, int_m indicating the types of interpolation supported by a coverage with this range type.

Example The expression below represents a single-band range type of dta type unsigned short with nil values 254 and 255; allowed interpolations are linear and quadratic. All further range type components introduced by SWE Common are not present in the resulting range type structure.

range type panchromatic
quantity unsigned short
nil 254, 255
interpolation linear, quadratic

NOTE 1 SWE Common, on which the CIS range type relies, defines several more components which, howver, have turned out to be unused in WCPS practice. Hence, there is a restrioction to the practically relevant parts. A future version of this standard may add handling of further SWE components.

NOTE 2 The WCS 1 concept of null resistance (see Subclause 6.1.6) does not exist in CIS 1 and WCS 2, hence it is not present in the xWCPS interpolation clause.

A rangeSetExpr creates the coverage range set. As in the original WCPS, a scalarExpr is evaluated at every direct position of the coverage, as given by the domain set. The coverage’s direct position coordinates are defined in the domainSetExpr, the coverage range component field names are defined in the rangeTypeExpr.

Requirement 8 – Syntax and semantics of a rangeSetExpr shall be given as follows.

Let

r be a scalarExpr possibly containing occurrences of range component identifiers and direct position indicators as provided by the current context.

Then,

For any rangeSetExpr R
where
R = range set s

R is defined as a coverage range set where s gets evaluated at every direct position provided by the context, and of a type provided by the context.

NOTE This range set is amenable to interpretation only in the context of a complete coverage.

Example The range set expression below adds the current Lat and Long coordinate values (assuming the coverage’s Native CRS defines these axis names) and assigns the result to the range cell given by these coordinates:

range set Lat + Long

An optional metadataExpr creates the coverage metadata component. As such metadata are not interpreted by the coverage they are represented as a string which may contain any character.

Requirement 9 – Syntax of a metadataExpr shall be given as follows.

metadata “<inspireMetadata>...</inspireMetadata>”

NOTE If the metadata value resembles valid XML then XPath can address into these metadata.

An xWcpsCoverageConstructorExpr creates a coverage of some given type and with an identifier provided likewise. A coverage function is optional. Mandatory elements are domain set, range type, and range set. A metadata section is optional.

NOTE The use of the coverage function is currently not standardized within OGC.

Requirement 10 – Syntax and semantics of an xWcpsCoverageConstructorExpr shall be given as follows.

Let

t be an identifier which is either a coverage type defined in CIS or a coverage type validly derived from those,
id be an identifier,
f be a stringConstant representing a CIS coverage function
D be a domainSetExpr,
T be a rangeTypeExpr,
R be a rangeSetExpr,
M be a metadataExpr.

Then,

For any xWcpsCoverageConstructorExpr C
where
C = coverage t id [ f ] [ D ] [ T ] R [ M ]

C is defined as a coverage of type t as follows:

INSERT_TABLE_08-068r3_0027

Due to the historical development not all coverage types represent all information; CIS 1. GeneralGridCoverage can express any grid type and axis type combination, for the other types some constraints apply.

Requirement 11 – In a xWcpsoverageConstructorExpr a RectifiedGridCoverage shall contain only axes of type index and regular; a ReferenceableGridCoverage shall contain only axes of type irregular.

NOTE 1 In this version of the standard only the domain/range representation of coverages is supported. In a future version, more representations, such as geometry/value pair lists and partitioning, will be supported. The same holds for envelope.

NOTE 2 This constructor allows creating entirely new shapes, dimensions, and values – see the examples below.

Example 1 The expression below represents a 3-D georeferenced[12] image timeseries with a diagonal shade from white to black (the cast operator forces the floating point division result into an integer) and an INSPIRE XML metadata record associated:

coverage GeneralGridCoverage MySatelliteDatacube
domain set
  crs “EPSG:4326+OGC:date”
  with
   Lat regular (10:30) uom degree resolution 0.5,
  Long regular (10:30) uom degree resolution 0.5,
  date regular (“2017-01”:”2017-12”) uom m resolution 1
range type panchromatic quantity short,
range set decode( $1 )
metadata “<inspireMetadata>...</inspireMetadata>”

Example 2 The expression below computes a 256-bucket histogram over band b of some coverage $c of unknown domain extent and dimension:

coverage GeneralGridCoverage histogram
domain set crs OGC:Index1D with bucket index (0:255)
range type h quantity unsigned long
range set count( $c.b = bucket )

Example 3 If constituents can be determined then they do not need to be indicated; in this case it is input coverage $c; assuming it has range type unsigned short then the log() operation suggests a float result, so this will be adopted as range type. Along the same line, the domain set is adopted:

coverage GeneralGridCoverage LogOfCube
range set log( $C )

Example The earlier mentioned filter kernel operation is expressed in xWCPS like this:

coverage GeneralGridCoverage filteredImage
domain set
crs “OGC:Index2d” with
x index ( x0 : x1 ),
  y index ( y0 : y1 )
range set
condense +
over   i index ( -1 : +1 ),
         j index ( -1 : +1 )
  using $c.b[ i(i+x), j(j+y) ] * $k

8.2.4 decodeCoverageExpr

A decodeCoverageExpr evaluates a byte stream passed as parameter to a coverage by decoding the bytestream. This bytestream must represent a coverage encoding following CIS 1.1 [09-146r6] and its coverage encoding profiles.

NOTE 1 Implementations will be able to recognize the encoding format used from analyzing the input byte stream, hence no format indication parameter is required.

NOTE 2 Coverages and, in general, features in GML can be represented directly in a WCPS query and, hence, do not require a decoding to be applied.

Requirement 12 – Syntax and semantics of a decodeCoverageExpr shall be given as follows.

Let

b be a byteString

where

b is a valid (binary or ASCII) representation of a complete coverage or a domain set, range type, range set, or metadata component of a coverage,
extraParams is a stringConstant containing decoding directives, such as defined in the CIS encoding profile for the format on hand,

Then,

for any decodeCoverageExpr C
where C is one of
Ce = decode ( b )
Cee = decode ( b , extraParams )

C is defined as the decoded coverage or coverage component equivalent to b while applying the directives in extraParams.

In practice, this function can be used in several ways:

To provide inline constants, such as XML documents or fragments
To provide input files, accompaniying the query, through positional parameters

Example Assume a NetCDF file is passed as positional parameter $1 in the WCS Processing Extension [OGC 08-059]). This decodes the byte stream and establishes the corresponding coverage:

decode( $1 )

Note The extraParams syntax and semantics is data format dependent, specified in the CIS encoding formats.

8.2.5 switchExpr

The switchExpr allows choosing an individual value for each direct position, based on a case distinction.

If the result expressions return scalar values, the returned scalar value on a branch is used in places where the condition expression on that branch evaluates to true.
If the result expressions return coverages, the values of the returned coverage on a branch are copied in the result coverage in all places where the condition coverage on that branch contains pixels with value true.

The conditions of the statement are evaluated in a manner similar to the if-then-else statement in programming languages such as Java or C++. This implies that the conditions must be specified by order of generality, starting with the least general and ending with the default result, which is the most general one. A less general condition specified after a more general condition will be ignored, as the expression meeting the less general expression will have had already met the more general condition.

All input coverages must be of identical coverage type and must have identical domain sets and range types, which will be the result domain set and range type.

Requirement 13 – Syntax and semantics of a switchExpr shall be given as follows.

Let

n be an integer with n1,
C₁, …, C_n be either all scalarExprs evaluating to type Boolean or all coverageExprs with a single Boolean range component,
R,R₁, …, R_n+1 be either all scalarExprs or all coverageExprs,

where, for 1in,

R/name() = R1/name() = … = Rn/name() = Rn+1/name(),
R/DomainSet = R1/DomainSet = … = Rn/DomainSet = Rn+1/DomainSet,
R/RangeType = R1/RangeType = … = Rn/RangeType = Rn+1/RangeType.

Then,

for any coverageExpr C’
where C’ is one of
    C’ = switch
          case C₁    return R₁                        …
                        case C_n    return R_n                        default return R_n+1
coverage C’ is defined as follows:

INSERT_TABLE_08-068r3_0028

All range type components beyond the field names loose their meaning in face of the changed values, so quantities, nil values, units of measure, etc. all are stripped off in the result range type (cf. example in Subclause 7.12.2).

Example 1 The expression below performs a traffic light classification on some single-band coverage $c. It assigns blue:255 multiplied by the original pixel value to all pixels in the $c coverage having a value less than 10, green:255 multiplied by the original pixel value to the ones having values at least equal to 10, but less than 20, red:255 multiplied by the original pixel value to the ones having values at least equal to 20 but less than 30 and black to all other pixels.

switch
case $c < 10 return $c * {red: 0; green: 0; blue: 255}
case $c < 20 return $c * {red: 0; green: 255; blue: 0}
case $c < 30 return $c * {red: 255; green: 0; blue: 0}
default return {red: 0; green: 0; black: 0}

Example 2 The example below computes log of all positive values in $c, and assigns 0 to the remaining ones.

switch
case $c>0 return log($c)
default return 0

8.2.6 Additional atomic types

In addition to the WCPS atomic types defined in Table 2 the types in Table 6 are defined, in particular to support SAR applications.

Requirement 14 – An xWCPS service shall support the data types of Table 6, in addition to those of Table 2.

Table 6 – Additional coverage range field data types.

INSERT_TABLE_08-068r3_0029

8.3 Coordinate Reference Systems (CRSs)

This standard does not define the syntax of CRS parameters. Following a change of course in OGC, URLs are generally preferred, and OGC provides a resolver[13] for CRSs, axes, etc. at URL www.opengis.net/def/crs, www.opengis.net/def/axis/, etc. Composition of CRSs can be done through a special constructor, crs-compound. A typical space/time CRS is given by

http://www.opengis.net/def/crs-compound?
1=http://www.opengis.net/def/crs/EPSG/0/4326&
2=http://www.opengis.net/def/crs/OGC/0/AnsiDate

In practice, however, this leads to lengthy CRS URLs; while this is no problem for machine-to-machine communication it is less convenient for human readers. Therefore, implementations may also support GDAL-style CRS composition, for example: “EPSG:4326+OGC:Date” or some WKT string.

8.4 Evaluation response

The response to a valid xWCPS query shall be a (possibly empty) sequence of strings or a (possibly empty) sequence of coverages.

Requirement 15 – A coverage-valued response to a valid WCPS request shall validate against OGC CIS.

8.5 Metadata

An implementation may choose not to return the complete metadata component of a coverage.

NOTE A possible reason is to differentiate between global metadata (which are valid for the whole coverage and get delivered always) and local metadata (which are valid for a part of a coverage and get only delivered in a subsetting when the area of their validity is retrieved). In this version of the standard this behavior is implementation dependent; in a future version, conventions may be established.

8.5.1 Operator precedence rules

Operator precedence of WCPS remains unchanged, but new operators are phased in.

Requirement 16 xWCPS Operator precedence shall be as follows:

§ Range field selection, trimming, slicing

§ unary –

§ unary arithmetic, trigonometric, and exponential functions

§ *, /

§ +, -

§ <, <=, >, >=, !=, =

§ and

§ or, xor

§ : (interval constructor), condense, coverage, xWCPS coverage constructor

§ Overlay, switch

In all remaining cases evaluation is done left to right.

8.6 Character encoding

The character set available in an xWCPS query is depending on the embedding protocol.

Requirement 17 – The character set of an xWCPS request shall follow the rules of the embedding protocol binding context; default is US ASCII.

Example An extra parameter in a WCS Processing request may specify a Unicode character set.

A quoted string may contain any character, even national special characters and non-printable characters, as long as these are properly encoded following http URL rules.

Requirement 18 – Non-printable characters in an xWCPS request shall be represented according to http rules.

8.7 Evaluation exceptions

Not all syntactically valid xWCPS expressions are semantically admissible. Possible errors include:

An XPath expression result is used as input for a function which expects a different structure;
The data volume construed by the XPath expression is exceeding the server’s capabilities;
An XPath expression attempts to reach into the metadata, but these are not valid XML.

Requirement 19 – Whenever a coverage expression cannot be evaluated an xWCPS service shall respond with an exception.

NOTE No specific exception handling is defined here as this will be defined by the concrete protocol binding the WCPS service provides, such as GET/KVP, XML/POST, SOAP, or OpenAPI.

Annex A
(normative)

Abstract Test Suite

The Abstract Test Suite for WCPS is provided in [OGC 08-069], defining conformance class WCPS which is the core conformance class. The additional rules for xWCPS, which needs to be passed in addition to WCPS, are provided below.

Test:

Send query to system under test containing valid versions of each of the expressions
Check for proper result.

Requirement 2 – Syntax and semantics of a letExpr shall be given as follows.

Test:

Send query to system under test containing valid versions of let expressions
Check for proper result.

Requirement 3 – An xWCPS query consists of WCPS express may contain occurrences of variables defined in the scope of the XPath expression.

Test:

Send query to system under test containing let expressions with valid variables used in other places of the query
Check for proper result.

Requirement 4 – An XPath expression in an xWCPS query may contain occurrences of variables defined in the scope of the XPath expression.

Test:

Send query to system under test containing valid XPath expressions utilizing let variables
Check for proper result.

Test:

Send query to system under test containing valid XPath expressions
Check for result matching CIS XML schema.

Requirement 6 – A domainSetExpr shall describe a valid coverage domain set following the rules defined in OGC CIS whereby domainSetExpr establishes the following domain set constituents: (…)

Test:

Send query to system under test containing valid domainSetExprs (as part of coverage constructor)
Check for proper domain set result.

Requirement 7 – Syntax and semantics of a rangeTypeExpr shall be given as follows.

Test:

Send query to system under test containing valid rangeTypeExprs (as part of coverage constructor)
Check for proper domain set result.

Requirement 8 – Syntax and semantics of a rangeSetExpr shall be given as follows.

Test:

Send query to system under test containing valid rangeSetExprs (as part of coverage constructor)
Check for proper result.

Requirement 9 – Syntax of a metadataExpr shall be given as follows.

Test:

Send query to system under test containing valid metadataExprs (as part of coverage constructor)
Check for proper result.

Requirement 10 – Syntax and semantics of an xWcpsCoverageConstructorExpr shall be given as follows.

Test:

Send query to system under test containing valid xWcpsCoverageConstructorExprs
Check for proper result.

Test:

Send query to system under test containing valid xWcpsCoverageConstructorExprs
Check for proper result.

Requirement 12 – Syntax and semantics of a decodeCoverageExpr shall be given as follows.

Test:

Send query to system under test containing valid decodeCoverageExprs
Check for proper domain set result.

Requirement 13 – Syntax and semantics of a switchExpr shall be given as follows.

Test:

Send query to system under test containing valid switchExprs
Check for proper domain set result.

Requirement 14 – An xWCPS service shall support the data types of Table 6, in addition to those of Table 2.

Test:

Send query to system under test containing valid uses of the additional data types
Check for proper domain set result.

Requirement 15 – A coverage-valued response to a valid WCPS request shall validate against OGC CIS.

Test:

Send query to system under test returning OGC CIS coverages
Check for proper domain set result.

Requirement 16 xWCPS Operator precedence shall be as follows: (…)

Test:

Send query to system under test containing unparenthesized expressions, send same queries adequately parenthesized to determine same result
Check for proper domain set result.

Requirement 17 – The character set of an xWCPS request shall follow the rules of the embedding protocol binding context; default is US ASCII.

Test:

Send query to system under test containing valid characters for protocol bindings supported by the system under test; test at least US ASCII.
Check for proper domain set result.

Requirement 18 – Non-printable characters in an xWCPS request shall be represented according to http rules.

Test:

Send query to system under test containing non-printable characters in input and output
Check for proper domain set result.

Requirement 19 – Whenever a coverage expression cannot be evaluated an xWCPS service shall respond with an exception.

Test:

Send query to system under test which must fail, expecting proper exceptions
Check for proper domain set result.

Annex B
(normative)

WCPS Expression Syntax

B.1 Overview

This Annex summarizes the WCPS expression syntax. It is described in EBNF grammar syntax according to [IETF RFC 2616].

Underlined tokens represent literals which appear “as is” in a valid WCPS expression (“terminal symbols”), tokens in italics represent either sub-expressions to be substituted according to the grammar production rules (“non-terminals”) or terminal symbol classes like identifiers, strings, and numbers as listed at the end of this Annex. The processCoveragesExpr nonterminal is the start of the production system.

Any number of whitespace characters (blank, tabulator, newline) may appear between tokens as long as parsing is unambiguous.

Example Between language tokens (such as “for”) and names there must be at least one whitespace character, whereas between names and non-alphanumeric tokens (such as opening parenthesis, “(“), no whitespace is required.

Meta symbols used are as follows:

- brackets (“[…]”) denote optional elements which may occur or be left out;

- an asterisk (“*”) denotes that an arbitrary number of repetitions of the following element can be chosen, including none at all;

- a vertical bar (“|”) denotes alternatives from which exactly one must be chosen;

- Double slashes (“//”) begin comments which continue until the end of the line. Comments are normative.

NOTE The syntax as is remains ambiguous; the semantic rules listed in this document disambiguate the grammar.

B.2 WCPS syntax

processCoveragesExpr:
       for variableName in ( coverageList )
             *( , variableName in ( coverageList ) )
       [ where booleanScalarExpr ]
       return processingExpr

coverageList:
coverageName *( , coverageName )

processingExpr:
       encodedCoverageExpr
       | storeCoverageExpr
       | scalarExpr

encodedCoverageExpr:
encode ( coverageExpr , formatName
[ , extraParams ] )

formatName:
stringConstant

extraParams:
stringConstant

storeCoverageExpr:
store ( encodedCoverageExpr )

scalarExpr:
         getMetaDataExpr
       | booleanScalarExpr
       | numericScalarExpr
       | ( scalarExpr )

booleanScalarExpr:
       booleanScalarExpr or booleanScalarTerm
       | booleanScalarExpr xor booleanScalarTerm
       | booleanScalarTerm

booleanScalarTerm:
booleanScalarTerm and booleanScalarFactor
| booleanScalarFactor

booleanScalarFactor:
       numericScalarExpr compOp numericScalarExpr
       | stringScalarExpr compOp stringScalarExpr
       | not booleanScalarExpr
       | ( booleanScalarExpr )
       | booleanConstant

numericScalarExpr:
       numericScalarExpr + numericScalarTerm
       | numericScalarExpr - numericScalarTerm
       | numericScalarTerm

numericScalarTerm:
       numericScalarTerm * numericScalarFactor
       | numericScalarTerm / numericScalarFactor
       | numericScalarFactor

compOp:
       =
       | !=
       | >
       | >=
       | <
       | <=

stringScalarExpr:
identifierExpr
| stringConstant

identifierExpr:
identifier ( coverageExpr )

domainExpr:
domain ( variableName , axisName , crsName )

setMetaDataExpr:
       setIdentifier ( coverageExpr , stringConstant )
    | setCrsSet ( coverageExpr ,
           { [ crsName *( , crsName ) ] } )
       | setNullSet ( coverageExpr ,
           { [ rangeExpr *( , rangeExpr ) ] } )
    | setInterpolationDefault ( coverageExpr , fieldName
           , interpolationMethod )
    | setInterpolationSet ( coverageExpr , fieldName ,
           { [ interpolationMethod
               *( , interpolationMethod ) ] } )

rangeExpr:
struct { fieldName : scalarExpr
*( : fieldName : scalarExpr ) }

coverageExpr:
       coverageLogicExpr or coverageLogicTerm
       | coverageLogicExpr xor coverageLogicTerm
       | coverageLogicTerm

coverageLogicTerm:
coverageLogicTerm and coverageLogicFactor
| coverageLogicFactor

coverageLogicFactor:
coverageArithmExpr compOp coverageArithmExpr
| coverageArithmExpr

coverageArithmExpr:
      coverageArithmExpr + coverageArithmTerm
      | coverageArithmExpr - coverageArithmTerm
      | coverageArithmTerm

coverageArithmTerm:
      coverageArithmTerm * coverageArithmFactor
      | coverageArithmTerm / coverageArithmFactor
      | coverageArithmFactor

coverageArithmFactor:
coverageArithmFactor overlay coverageValue
| coverageValue

coverageValue:
      coverageAtom
      | subsetExpr
      | unaryInducedExpr
      | crsTransformExpr
      | scaleExpr

exponentialExpr:
       exp ( coverageExpr )
       | log ( coverageExpr )
       | ln ( coverageExpr )

booleanExpr:
not coverageExpr
| bit ( coverageExpr , indexExpr )

indexExpr:
       indexExpr + indexTerm
       | indexExpr – indexTerm
       | indexTerm

indexTerm:
       indexTerm * indexFactor
       | indexTerm / indexFactor
                     // integer division, rounding to next integer towards 0
       | indexFactor

indexFactor:
       indexConstant
       | round ( numericScalarExpr )
       | ( indexExpr )

castExpr:
( rangeType ) coverageExpr

fieldExpr:
coverageExpr . fieldName

rangeConstructorExpr:
struct { fieldName : coverageExpr
*( ; fieldName : coverageExpr ) }

subsetExpr:
       trimExpr
       | sliceExpr
       | extendExpr

trimExpr:
coverageExpr [ dimensionIntervalList ]
| trim ( coverageExpr , { dimensionIntervalList } )

sliceExpr:
coverageExpr [ dimensionPointList ]
| slice ( coverageExpr , { dimensionPointList } )

extendExpr:
extend ( coverageExpr , dimensionIntervalList )

scaleExpr:
scale ( coverageExpr , dimensionIntervalList ,
fieldInterpolationList )

crsTransformExpr:
       crsTransform ( coverageExpr ,
                        dimensionCrsList ,
                        fieldInterpolationList )

dimensionPointList:
dimensionPointElement *( , dimensionPointElement )

dimensionPointElement:
axisName [ : crsName ] ( dimensionPointExpr )

dimensionPointExpr:
       stringConstant
       | booleanConstant
       | integerConstant
       | floatConstant

dimensionIntervalList:
dimensionIntervalElement
*( , dimensionIntervalElement )

dimensionIntervalElement:
       axisName [ : crsName ]
             ( dimensionPointExpr : dimensionPointExpr )
       | axisName [ : crsName ] ( domainExpr )

dimensionCrsList:
{ dimensionCrsElement *( , dimensionCrsElement ) }

dimensionCrsElement:
axisName : crsName

fieldInterpolationList:
{ fieldInterpolationListElement
*( , fieldInterpolationListElement ) }

fieldInterpolationListElement:
fieldName interpolationMethod

interpolationMethod: // as in WCS [OGC 07-067r5]
( interpolationType : nullResistance )

interpolationType:          // as in WCS [OGC 07-067r5] Table I.7
       nearest
       | linear
       | quadratic
       | cubic

nullResistance:             // as in WCS [OGC 07-067r5]
       full
       | none
       | half
       | other

coverageConstructorExpr:
       coverage coverageName
       over axisIterator *( , axisIterator )
       values scalarExpr

axisIterator:
variableName axisName ( intervalExpr )

intervalExpr:
indexExpr : indexExpr // left value ≤ right value
| imageCrsDomain ( variableName , axisName )

coverageConstantExpr:
       coverage coverageName
       over axisSpec *( , axisSpec )
       values < constant *( ; constant ) >

axisSpec:
axisName ( intervalExpr )

condenseExpr:
reduceExpr
| generalCondenseExpr

generalCondenseExpr:
       condense condenseOpType
       over axisIterator *( , axisIterator )
       [ where booleanScalarExpr ]
       using scalarExpr

condenseOpType:
       +
       | *
       | max
       | min
       | and
       | or

coverageName:
name // coverage identifier as in WCS [OGC 07-067r5]

crsName:
stringConstant // containing a valid CRS name

axisName[14]:
       x
       | y
       | r
       | phi
        | z
        | t
       | name                // where name is none of the other variants

fieldName:
name // as in WCS [OGC 07-067r5] Table 19

constant:
    stringConstant
       | booleanConstant
       | integerConstant
       | floatConstant
       | complexConstant

complexConstant:
( floatConstant , floatConstant )

B.2 WCPS terminal symbols

The following are terminal symbols, in addition to the underlined terminal literals: variableName; name; stringConstant; booleanConstant; integerConstant; floatConstant.

A variableName shall be a consecutive sequence of characters where the first character shall be either an alphabetical character or the “$” character and the remaining characters consist of decimal digits, upper case alphabetical characters, lower case alphabetical characters, underscore (“_”), and nothing else. The length of an identifier shall be at least 1.

NOTE The regular expression describing a variable is: [$a-zA-Z_][0-9a-zA-Z_]*.

A name shall either be a consecutive sequence of digits and/or letters where the first character is a letter, or a non-empty string constant.

NOTE 1 The regular expression describing a name identifier is: ([a-zA-Z_][0-9a-zA-Z_]*)|(“.+”).

NOTE 2 WCS [OGC 07-067r5] allows significant freedom in the choice of names; to combine syntactical simplicity with this generality in a syntax-controlled environment both a non-quoted and a quoted variant are provided.

A booleanConstant shall represent a logical truth value expressed as one of the literals “true” and “false” resp., whereby upper and lower case characters shall not be distinguished.

An integerConstant shall represent an integer number expressed in either decimal, octal (with a “0” prefix), or hexadecimal notation (with a “0x” or “0X” prefix).

A floatConstant shall represent a floating point number following the syntax of the Java programming language.

A stringConstant shall represent a character sequence expressed by enclosing it into double quotes (‘”´).

B.3 xWCPS syntax

For xWCPS this new start symbol is used. It relies on the WCPS syntax, i.e., its nonterminals and terminals declared in Subclauses B.1 and B.2.

xWcpsExpr:
letExpr*
processCoveragesExpr

letExpr:
let letBinding ( , letBinding )*

letBinding:
variableName := ( coverageExpr | scalarExpr )

xWcpsCoverageConstructorExpr:
         coverage coverageTypeName nameOrIdentifier
         [ coverageFunctionExpr ]
         [ domainSetExpr ] [ rangeTypeExpr ] rangeSetExpr
         [ metadataExpr ]

coverageTypeName:
         RectifiedGridCoverage
         | ReferenceableGridCoverage
         | GeneralGridCoverage
         | nameOrString // name of a coverage type derived from the above

coverageFunctionExpr:
coverage function nameOrString

domainSetExpr:
       domain set
         crs nameOrString with
         nameOrString axisdefExpr
         ( , nameOrString axisdefExpr )*

axisdefExpr:
         index ( indexExpr : indexExpr )
         | regular ( indexExpr : indexExpr )
         uom nameOrString resolution indexExpr
         | irregular ( indexExpr ( , indexExpr )* )
         uom nameOrString

rangeTypeExpr:
range type rangeComponent ( , rangeComponent )*

rangeComponent:
nameOrString quantityExpr
[ nilExpr ] [ interpolationExpr ]

quantityExpr:
quantity nameOrString

nilExpr:
nil nameOrString ( , nameOrString )*

interpolationExpr:
interpolation
interpolationMethod ( , interpolationMethod )*

rangeSetExpr:
range set scalarExpr

metadataExpr:
metadata stringConstant

nameOrString:
name | stringConstant

Processing is extended over the definition in Subclause B.1 by adding XPath options:

scalarExpr:
… // B.1 definitions
| xpathExpr // as per W3C XPath 3.1

The range type definition is extended over the definition in Subclause B.1 by adding further complex types (relevant, among others, for SAR):

rangeType:
     …       // B.1 definitions
       | complex char
          | complex short
     | complex int
     | complex long

Coordinates can be more general, and even non-numeric (cf. date and time):

intervalExpr:
… // B.1 definitions
| nameOrString

Bibliography

[1] Ritter, G., Wilson, J., Davidson, J.: Image Algebra: An Overview. Computer Vision, Graphics, and Image Processing, 49(3)1990, pp. 297-331

[2] Baumann, P.: A Database Array Algebra for Spatio-Temporal Data and Beyond. The Fourth International Workshop on Next Generation Information Technologies and Systems (NGITS '99), July 5-7, 1999, Zikhron Yaakov, Israel, Lecture Notes on Computer Science 1649, Springer Verlag, pp. 76 – 93

[3] Baumann, P.: The OGC Web Coverage Processing Service (WCPS) Standard. Geoinformatica, 14(4)2010, pp 447-479

[4] P. Baumann, D. Misev, V. Merticariu, B. Pham Huu: Datacubes: Towards Space/Time Analysis-Ready Data.. In: J. Doellner, M. Jobst, P. Schmitz (eds.): Service Oriented Mapping - Changing Paradigm in Map Production and Geoinformation Management, Springer Lecture Notes in Geoinformation and Cartography, 2018

[1] And in future, once the corresponding extension to WCS is available, abstract axes without spatiotemporal semantics

[2] The rules set forth in this table are superseded by the more recent standard OGC CIS 1.1.

[3] As this function is derived it is not listed in the coverage constituent effects in Section 7.

[4] NOTE As a consequence of this model, the same image CRS is supported by all axes of a coverage.

[5] An undefined default interpolation method shall lead to a runtime exception whenever it needs to be applied (see Clause 6).

[6] In the future, introduction of a GeneralDomain concept is planned for WCS which, among others, will allow an arbitrary number of so-called “abstract axes”, i.e., axes without spatio-temporal semantics. More than one dimension of this type will be allowed.

[7] Note that, due to the empty crsSet, this “loop” anyway will not be “entered”.

[8] In the future, introduction of a GeneralDomain concept is planned for WCS which, among others, will allow an arbitrary number of so-called “abstract axes”, i.e., axes without spatio-temporal semantics. With the availability of abstract axes, dimension type “x” will be replaced by dimension type “abstract” in the code piece displayed.

[9] In the future, introduction of a GeneralDomain concept is planned for WCS which, among others, will allow an arbitrary number of so-called “abstract axes”, i.e., axes without spatio-temporal semantics. More than one dimension of this type will be allowed.

[10] Note that, due to the empty crsSet, this “loop” anyway will not be “entered”.

[11] $a is assumed to evaluate to a coverage with a single numeric range field, $b to a coverage with a single Boolean range field.

[12] Note that the CRS syntax is not defined by WCPS, but through some independent standard (such as by OGC-NA).

[13] This resolver is operated by Jacobs University on behalf of OGC. It is based on an open-source implementation available from www.rasdaman.org.

[14] In the future, introduction of a General Domain concept is planned for WCS which, among others, will allow an arbitrary number of so-called “abstract axes”, i.e., axes without spatio-temporal semantics.