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 coverages 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

	C1 be a coverageExpr,
 	n be an integer with 0≤n,
 	a1,…,an be pairwise distinct dimensionNames with ai ∈ dimensionNameSet(C1) for 1≤i≤n,
 	crs1,…,crsn be crsNames with crsi ∈ crsList(C1) for 1≤i≤n,
 	s1,…,sn be dimensionPoints for 1≤i≤n.

Then,

	for any coverageExpr C2
 	where C2 is one of
 		Cbracket = C1 [ S1,…, Sn ]
 		Cfunc = slice( C1, , { S1,…, Sn } )
 	with
 		Si is one of
 		Simg,i = ai ( si )
 		Scrs,i = ai : crsi ( si )
	C2 is defined as follows:

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 coverages dimensions. For each of the coverages range fields, an interpolation method can be chosen from the coverages interpolation method list. If no interpolation is indicated for a field, then this fields default interpolation method shall be used.

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

Let

	C1 be a coverageExpr,
	m, n be integers with 0≤m and 0≤n,
	a1,…,am be pairwise distinct dimensionNames with ai ∈ dimensionNameSet(C1) 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(C1)
	and (iti,nri)∈interpolationSet(C1,fi) for 1≤i≤n.

Then,

	For any coverageExpr C2,
	where
		C2 = scale (
			C1,
			{ a1 ( I1 ), , am ( Im ) } ,
			{f1(it1,nr1), …, fn(itn,nrn) }
		 )

	C2 is defined as follows:

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 ( lox: hix) , y ( loy: hiy) },
		{ 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

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

Then,

	for any coverageExpr C2
	where
		C2 = crsTransform(
			C1, ,
			{ a1 : crs1 , , am : crsm } ,
			{f1 ( it1 , nr1 ) , …, fn ( itn , nrn ) }
		)

	C2 is defined as follows:

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 coverages 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 expressions 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:

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 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 coverages 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.

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 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,
	c1,…, cm 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:

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 coverages 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 expressions 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

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.

7.2       Expression evaluation

This Sublause defines additional rules for ProcessCoveragesexpression 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

	C1 and C2 be coverageExprs

Then,

	For any coverageExpr C2 
	where
		 C2 = ( C1 )

	C2 is defined as yielding the same result as C1.

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 t₁ is said to be cast-compatible with a range type t₂ iff the following conditions hold:

•   Both range types, t₁ and t₂, 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 f₁,i of t₁ is cast-compatible with the ith range field type f₂,i of t₂.

A range field type f₁ is said to be cast-compatible with a range field type f₂ iff f₂ can be cast to f₁, whereby casting of f₂ to f₁ is defined as looking up f₂ 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 f₁ is matched, or the end of the Table 5 is reached. Type f₁ can be cast to type f₂ if the casting procedure terminates with finding t₂, 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

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"

	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.

	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 coverages 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 coverages 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,
	nil1,…, niln be constants for 1≤i≤n with n>0 compatible with tape q,
	int1,…, intm be interpolationMethods for 1≤i≤m with m>0.

Then,

	For any rangeTypeExpr T
	where
		T = range type
			quantity q
			[ nil nil1,…, niln ]
			[ interpolation int1,…, intm ]

	T evaluates to a range type over quantity (i.e.: data type) q with nil values
	nil1,…, niln and int1,…, intm
	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 coverages 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 coverages 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:

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.

	b be a byteString

	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,

	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.

	n be an integer with n≥1,
	C1, …, Cn be either all scalarExprs evaluating to type Boolean or all coverageExprs with a single Boolean range component,
	R,R1, …, Rn+1 be either all scalarExprs or all coverageExprs,

		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.

	for any coverageExpr C’
	where C’ is one of
 		C’ =	switch
 				case C1    return R1
 				…
 				case Cn    return Rn
 				default return Rn+1
	coverage C’ is defined as follows:

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.

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

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 servers 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.

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

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.

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.

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.

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.

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 16xWCPS 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 requestshall 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

   numericScalarFactor:
 			  ( numericScalarExpr )
			| - numericScalarFactor
 			| round ( numericScalarExpr )
 			| integerConstant
 			| floatConstant
 			| complexConstant
			| condenseExpr

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

   stringScalarExpr:
			  identifierExpr
			| stringConstant

   getMetaDataExpr:
			  identifierExpr
			| imageCrs ( coverageExpr )
			| imageCrsDomain ( coverageExpr )
			| imageCrsDomain ( coverageExpr , axisName )
			| crsSet ( coverageExpr )
			| domainExpr
			| nullSet ( coverageExpr )
			| interpolationDefault ( coverageExpr , fieldName )
			| interpolationSet ( coverageExpr , fieldName )

   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

   coverageAtom:
			  variableName
			| setMetaDataExpr
			| scalarExpr
			| coverageConstantExpr
			| coverageConstructorExpr
			| ( coverageExpr )

   unaryInducedExpr:
			  unaryArithmeticExpr
			| exponentialExpr
			| trigonometricExpr
			| booleanExpr
			| castExpr
			| fieldExpr
			| rangeConstructorExpr

   unaryArithmeticExpr:
			  + coverageAtom
			| - coverageAtom
			| sqrt ( coverageExpr )
			| abs ( coverageExpr )
			| re ( coverageExpr )
			| im ( coverageExpr )

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

   trigonometricExpr:
			  sin ( coverageExpr )
			| cos ( coverageExpr )
			| tan ( coverageExpr )
			| sinh ( coverageExpr )
			| cosh ( coverageExpr )
			| tanh ( coverageExpr )
			| arcsin ( coverageExpr )
			| arccos ( coverageExpr )
			| arctan ( 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

   rangeType:
			  boolean
			| char
			| unsigned char
			| short
			| unsigned short
			| long
			| unsigned long
			| float
			| double
			| complex
			| complex2

   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

   reduceExpr:
			  all ( coverageExpr )
			| some ( coverageExpr )
			| count ( coverageExpr )
			| add ( coverageExpr )
			| avg ( coverageExpr )
			| min ( coverageExpr )
			| max ( coverageExpr )

   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.