Common Query Language (CQL2)

http://www.opengis.net/spec/cql2/1.0/req/case-insensitive-comparison

This requirements class adds support for the operators LIKE, BETWEEN and IN.

Requirement 5

/req/advanced-comparison-operators/like-predicate

The like predicate (rule isLikePredicate) tests whether a string value matches the specified pattern. If the value matches the pattern (rule patternExpression), then the predicate SHALL evaluate to the Boolean value TRUE.

If the value does not match the pattern (patternExpression), then the predicate SHALL evaluate to the Boolean value FALSE.

If the character expression (rule characterExpression) and/or the pattern expression (rule patternExpression) in the predicate is NULL, then the predicate SHALL evaluate to the value NULL.

The character expression (rule characterExpression) in rule isLikePredicate SHALL evaluate to a characterLiteral.

The wildcard character SHALL be the percent character (ASCII x25, %).

The wildcard SHALL match zero of more characters in the test value.

The wildcard character SHALL not match the NULL value.

The single character wildcard SHALL be the underbar character (ASCII x5F, _).

The single character wildcard SHALL match one character in the test value.

The single character wildcard SHALL not match the NULL value.

The escape character SHALL be the back slash (ASCII x5C, \).

Permission 3

/per/advanced-comparison-operators/like-predicate

The server MAY not support characterLiteral as the character expression (rule characterExpression) in rule isLikePredicate.

Example 5. Example of a LIKE predicate

name LIKE 'Smith%'

{
  "op": "like",
  "args": [
    { "property": "name" },
    "Smith%"
  ]
}

Requirement 6

/req/advanced-comparison-operators/between-predicate

The between predicate (rule isBetweenPredicate) tests whether a numeric value lies within the specified range. The between operator is inclusive. If the value lies within the specified range, then the predicate SHALL evaluate to the Boolean value TRUE.

If the value lies outside the specified range, then the predicate SHALL evaluate to the Boolean value FALSE.

If any numeric expression (rule numericExpression) in the predicate is NULL then the predicate SHALL evaluate to the value NULL.

Any function (rule function) or property (rule propertyName) in rule isBetweenPredicate SHALL evaluate to a numericLiteral.

Permission 4

/per/advanced-comparison-operators/between-predicate

The server MAY not support a numericLiteral as the first operand (rule numericExpression) in rule isBetweenPredicate.

The server MAY not support a propertyName as the second and third operand (rule numericExpression) in rule isBetweenPredicate.

Example 6. Examples of a BETWEEN predicate

depth BETWEEN 100.0 and 150.0

{
  "op": "between",
  "args": [
    { "property": "depth" },
    100.0,
    150.0
  ]
}

Requirement 7

/req/advanced-comparison-operators/in-predicate

The in-list predicate (rule isInListPredicate) tests, for equality, the value of a scalar expression against a list of values of the same type. If the value on the left side of the predicate is equal to one or more of the values in the list on the right side of the predicate, the predicate SHALL evaluate to the Boolean value TRUE. Otherwise the predicate SHALL evaluate to the Boolean value FALSE.

The items in the list of an in-list predicate (rule inList, i.e., the items on the right-hand side of the predicate) SHALL be of the same literal type as the value being tested by the predicate (rule scalarExpression, i.e., the left-hand side of the predicate), if evaluated.

Permission 5

/per/advanced-comparison-operators/in-predicate

The server MAY not support characterLiteral, numericLiteral, booleanLiteral or instantInstance as the value to be tested (rule scalarExpression, i.e., the left-hand side of the predicate).

The server MAY not support propertyName as the items in the list of an in-list predicate (rule inList, i.e., the items on the right-hand side of the predicate).

Example 7. Examples of a IN predicate

cityName IN ('Toronto','Frankfurt','Tokyo','New York')

{
  "op": "in",
  "args": [
    { "property": "cityName" },
    [ "Toronto", "Frankfurt", "Tokyo", "New York" ]
  ]
}

category NOT IN (1,2,3,4)

{
  "op": "not",
  "args": [
    {
      "op": "in",
      "args": [
        { "property": "category" },
        [ 1, 2, 3, 4 ]
      ]
    }
  ]
}

7.3. Requirements Class "Case-insensitive Comparison"

Requirements Class

Target type

Servers that evaluate filter expressions

Dependency

http://www.opengis.net/spec/cql2/1.0/req/accent-insensitive-comparison

The following requirements class adds support for case-insensitive string comparisons.

This capability is useful to operate across data that has not been normalized or has been normalized to values that are different than they should be. This is implemented via a standardized string function to normalize a string with respect to case (CASEI).

For example, the CASEI function is useful when a property is set to "PLANET", "Planet", or "planet" and one wants to match either without having to enumerate all the variations.

Implementations of the CASEI function can be complex and depend on the locale, but in many cases the underlying datastore will provide a capability that the function can be mapped to.

Requirement 8

/req/case-insensitive-comparison/casei-function

The server SHALL support a function named CASEI.

The function SHALL accept one argument that can be a character string literal, the name of a property that evaluates to a character string literal or a function that returns a character string literal (see rules characterLiteral, propertyName, function).

The function SHALL return a character string.

If the argument to the function is NULL, the function SHALL return a NULL value.

The function SHALL implement the full case folding algorithm defined in the implementation guidelines of the Unicode 15.0.0 standard (see clause 5.18 Case Mappings, sub-clause Caseless Matching, CaseFolding-15.0.0.txt and SpecialCasing-15.0.0.txt).

Note	Implementation Guidance for CASEI() The implementation of case folding makes use of the CaseFolding-15.0.0.txt file and replaces code points in the source string by the corresponding sequence on lines with a 'C'(ommon) or 'F'(ull).

Example 8. Example case-insensitive comparison

CASEI(road_class) IN (CASEI('Οδος'),CASEI('Straße'))

{
  "op": "in",
  "args": [
    {
      "op": "casei",
      "args": [ { "property": "road_class" } ]
    },
    [
      { "op": "casei", "args": [ "Οδος" ] },
      { "op": "casei", "args": [ "Straße" ] }
    ]
  ]
}

The CASEI function returns a string typed representation of the input expression that is guaranteed to be equal to any other case insensitive representation of that string. In order to ensure correct comparisons, the function should be applied to both sides of an expression. So, for example, the only durable case-insensitive equality comparison would be CASEI(some_property) = CASEI('Straße'). An expression such as CASEI(some_property) = 'strasse' might work but is not guaranteed to work across implementations or between versions of the same implementation.

7.4. Requirements Class "Accent-insensitive Comparison"

Requirements Class

Target type

Servers that evaluate filter expressions

Dependency

http://www.opengis.net/spec/cql2/1.0/req/basic-spatial-functions

This requirements class adds support for accent-insensitive string comparisons to operate across data that has not been normalized or has been normalized to values that are different than they should be.

Similar to the case-insensitive comparison, this capability is supported via a string function ACCENTI.

For example, the ACCENTI function is useful when accents (or, more generally, diacritics not available in ASCII) were dropped when indexing a property. This may be useful, for example, to support users that are not familiar with accents or that do not know how to type them on their keyboard. For example, "papa" would also match "papá". Note that accent-insensitive comparisons can match values with a different meaning. E.g., in Spanish "papa" is potato and "papá" is father. "papá" in an accent-insensitive comparison will match both, but this may also be intentional, because the users knows that some of the data has been processed in ASCII.

Implementations of the ACCENTI function can be complex, but in many cases the underlying datastore will provide a capability that the function can be mapped to.

Requirement 9

/req/accent-insensitive-comparison/accenti-function

The server SHALL support a function named ACCENTI.

The function SHALL return a character string.

If the argument to the function is NULL, the function SHALL return a NULL value.

The function SHALL implement accent stripping and diacritic folding.

Example 9. Example accent-insensitive comparison

ACCENTI(etat_vol) = ACCENTI('débárquér')

{
  "op": "=",
  "args": [
    {
      "op": "accenti",
      "args": [ { "property": "etat_vol" } ]
    },
    {
      "op": "accenti",
      "args": [ "débárquér" ]
    }
  ]
}

Like CASEI, the ACCENTI function returns a string typed representation of the input expression that is guaranteed to be equal to any other accent insensitive representation of that string. In order to ensure correct comparisons, the function should be applied to both sides of an expression. So, for example, the only durable accent-insensitive equality comparison would be ACCENTI(some_property) = ACCENTI('papá'). An expression such as ACCENTI(some_property) = 'papa' might work but is not guaranteed to work across implementations or between versions of the same implementation.

Note

Implementation guidance for ACCENTI()

The implementation of an ACCENTI() function requires the use of fields 3 and 5 from UnicodeData.txt and the application of the Unicode Normalization Algorithm (NFD or NFKD) by:

Recursively replacing code points in the source string by their field 5 Decomposition Mappings for those rows with canonical mappings (i.e. those mappings not prefixed by a tag from Table 14, or any of them if applying NFKD; the decomposition type is also available in DerivedDecompositionType.txt).
Applying special rules to decompose Hangul syllables which do not have a decomposition mapping set up. There are some details in http://www.unicode.org/versions/Unicode9.0.0/ch03.pdf Section 3.12 of the Unicode Standard (from page 142) and https://stackoverflow.com/questions/41309402/breaking-down-a-hangul-syllable-into-letters-jamo. The following C code implements the hangul syllable decomposition:

if(codePoint >= 0xAC00 && codePoint < 0xD7B0)
{
   unsigned int syllable = codePoint - 0xAC00;
   unsigned int t = syllable % 28, v, l;
   syllable /= 28;
   v = syllable % 21, l = syllable / 21;
   add(0x1100 + l);
   add(0x1161 + v);
   if(t) add(0x11A7 + t);
}

Applying the Canonical Ordering algorithm which is stable-sorting (e.g., bubble-sort) the decomposed mapping code points by the value of that combining class for any sub-string where the Combining Class (field 3) (also in DerivedCombiningClass.txt) value is non-zero. This step is necessary if there were combining marks in the source text; the Decomposition Mappings should otherwise already be in the correct order. The canonical ordering will only matter for code points that do not get stripped, so it will not matter for any of the combining characters that are non-spacing marks.

then:

Removing Nonspacing Marks (category Mn) (general category is field 2 of UnicodeData.txt, also available in DerivedGeneralCategory.txt).
An exception should be made for some characters categorized as Mn, as stripping some non-spacing marks — like the Japanese voicing marks (dakuten [ ゛] U+3099 and handakuten [゜] U+309A) — can be a lossy change that would turn はじめ "hajime" (beginning) into はしめ "hashime" (fastener).

Recommendation 2

/rec/accent-insensitive-comparison/japanese-non-spacing-marks Implementations of the ACCENTI() function SHOULD not remove the Japanese non-spacing marks dakuten U+3099[ ゛] and handakuten U+309A[゜].

7.5. Requirements Class "Basic Spatial Functions"

Requirements Class

Target type

Servers that evaluate filter expressions

Dependency

OGC Simple feature access - Part 1: Common architecture, Architecture

Dependency

A spatial predicate evaluates two geometry-valued expressions to determine if the expressions satisfy the requirements of the specified spatial comparison function.

7.5.1. Basic spatial data types and literal values

The basic spatial data types are (part of rule spatialInstance):

"Point": a point;
"BBox": a bounding rectangle or box.

For the Point data type, the following representations are used for literal values:

Text: an OGC Well-Known Text (WKT) literal (see clause 7 of Simple feature access - Part 1: Common architecture)
JSON: a GeoJSON geometry object (see clause 3.1 of GeoJSON)

For the BBox data type:

In the Text representation, the type is encoded as a BBOX() spatial comparison function with four or six numerical arguments, depending on whether the coordinates include a vertical axis (height or depth):

Lower left corner, coordinate axis 1
Lower left corner, coordinate axis 2
Minimum value, coordinate axis 3 (optional)
Upper right corner, coordinate axis 1
Upper right corner, coordinate axis 2
Maximum value, coordinate axis 3 (optional)

In cases where the bounding box spans the antimeridian of a geographic coordinate reference system, the lower-left value (west-most box edge) is larger than the upper-right value (east-most box edge).

If the vertical axis is included, the third and the sixth number are the bottom and the top of the 3-dimensional bounding box.

In JSON, the BBox type is encoded as a JSON object with a "bbox" member with an array with four or six numbers. This representation is consistent with the GeoJSON representation of a bounding box (see clause 5 of GeoJSON).

Since WKT and GeoJSON do not provide a capability to specify the CRS of a geometry literal, the server has to determine the CRS of the geometry literals in a filter expression through another mechanism. For example, a query parameter filter-crs is used in OGC API - Features - Part 3: Filtering to pass the CRS information to the server.

Example 10. Spatial literal example

spatial geometry (Text)

POINT(43.5845 -79.5442)

spatial geometry (JSON)

{
   "type": "Point",
   "coordinates": [43.5845,-79.5442]
}

bounding box (Text)

BBOX(160.6,-55.95,-170,-25.89)

bounding box (JSON)

{
   "bbox": [160.6, -55.95, -170, -25.89]
}

7.5.2. Spatial Functions

In this conformance class, the only required spatial comparison function is intersects and the only required spatial literals are point and BBox. Additional spatial literals are specified in the Basic Spatial Functions with additional Spatial Literals requirements class and additional spatial comparison functions are specified in the Spatial Functions requirements class.

Requirement 10

/req/basic-spatial-operators/spatial-predicate

If the requirements of the standardized spatial comparison function are satisfied, then the predicate SHALL evaluate to the Boolean value TRUE.

If the requirements of the standardized spatial comparison function are not satisfied, then the predicate SHALL evaluate to the Boolean value FALSE.

If either geometry expression (rule geomExpression) of the predicate is NULL then the predicate SHALL evaluate to the value NULL.

Requirement 11

/req/basic-spatial-functions/spatial-functions

The server SHALL support the standardized S_INTERSECTS spatial comparison function as defined by the BNF rule spatialFunction in CQL2 BNF.

All supported standardized spatial comparison functions SHALL be evaluated as defined in clause 6.1.15 of OpenGIS® Implementation Standard for Geographic information - Simple feature access - Part 1: Common architecture (except that in CQL2 the predicates evaluate to a Boolean, not an Integer).

Permission 6

/per/basic-spatial-functions/spatial-predicates

The server MAY not support a spatialInstance as the first operand (rule geomExpression) in rule spatialPredicate.

The server MAY not support a propertyName as the second operand (rule geomExpression) in rule spatialPredicate.

Permission 7	/per/basic-spatial-functions/spatial-data-types
A	The server MAY only support `pointTaggedText` and `bboxTaggedText` in rule `spatialInstance`.

7.5.3. Examples

Example 11. Example spatial predicate

S_INTERSECTS(geometry,POINT(36.319836 32.288087))

{
  "op": "s_intersects",
  "args": [
    { "property": "geometry" },
    {
      "type": "Point",
      "coordinates": [ 36.319836, 32.288087 ]
    }
  ]
}

Example 12. Example for the filter-crs query parameter

...filter-lang=cql2-text&
   filter-crs=http://www.opengis.net/def/crs/EPSG/0/32635&
   filter=S_INTERSECTS(geometry,POINT(379213.87 3610774.16))...

Note that the values of the filter-crs and filter parameters have not been percent-encoded (see section 2.1 of RFC 3986) in this example for better readability.

7.6. Requirements Class "Basic Spatial Functions with additional Spatial Literals"

Requirements Class

http://www.opengis.net/spec/cql2/1.0/req/basic-spatial-functions-plus

Target type

Servers that evaluate filter expressions

Dependency

OGC Simple feature access - Part 1: Common architecture, Architecture

Dependency

This requirements class is similar to the Basic Spatial Functions requirements class except it removes the restrictions on the spatial literals that can participate in the expression.

7.6.1. Additional spatial data types and literal values

In addition to the spatial types listed in the Basic Spatial Functions requirements class (i.e. "Point", "BBox"), this requirements class allows the following Spatial Literals (part of rule spatialInstance):

"LineString": a curve with linear interpolation between the vertices;
"Polygon": a planar surface bounded by closed line strings;
"MultiPoint": a collection of points;
"MultiLineString": a collection of line strings;
"MultiPolygon": a collection of polygons;
"GeometryCollection": a collection of one or more of "Point", "Polygon", "MultiPoint", "MultiLineString", or "MultiPolygon" instances;

Requirement 12	/req/basic-spatial-functions-plus/spatial-data-types
A	The server SHALL support all spatial literals as defined by the BNF rule `spatialInstance` in CQL2 BNF.

The following representations are used for literal values:

Text: an OGC Well-Known Text (WKT) literal (see clause 7 of Simple feature access - Part 1: Common architecture)
JSON: a GeoJSON geometry object (see clause 3.1 of GeoJSON)

Example 13. Spatial literal example

spatial geometry (Text)

LINESTRING(43.6776 -79.5792, 43.7089 -79.5532, 43.7184 -79.5169, 43.7314 -79.4503, 43.7592 -79.4037, 43.7681 -79.3384, 43.8118 -79.3473, 43.8118 -79.3473, 43.8416 -79.3673)

POLYGON((43.5845 -79.5442, 43.6079 -79.4893, 43.5677 -79.4632, 43.6129 -79.3925, 43.6223 -79.3238, 43.6576 -79.3163, 43.7945 -79.1178, 43.8144 -79.1542, 43.8555 -79.1714, 43.7509 -79.6390, 43.5845 -79.5442))

spatial geometry (JSON)

{
  "type": "LineString",
  "coordinates": [
    [43.6776,-79.5792],
    [43.7089,-79.5532],
    [43.7184,-79.5169],
    [43.7314,-79.4503],
    [43.7592,-79.4037],
    [43.7681,-79.3384],
    [43.8118,-79.3473],
    [43.8118,-79.3473],
    [43.8416,-79.3673]
  ]
}

{
  "type": "Polygon",
  "coordinates": [
    [
     [43.5845,-79.5442],
      [43.6079,-79.4893],
      [43.5677,-79.4632],
      [43.6129,-79.3925],
      [43.6223,-79.3238],
      [43.6576,-79.3163],
      [43.7945,-79.1178],
      [43.8144,-79.1542],
      [43.8555,-79.1714],
      [43.7509,-79.6390],
      [43.5845,-79.5442]
    ]
  ]
}

Example 14. Example spatial predicate

S_INTERSECTS(geometry,POLYGON((43.5845 -79.5442, 43.6079 -79.4893, 43.5677 -79.4632, 43.6129 -79.3925, 43.6223 -79.3238, 43.6576 -79.3163, 43.7945 -79.1178, 43.8144 -79.1542, 43.8555 -79.1714, 43.7509 -79.6390, 43.5845 -79.5442)))

{
  "op": "s_intersects",
  "args": [
    { "property": "geometry" },
   {
     "type": "Polygon",
     "coordinates": [
       [
         [43.5845,-79.5442],
         [43.6079,-79.4893],
         [43.5677,-79.4632],
         [43.6129,-79.3925],
         [43.6223,-79.3238],
         [43.6576,-79.3163],
         [43.7945,-79.1178],
         [43.8144,-79.1542],
         [43.8555,-79.1714],
         [43.7509,-79.6390],
         [43.5845,-79.5442]
       ]
     ]
   }
  ]
}

Example 15. Example for the filter-crs query parameter

...filter-lang=cql2-text&
   filter-crs=http://www.opengis.net/def/crs/EPSG/0/32635&
   filter=S_INTERSECTS(geometry,POLYGON((43.5845 -79.5442, 43.6079 -79.4893, 43.5677 -79.4632, 43.6129 -79.3925, 43.6223 -79.3238, 43.6576 -79.3163, 43.7945 -79.1178, 43.8144 -79.1542, 43.8555 -79.1714, 43.7509 -79.6390, 43.5845 -79.5442)))...

Note that the values of the filter-crs and filter parameters have not been percent-encoded (see section 2.1 of RFC 3986) in this example for better readability.

7.7. Requirements Class "Spatial Functions"

Requirements Class

http://www.opengis.net/spec/cql2/1.0/req/spatial-functions

Target type

Servers that evaluate filter expressions

Dependency

Requirements Class "Basic Spatial Functions with additional Spatial Literals"

Dependency

This requirements class adds:

a set of Dimensionally Extended Nine-intersection Model (DE-9IM) relation operators that may be used to add spatial predicates to a CQL2 filter expression. These operators are implemented in CQL2 as standardized functions.

7.7.1. Spatial Functions

Requirement 13

/req/spatial-functions/spatial-functions

The server SHALL support all standardized spatial comparison functions as defined by the BNF rule spatialFunction in CQL2 BNF.

This clause specifies a set of standardized spatial comparison functions that can be used to evaluate whether a specific spatial relationship exists between a pair of geometries.

The definition of these spatial comparison functions is based on a Dimensionally Extended 9-Intersection Model (DE-9IM) and further discussion and explanation about this model can be found at DE-9IM and Dimensionally Extended 9-Intersection Model.

Consider geometries a and b.

The spatial relationships between a and b can be represented by the following intersection matrix (see DE-9IM):

Figure 1. The DE-9IM intersection matrix.

I() represents the set of all positions in the interior of the geometry, B() represents the set of all positions on the boundary of the geometry and E() represents the set of all exterior positions. dim() represents the dimension of the intersection of the interior (I), boundary (B) and exterior (E) of geometries a and b.

The value of each cell in this intersection matrix is either:

0 (i.e. the dimension of the intersection is a point),
1 (i.e. the dimension of the intersection is a line),
2 (i.e. the dimension of the intersection is an area) or,
∅ for the empty set or no intersection.

These values are sometimes simplified to:

T representing {0,1,2} (if the actual value of the dimension does not matter),
F representing the empty set and,
* representing a value that is not relevant to the evaluation of a spatial comparison function.

An example of such an intersection matrix is:

\$[[T,"*",F],["*","*",F],[F,F,"*"]]\$

The following table lists the mathematical definitions of each standardized spatial comparison function as described in OpenGIS® Implementation Standard for Geographic information - Simple feature access - Part 1: Common architecture and also using DE-9IM.

Table 4. Mathematical definitions of standardized spatial comparison functions
Spatial comparison function	Definition	Intersection matrix
S_CONTAINS	S_CONTAINS(a,b) ⬄ b WITHIN a	\$[[T,"",""],["","",""],[F,F,""]]\$
S_CROSSES	S_CROSSES(a,b) ⬄ [I(a) ∩ I(b) ≠ ∅) ∧ (a ∩ b ≠ a) ∧ (a ∩ b ≠ b)]	\$[[T,"",T],["","",""],["","",""]]\$, \$[[T,"",""],["","",""],[T,"",""]]\$, \$[[0,"",""],["","",""],["","",""]]\$
S_DISJOINT	S_DISJOINT(a,b) ⬄ a ∩ b = ∅	\$[[F,F,""],[F,F,""],["","","*"]]\$
S_EQUALS	S_EQUALS(a,b) ⬄ a ⊆ b ∧ b ⊆ a	\$[[T,"",F],["","",F],[F,F,""]]\$
S_INTERSECTS	S_INTERSECTS(a,b) ⬄ ! a DISJOINT b	\$[[T,"",""],["","",""],["","",""]]\$,\$[["",T,""],["","",""],["","",""]]\$,\$[["","",""],[T,"",""],["","",""]]\$,\$[["","",""],["",T,""],["","",""]]\$
S_OVERLAPS	S_OVERLAPS(a,b) ⬄ (dim(I(a)) = dim(I(b)) = dim(I(a) ∩ I(b))) ∧ (a ∩ b ≠ a) ∧ (a ∩ b ≠ b)	\$[[T,"",T],["","",""],[T,"",""]]\$,\$[[1,"",T],["","",""],[T,"",""]]\$,
S_TOUCHES	S_TOUCHES(a,b) ⬄ (I(a) ∩ I(b) = ∅) ∧ (a ∩ b) ≠ ∅	\$[[F,T,""],["","",""],["","",""]]\$,\$[[F,"",""],[F,"",""],["","",""]]\$,\$[[F,"",""],["",T,""],["","","*"]]\$
S_WITHIN	S_WITHIN(a,b) ⬄ (a ∩ b = a) ∧ (I(a) ∩ E(b) = ∅)	\$[[T,"",F],["","",F],["","",""]]\$

The following diagrams illustrate the meaning of the S_CROSSES, S_OVERLAPS, S_TOUCHES and S_WITHIN spatial comparison functions.

Figure 2. Examples of the S_CROSSES relationship Polygon/LineString(a) and LineString/LineString(b).

Figure 3. Examples of the S_OVERLAPS relationship Polygon/LineString(a) and LineString/LineString(b).

Figure 4. Examples of the S_TOUCHES relationship

Figure 5. Examples of the S_WITHIN relationship Polygon/Polygon(a), Polygon/LineString(b), LineString/LineString(c), and Polygon/Point(d)

Note	If geometry a `S_CONTAINS` geometry b, then geometry b is `S_WITHIN` geometry a.

Example 16. Example of a spatial relationship between a property and a literal geometry.

S_CROSSES(road,POLYGON((43.7286 -79.2986, 43.7311 -79.2996, 43.7323 -79.2972,
                        43.7326 -79.2971, 43.7350 -79.2981, 43.7350 -79.2982,
                        43.7352 -79.2982, 43.7357 -79.2956, 43.7337 -79.2948,
                        43.7343 -79.2933, 43.7339 -79.2923, 43.7327 -79.2947,
                        43.7320 -79.2942, 43.7322 -79.2937, 43.7306 -79.2930,
                        43.7303 -79.2930, 43.7299 -79.2928, 43.7286 -79.2986)))

{
  "op": "s_crosses",
  "args": [
    { "property": "road" },
    {
      "type": "Polygon",
      "coordinates": [
        [
          [ 43.7286, -79.2986 ], [ 43.7311, -79.2996 ], [ 43.7323, -79.2972 ],
          [ 43.7326, -79.2971 ], [ 43.7350, -79.2981 ], [ 43.7350, -79.2982 ],
          [ 43.7352, -79.2982 ], [ 43.7357, -79.2956 ], [ 43.7337, -79.2948 ],
          [ 43.7343, -79.2933 ], [ 43.7339, -79.2923 ], [ 43.7327, -79.2947 ],
          [ 43.7320, -79.2942 ], [ 43.7322, -79.2937 ], [ 43.7306, -79.2930 ],
          [ 43.7303, -79.2930 ], [ 43.7299, -79.2928 ], [ 43.7286, -79.2986 ]
        ]
      ]
    }
  ]
}

7.8. Requirements Class "Temporal Functions"

Requirements Class

http://www.opengis.net/spec/cql2/1.0/req/temporal-functions

Target type

Servers that evaluate filter expressions

Dependency

W3C/OGC Time Ontology in OWL, Topological Temporal Relations

Dependency

A temporal predicate evaluates two time-valued expressions to determine, if the expressions satisfy the requirements of the specified standardized temporal comparison function.

The operands in a temporal predicate are temporal geometries. A temporal geometry is either an instant or an interval.

7.8.1. Temporal data types and instances

An instant is either a date (rule dateInstant) or a timestamp (rule timestampInstant) in accordance with RFC 3339 (RFC 3339 rules full-date or date-time). Note that since time is continuous, every instant has a duration and a start/end. Nevertheless, the geometry can be considered an instant in the temporal resolution that is applicable for the specific property.

An interval is the time between a start instant and an end instant, including both bounding instances (rule intervalInstance). Unbounded interval ends are represented by a double-dot string ("..") based on the convention specified in ISO 8601-2.

CQL2 follows ISO 8601-1/ISO 8601-2 in defining intervals as closed at both start and end. Note that some implementations and other specifications use a different definition and it may be necessary to convert between the interval representations. For example, SQL uses half-closed intervals - closed at the start, open at the end.

Depending on the implementation environment, the underlying datastore may or may not support intervals as data types of properties. If not, intervals are typically represented by two separate properties that are instants, one for the start and one for the end of the interval.

All temporal geometries are in the Gregorian Calendar. This is a deliberate restriction to keep implementations of CQL2 simple, avoiding requirements to transform time instants to other temporal coordinate reference systems, but still cover a large number of use cases. This is consistent with the use of RFC 3339 as a key standard for expressing date and time on the internet, including in the OGC API Standards.

For intervals, the following representations are used:

Text: an INTERVAL function with two instants or double-dot strings as parameters;
JSON: an object with an interval member with an array of two instants or double-dot strings as parameters.

In case two instants are provided, both instants have the same granularity (i.e., they are either timestamps or dates).

Note	Instants are also scalar data types; for the representations and examples of instances see Scalar data types.

Example 17. Interval examples

intervals (Text)

INTERVAL('1969-07-16', '1969-07-24')
INTERVAL('1969-07-16T05:32:00Z', '1969-07-24T16:50:35Z')
INTERVAL('2019-09-09', '..')

intervals (JSON)

{ "interval": [ "1969-07-16", "1969-07-24" ] }
{ "interval": [ "1969-07-16T05:32:00Z", "1969-07-24T16:50:35Z" ] }
{ "interval": [ "2019-09-09", ".." ] }

7.8.2. Temporal Functions

The standardized temporal comparison functions in CQL2 are based on the temporal operator definitions in the W3C/OGC Time Ontology in OWL.

Note	Simple temporal predicates involving time instants can also be evaluated using the standard comparison operators.

The following table specifies the definition of the standardized temporal comparison functions where both operands may be instants or intervals, including mixed combinations.

Table 5. Definitions of standardized temporal comparison functions that support both instants and intervals
Temporal comparison function	Definition (t1: first operand, t2: second operand)
T_AFTER	See after
T_BEFORE	See before
T_DISJOINT	(t1 T_BEFORE t2) OR (t1 T_AFTER t2)
T_EQUALS	Start and end of t1 and t2 are coincident
T_INTERSECTS	NOT (t1 T_DISJOINT t2)

Additional temporal comparison functions are available, but only applicable for intervals. Using these functions with instants will result in a client error.

Table 6. Definitions of standardized temporal comparison function between intervals
Temporal comparison function	Definition
T_CONTAINS	See intervalContains
T_DURING	See intervalDuring
T_FINISHEDBY	See intervalFinishedBy
T_FINISHES	See intervalFinishes
T_MEETS	See intervalMeets
T_METBY	See intervalMetBy
T_OVERLAPPEDBY	See intervalOverlappedBy
T_OVERLAPS	See intervalOverlaps
T_STARTEDBY	See intervalStarts
T_STARTS	See intervalStartedBy

The following diagram illustrates the meaning of most of the standardized temporal comparison functions when applied to intervals.

Figure 6. The elementary relations between time intervals

Requirement 14

/req/temporal-operators/temporal-predicates

If the requirements of the standardized temporal comparison function are satisfied, then the predicate SHALL evaluate to the Boolean value TRUE.

If the requirements of the standardized temporal comparison function are not satisfied, then the predicate SHALL evaluate to the Boolean value FALSE.

If the either temporal expression (rule temporalExpression) of the standardized temporal comparison function is NULL, then the predicate SHALL evaluate to the value NULL.

Requirement 15

/req/temporal-functions/temporal-functions

The server SHALL support all temporal functions as defined by the BNF rule temporalFunction in CQL2 BNF.

The temporal functions SHALL be evaluated as defined in the tables Table 5 and Table 6.

Permission 8

/per/temporal-functions/temporal-operands

The server MAY not support a temporalInstance as the first operand (rule temporalExpression) in rule temporalPredicate.

The server MAY not support a propertyName as the second operand (rule temporalExpression) in rule temporalPredicate.

7.8.3. Type casts

As stated in Type casts, the evaluation of filter expressions that involve type casts is system dependent.

For example, a system that evaluates the interval INTERVAL('2022-01-01','2022-04-11T12:41:13Z') can, for example,

throw an error (incompatible types in an interval);
cast the value to an interval of dates, e.g., INTERVAL('2022-01-01','2022-04-11');
cast the value to an interval of timestamps, e.g., INTERVAL('2022-01-01Z00:00:00Z','2022-04-11T12:41:13Z').

7.8.4. Examples

Example 18. Examples of temporal predicate using T_INTERSECTS

T_INTERSECTS(event_time, INTERVAL('1969-07-16T05:32:00Z', '1969-07-24T16:50:35Z'))

{
  "op": "t_intersects",
  "args": [
    { "property": "event_time" },
    { "interval": [ "1969-07-16T05:32:00Z", "1969-07-24T16:50:35Z" ] }
  ]
}

Example 19. Examples of temporal relationships using a property and a temporal literal.

T_DURING(INTERVAL(touchdown, liftOff), INTERVAL('1969-07-16T13:32:00Z', '1969-07-24T16:50:35Z'))

{
  "op": "t_during",
  "args": [
    { "interval": [ { "property": "touchdown" }, { "property": "liftOff" } ] },
    { "interval": [ "1969-07-16T13:32:00Z", "1969-07-24T16:50:35Z" ] }
  ]
}

7.9. Requirements class "Array Functions"

Requirements Class

http://www.opengis.net/spec/cql2/1.0/req/array-functions

Target type

Servers that evaluate filter expressions

Dependency

http://www.opengis.net/spec/cql2/1.0/req/property-property

This clause specifies requirements for supporting array expression in CQL2.

7.9.1. Arrays

An array is a bracket-delimited, comma-separated list of array elements. An array element is either a scalar value, a geometry, an interval, or another array.

Example 20. Array examples

arrays (Text)

( 'a', 'c' )
( 'a', true, 1 )
( DATE('1969-07-16'), DATE('1969-07-20'), DATE('1969-07-24') )

arrays (JSON)

[ "a", "c" ]
[ "a", true, 1 ]
[ { "date" : "1969-07-16" }, { "date" : "1969-07-20" }, { "date" : "1969-07-24" } ]

7.9.2. Array Functions

Array expressions can be tested in a predicate for equality, if one array is a subset of another, if one array is a superset of another or if two arrays overlap or share elements using a standardized set of array comparison functions.

Requirement 16

/req/array-functions/array-predicates

The server SHALL support arrays as defined by the BNF rule arrayPredicate in CQL2 BNF with the exception of the following rules:

function in arrayExpression, arrayElement
arithmeticExpression and function in arrayElement.

Both array expressions SHALL be evaluated as sets. No inherent order SHALL be implied in an array of values.

The semantics of the standardized array comparison functions SHALL be evaluated as follows:

A_EQUALS evaluates to the Boolean value TRUE, if both sets are identical; otherwise the predicate SHALL evaluate to the Boolean value FALSE.
A_CONTAINS evaluates to the Boolean value TRUE, if the first set is a superset of the second set; otherwise the predicate SHALL evaluate to the Boolean value FALSE.
A_CONTAINEDBY evaluates to the Boolean value TRUE, if the first set is a subset of the second set; otherwise the predicate SHALL evaluate to the Boolean value FALSE.
A_OVERLAPS evaluates to the Boolean value TRUE, if both sets share at least one common element; otherwise the predicate SHALL evaluate to the Boolean value FALSE.

Permission 9

/per/array-functions/array-predicates

The server MAY not support an array as the first operand (rule arrayExpression) in rule arrayPredicate.

The server MAY not support a propertyName as the second operand (rule arrayExpression) in rule arrayPredicate.

Note	Support for the BNF rule `function` is added by the requirements class Functions. Support for the BNF rule `arithmeticExpression` is added by the requirements class Arithmetic Expressions.

7.9.3. Examples

Example 21. Evaluate if the value of an array property contains the specified subset of values.

A_CONTAINS(layer:ids, ('layers-ca','layers-us'))

{
  "op": "a_contains",
  "args": [
    { "property": "layer:ids" },
    [ "layers-ca", "layers-us" ]
  ]
}

7.10. Requirements Class "Property-Property Comparisons"

Requirements Class

Target type

Servers that evaluate filter expressions

Dependency

Conditional Dependency

Conditional Dependency

Conditional Dependency

Conditional Dependency

Conditional Dependency

http://www.opengis.net/spec/cql2/1.0/req/functions

This requirements class adds support for properties on the right side of predicates and for literal on the left side of predicates.

Requirement 17

/req/property-property/withdraw-permissions

The following permissions SHALL not apply:

/per/basic-cql2/cql2filter
/per/advanced-comparison-operators/like-predicate
/per/advanced-comparison-operators/between-predicate
/per/advanced-comparison-operators/in-predicate
/per/basic-spatial-functions/spatial-predicates
/per/temporal-functions/temporal-predicates
/per/array-functions/array-predicates

Example 22. Example of a spatial relationship between two literal geometries.

S_CROSSES(LINESTRING(43.72992 -79.2998, 43.73005 -79.2991, 43.73006 -79.2984,
                     43.73140 -79.2956, 43.73259 -79.2950, 43.73266 -79.2945,
                     43.73320 -79.2936, 43.73378 -79.2936, 43.73486 -79.2917),
        POLYGON((43.7286 -79.2986, 43.7311 -79.2996, 43.7323 -79.2972, 43.7326 -79.2971,
                 43.7350 -79.2981, 43.7350 -79.2982, 43.7352 -79.2982, 43.7357 -79.2956,
                 43.7337 -79.2948, 43.7343 -79.2933, 43.7339 -79.2923, 43.7327 -79.2947,
                 43.7320 -79.2942, 43.7322 -79.2937, 43.7306 -79.2930, 43.7303 -79.2930,
                 43.7299 -79.2928, 43.7286 -79.2986)))

{
  "op": "s_crosses",
  "args": [
    {
      "type": "LineString",
      "coordinates": [
        [ 43.72992, -79.2998 ], [ 43.73005, -79.2991 ], [ 43.73006, -79.2984 ],
        [ 43.73140, -79.2956 ], [ 43.73259, -79.2950 ], [ 43.73266, -79.2945 ],
        [ 43.73320, -79.2936 ], [ 43.73378, -79.2936 ], [ 43.73486, -79.2917 ]
      ]
    },
    {
      "type": "Polygon",
      "coordinates": [
        [
          [ 43.7286, -79.2986 ], [ 43.7311, -79.2996 ], [ 43.7323, -79.2972 ],
          [ 43.7326, -79.2971 ], [ 43.7350, -79.2981 ], [ 43.7350, -79.2982 ],
          [ 43.7352, -79.2982 ], [ 43.7357, -79.2956 ], [ 43.7337, -79.2948 ],
          [ 43.7343, -79.2933 ], [ 43.7339, -79.2923 ], [ 43.7327, -79.2947 ],
          [ 43.7320, -79.2942 ], [ 43.7322, -79.2937 ], [ 43.7306, -79.2930 ],
          [ 43.7303, -79.2930 ], [ 43.7299, -79.2928 ], [ 43.7286, -79.2986 ]
        ]
      ]
    }
  ]
}

Example 23. Examples of temporal relationships using temporal literals.

T_DURING(INTERVAL('1969-07-20T20:17:40Z', '1969-07-21T17:54:00Z'), INTERVAL('1969-07-16T13:32:00Z', '1969-07-24T16:50:35Z'))

{
  "op": "t_during",
  "args": [
    { "interval": [ "1969-07-20T20:17:40Z", "1969-07-21T17:54:00Z" ] },
    { "interval": [ "1969-07-16T13:32:00Z", "1969-07-24T16:50:35Z" ] }
  ]
}

7.11. Requirements Class "Functions"

Requirements Class

Target type

Servers that evaluate filter expressions

Dependency

http://www.opengis.net/spec/cql2/1.0/req/arithmetic

This sub-clause specifies requirements for supporting custom functions in CQL2. Functions allow implementations to extend the language.

Requirement 18

/req/functions/functions

The server SHALL support custom functions as defined by the BNF rules function in CQL2 BNF with the exception of the rule arithmeticExpression in argument.

The function SHALL evaluate to its return value that is allowed in the same rule in which the function is used.

Note	Support for the BNF rule `arithmeticExpression` is added by the requirements class Arithmetic Expressions.

Example 24. Example of a spatial relationship between a property and a function that return a geometry value.

It should be noted that the function "Buffer()" in this example is not part of CQL2 but is an example of a function that an implementation may offer that returns a geometry value.

S_WITHIN(road,Buffer(geometry,10,'m'))

{
  "op": "s_within",
  "args": [
    { "property": "road" },
    {
      "op": "Buffer",
      "args": [
        { "property": "geometry" },
        10,
        "m"
      ]
    }
  ]
}

7.12. Requirements Class "Arithmetic Expressions"

Requirements Class

Target type

Servers that evaluate filter expressions

Dependency

http://www.opengis.net/spec/cql2/1.0/req/cql2-text

This clause specifies requirements for supporting arithmetic expressions in CQL2. An arithmetic expression is an expression composed of an arithmetic operand (a property name, a number or a function that returns a number), an arithmetic operator (i.e., one of +, -, *, /, %, div, or ^) and another arithmetic operand.

+, -, *, and / are the four basic arithmetic operations (addition, subtraction, multiplication and division). In addition, the modulo operator (%), integer division (div), and the exponention operator (^) are supported.

Requirement 19

/req/arithmetic/arithmetic

The server SHALL support arithmetic expressions as defined by the BNF rules arithmeticExpression in CQL2 BNF with the exception of the rule function in arithmeticOperand.

Is any arithmeticOperand in an arithmetic expression is NULL, then the expression SHALL evaluate to NULL.

Note	Support for the BNF rule `function` is added by the requirements class Functions.

Example 25. Predicate with an arithmetic expression finding all vehicles that are too tall to pass under a bridge.

vehicle_height > (bridge_clearance-1)

{
  "op": ">",
  "args": [
    { "property": "vehicle_height" },
    {
      "op": "-",
      "args": [
        { "property": "bridge_clearance" },
        1
      ]
    }
  ]
}

8. Requirements classes for encodings

8.1. Overview

This clause specifies requirements for a text encoding and a JSON encoding of CQL2.

8.2. Requirements Class "CQL2 Text"

Requirements Class

Target type

Servers that evaluate filter expressions

Dependency

Simple feature access - Part 1: Common architecture, Well-known Text Representation for Geometry

Conditional Dependency

Conditional Dependency

Requirements Class "Case-insensitive Comparisons"

Conditional Dependency

Conditional Dependency

Requirements Class "Accent-insensitive Comparisons"

Conditional Dependency

Requirements Class "Basic Spatial Functions with additional Spatial Literals"

Conditional Dependency

Conditional Dependency

Conditional Dependency

Conditional Dependency

Requirements Class "Property-Property Comparisons"

Conditional Dependency

Conditional Dependency

Requirements Class "Functions"

Conditional Dependency

Requirements Class "Arithmetic Expressions"

This requirements class defines a Well Known Text (WKT) encoding of CQL2. Such an encoding would be suitable for use with the GET query parameter such as the filter query parameter specified by the "Filter" requirements class in OGC API - Features - Part 3: Filtering.

The "CQL2 Text" encoding is defined by the BNF grammar defined in CQL2 BNF.

Keywords in the BNF grammar are case-insensitive. Augmented BNF for Syntax Specifications states:

ABNF strings are case insensitive and the character set for these strings is US-ASCII.

The list of CQL2 keywords includes:

"A_EQUALS"
"A_CONTAINS"
"A_CONTAINEDBY"
"A_OVERLAPS"
"ACCENTI"
"AND"
"BBOX"
"BETWEEN"
"CASEI"
"DATE"
"DIV"
"FALSE"
"GEOMETRYCOLLECTION"
"IN"
"IS"
"LIKE"
"LINESTRING"
"MULTILINESTRING"
"MULTIPOINT"
"MULTIPOLYGON"
"NOT"
"NULL"
"OR"
"POINT"
"POLYGON"
"S_INTERSECTS"
"S_EQUALS"
"S_DISJOINT"
"S_TOUCHES"
"S_WITHIN"
"S_OVERLAPS"
"S_CROSSES"
"S_CONTAINS"
"T_AFTER"
"T_BEFORE"
"T_CONTAINS"
"T_DISJOINT"
"T_DURING"
"T_EQUALS"
"T_FINISHEDBY"
"T_FINISHES"
"T_INTERSECTS"
"T_MEETS"
"T_METBY"
"T_OVERLAPPEDBY"
"T_OVERLAPS"
"T_STARTEDBY"
"T_STARTS"
"TIMESTAMP"
"TRUE"

If a queryable uses a property name that is one of the keywords, the property name can be used in double quotes to avoid conflicts with the keyword.

Requirement 20

/req/cql2-text/basic-cql2

The server SHALL be able to parse and evaluate all filter expressions encoded as a text string that validate against the BNF rules identified in the Basic CQL2 requirements class.

Requirement 21

/req/cql2-text/escaping

The escape character in a character literal SHALL be the backslash (\\).

Embedded single quotations (') in a character literal SHALL be escaped using a double single quotation ('') OR the backslash (\\) character.

The server SHALL be able to parse the following escaped sequences for encoding control characters in a character literal:

'\a' BELL CHR(07)
'\b' BACKSPACE CHR(08)
'\t' HORIZONTAL TAB CHR(09)
'\n' NEWLINE CHR(10)
'\v' VERTICAL TAB CHR(11)
'\f' FORM FEED CHR(12)
'\r' CARRIAGE RETURN CHR(13)

Requirement 22

/req/cql2-text/advanced-comparison-operators

Condition

Server implements requirements class Advanced Comparison Operators

The server SHALL be able to parse and evaluate all spatial functions encoded as a text string that validate against the BNF production fragments identified in the Advanced Comparison Operators requirements class.

Requirement 23

/req/cql2-text/case-insensitive-comparison

Condition

Server implements requirements class Case-insensitive Comparisons

The server SHALL be able to parse and evaluate all standardized functions encoded as a text string that validate against the BNF production fragments identified in the Case-insensitive Comparisons requirements class.

Requirement 24

/req/cql2-text/accent-insensitive-comparison

Condition

Server implements requirements class Accent-insensitive Comparisons

The server SHALL be able to parse and evaluate all standardized functions encoded as a text string that validate against the BNF production fragments identified in the Accent-insensitive Comparisons requirements class.

Requirement 25

/req/cql2-text/basic-spatial-functions

Condition

Server implements requirements class Basic Spatial Functions

The server SHALL be able to parse and evaluate all standardized spatial comparison functions encoded as a text string that validate against the BNF production fragments identified in the Basic Spatial Functions requirements class.

Requirement 26

/req/cql2-text/basic-spatial-functions-plus

Condition

Server implements requirements class Basic Spatial Functions with additional Spatial Literals

The server SHALL be able to parse all spatial instances encoded as a text string that validate against the BNF production fragments identified in the Basic Spatial Functions with additional Spatial Literals requirements class.

The server SHALL support spatial literals with coordinates in a 2D or 3D CRS, independent of including the Z or not in the value.

OGC WKT uses a "Z" character to distinguish the dimensionality of the coordinate reference system (CRS), e.g. POINT(7 51) for a 2D CRS and POINT Z(7 51 100) for a 3D CRS. In CQL2 Text, processors are required to be more tolerant and to determine the coordinate dimension from the coordinates.

When creating a CQL2 Text expression, it is recommended to encode a geometry literal as required by OGC WKT.

Requirement 27

/req/cql2-text/spatial-functions

Condition

Server implements requirements class Spatial Functions

Requirement 28

/req/cql2-text/temporal-functions

Condition

Server implements requirements class Temporal Functions

The server SHALL be able to parse and evaluate all standardized temporal comparison functions encoded as a text string that validate against the BNF production fragments identified in the Temporal Functions requirements class.

Requirement 29

/req/cql2-text/arrays

Condition

Server implements requirements class Array Functions

The server SHALL be able to parse and evaluate all array expressions encoded as a text string that validate against the BNF production fragments identified in the Array Expressions requirements class.

Requirement 30

/req/cql2-text/property-property

Condition

Server implements requirements class Property-Property Comparisons

The server SHALL be able to parse and evaluate literal values on the left-hand side of comparison, spatial, temporal or array operators and property references on the right-hand side of such operators.

Requirement 31

/req/cql2-text/functions

Condition

Server implements requirements class Functions

The server SHALL be able to parse and evaluate all function call expressions encoded as a text string that validate against the BNF production fragments identified in the Functions requirements class.

Requirement 32

/req/cql2-text/arithmetic

Condition

Server implements requirements class Arithmetic Expressions

The server SHALL be able to parse and evaluate all arithmetic expressions encoded as a text string that validate against the BNF production fragments identified in the Arithmetic Expressions requirements class.

8.3. Requirements Class "CQL2 JSON"

Requirements Class

http://www.opengis.net/spec/cql2/1.0/req/cql2-json

Target type

Servers that evaluate filter expressions

Dependency

GeoJSON, Geometry Objects

Conditional Dependency

Conditional Dependency

Requirements Class "Case-insensitive Comparisons"

Conditional Dependency

Conditional Dependency

Requirements Class "Accent-insensitive Comparisons"

Conditional Dependency

Requirements Class "Basic Spatial Functions with additional Spatial Literals"

Conditional Dependency

Conditional Dependency

Conditional Dependency

Conditional Dependency

Requirements Class "Property-Property Comparisons"

Conditional Dependency

Conditional Dependency

Requirements Class "Functions"

Conditional Dependency

Requirements Class "Arithmetic Expressions"

This requirements class defines a JSON encoding of CQL2. Such an encoding would be suitable as the body of an HTTP POST request.

Requirement 33

/req/cql2-json/basic-cql2

The server SHALL be able to parse and evaluate all filter expressions encoded as JSON that validate against the JSON Schema in JSON Schema for CQL2 and that do not use the following schema components:

"#/$defs/isLikePredicate"
"#/$defs/isBetweenPredicate"
"#/$defs/isInListPredicate"
"#/$defs/casei"
"#/$defs/accenti"
"#/$defs/spatialPredicate"
"#/$defs/temporalPredicate"
"#/$defs/arrayPredicate"
"#/$defs/functionRef"
"#/$defs/arithmeticExpression"

Permission 10

/per/cql2-json/basic-cql2

The server MAY not support

the schema component "#/$defs/propertyRef" in an operand of a comparison operator, standardized spatial, temporal or array comparison functions starting with the second operand,
the schema components "#/$defs/characterExpression", "#/$defs/numericExpression", "#/$defs/spatialInstance", "#/$defs/instantInstance", "#/$defs/intervalInstance", "#/$defs/array", "#/$defs/functionRef", or a boolean literal in the first operand of a comparison operator, standardized spatial, temporal or array comparison function.

Requirement 34

/req/cql2-text/advanced-comparison-operators

Condition

Server implements requirements class Advanced Comparison Operators

In addition to the Basic CQL2 requirement, the server SHALL be able to parse and evaluate filter expressions encoded as JSON that use the following schema components:

"#/$defs/isLikePredicate"
"#/$defs/isBetweenPredicate"
"#/$defs/isInListPredicate"

Requirement 35

/req/cql2-text/case-insensitive-comparison

Condition

Server implements requirements class Case-insensitive Comparisons

In addition to the Basic CQL2 requirement, the server SHALL be able to parse and evaluate filter expressions encoded as JSON that use the following schema component:

"#/$defs/casei"

Requirement 36

/req/cql2-text/accent-insensitive-comparison

Condition

Server implements requirements class Accent-insensitive Comparisons

In addition to the Basic CQL2 requirement, the server SHALL be able to parse and evaluate filter expressions encoded as JSON that use the following schema component:

"#/$defs/accenti"

Requirement 37

/req/cql2-json/basic-spatial-functions

Condition

Server implements requirements class Basic Spatial Functions

The server SHALL be able to parse and evaluate filter expressions encoded as JSON that use the following schema components:

"#/$defs/spatialPredicate" where property "op" has the value "s_intersects"
"#/$defs/spatialInstance" where the value is either "#/$defs/point" or "#/$defs/bboxLiteral"

Requirement 38

/req/cql2-json/basic-spatial-functions-plus

Condition

Server implements requirements class Basic Spatial Functions with additional Spatial Literals

The server SHALL be able to parse and evaluate filter expressions encoded as JSON that use the following schema components:

"#/$defs/spatialPredicate" where property "op" has the value "s_intersects"

Requirement 39

/req/cql2-json/spatial-functions

Condition

Server implements requirements class Spatial Functions

The server SHALL be able to parse and evaluate filter expressions encoded as JSON that use the following schema components:

"#/$defs/spatialPredicate"

Requirement 40

/req/cql2-json/temporal-functions

Condition

Server implements requirements class Temporal Functions

In addition to the Basic CQL2 requirement, the server SHALL be able to parse and evaluate filter expressions encoded as JSON that use the following schema components:

"#/$defs/temporalPredicate"

Requirement 41

/req/cql2-json/arrays

Condition

Server implements requirements class Array Functions

In addition to the Basic CQL2 requirement, the server SHALL be able to parse and evaluate filter expressions encoded as JSON that use the following schema component:

"#/$defs/arrayPredicate"

Requirement 42

/req/cql2-json/property-property

Condition

Server implements requirements class Property-Property Comparisons

In addition to the Basic CQL2 requirement, the server SHALL be able to parse and evaluate filter expressions encoded as JSON that use

the schema component "#/$defs/propertyRef" in an operand of a comparison operator, standardized spatial, temporal or array comparison function starting with the second operand,
the schema components "#/$defs/characterExpression", "#/$defs/numericExpression", "#/$defs/spatialInstance", "#/$defs/instantInstance", "#/$defs/intervalInstance", "#/$defs/array", "#/$defs/functionRef", or a boolean literal in the first operand of a comparison operator, standardized spatial, temporal or array comparison function.

Requirement 43

/req/cql2-json/functions

Condition

Server implements requirements class Functions

In addition to the Basic CQL2 requirement, the server SHALL be able to parse and evaluate filter expressions encoded as JSON that use the following schema component:

"#/$defs/functionRef"

Requirement 44

/req/cql2-json/arithmetic

Condition

Server implements requirements class Arithmetic Expressions

In addition to the Basic CQL2 requirement, the server SHALL be able to parse and evaluate filter expressions encoded as JSON that use the following schema component:

"#/$defs/arithmeticExpression"

8.4. XML encoding

This document does not specifically define an XML-encoding for CQL2. However, it is recognized that XML is still in common use and so implementers are directed to review the OGC Filter Encoding 2.0 standard which defines an XML-encoding for filter expressions that closely matches most of the functionality of CQL2.

9. Media Types

No media type has been registered for the CQL2 encodings. The reason is the assumption that filter expressions as such will rarely be used as standalone documents, but usually be part of another document, e.g. a HTTP request or response, and be embedded in it.

Annex A: Abstract Test Suite (Normative)

This test suite uses the Given-When-Then notation to specify the tests.

Each implementation under test supports the evaluation of filter expressions on one or more data sources. A data source may be, for example, a feature collection in an OGC Web API that implements the OGC API - Features Standard. The implementation must declare the queryable properties (queryables) for each data source.

The requirements specified in this Standard can only be tested, if the test can assess whether the result of an evaluation matches the filter expression. However, in general, the queryables may not be part of the response; that is, it is not possible to perform such an assessment in general without knowledge about the data and the relationship between the queryables and the data. In addition, to assess the implementation of some requirements (e.g., case folding) the test needs to know the data.

With just the knowledge about the queryables and their data types, the tests can typically assess that valid filter expressions for a set of queryables are evaluated without an error. These tests are basic tests specified in this test suite and can be executed against any data.

In addition, to properly test an implementation, conditional tests are provided, if the implementation operates on a test dataset and where the queryables are properties of the features.

The test dataset contains feature types with point, line string and polygon geometries. It is available as a GeoPackage file with the associated queryables specified in JSON Schema for each feature collection in the OGC API Features GitHub repository. The test dataset has been derived from three layers of the Natural Earth vector dataset at scale 1:110 million (ne_110m_admin_0_countries, ne_110m_populated_places_simple, ne_110m_rivers_lake_centerlines). Some columns have been removed and a few columns have been added with random data in order to also test filter expressions on date, timestamp and boolean properties.

The tests assume that

all feature properties are also queryables;
the queryable for the feature geometry is geom.

All eleven conformance classes for the standardization target type "servers that evaluate filter expressions" have the following parameter:

Filter Language: The CQL2 encoding to be used in the test, either "CQL2 Text" or "CQL2 JSON".

General rules for the encoding of all filter expressions in tests:

The conformance tests in this annex are specified using the CQL2 BNF grammar. Depending on the Filter Language parameter, the filter expressions have to be instantiated in an executable test as CQL2 Text or CQL2 JSON;
If a property name in a filter expression is a reserved CQL2 keyword, the property name has to be placed in double quotes.

Executable test suites for the eleven conformance classes will also need to decide on the following questions and support at least one option per question:

How to execute the evaluation of a filter expression for a data source? At a minimum, Web API endpoints specified in OGC API - Features - Part 3: Filtering, requirements class "Filter", should be supported;
What are the queryables for a data source? At a minimum, queryables specified using JSON Schema, see OGC API - Features - Part 3: Filtering, requirements class "Filter", should be supported;
What is the format of the response that matches the filter expression? At a minimum, GeoJSON feature collections should be supported.

To qualify as an OGC Reference Implementation for CQL2, an implementation under test has to

support the tests with the test dataset;
support both CQL2 Text and CQL2 JSON;
support at least the conformance classes "Case-insensitive comparison", "Spatial functions" and "Temporal functions" (including all dependencies).

A.1. Conformance Class "CQL2 Text"

Conformance Class

http://www.opengis.net/spec/cql2/1.0/conf/cql2-text

Target type

Servers that evaluate filter expressions

Requirements class

Requirements Class "CQL2 Text"

Dependency

Conditional Dependency

Case-insensitive Comparisons

Conditional Dependency

Conditional Dependency

Accent-insensitive Comparisons

Conditional Dependency

Basic Spatial Functions with additional Spatial Literals

Conditional Dependency

Conditional Dependency

Spatial Functions

Conditional Dependency

Temporal Functions

Conditional Dependency

Array Functions

Conditional Dependency

Property-Property Comparisons

Conditional Dependency

Functions

Conditional Dependency

Arithmetic Expressions

A.1.1. Conformance Test 1

Test id:

/conf/cql2-text/validate

Requirements:

all requirements

Test purpose:

Validate that CQL2 Text is supported by the server

Test method:

Given:

When:

Execute conformance tests for all supported conformance classes with the parameter "Filter Language". Use the value "CQL2 Text".

Then:

assert that all conformance tests are successful.

A.1.2. Conformance Test 2

Test id:

/conf/cql2-text/escaping

Requirements:

/req/cql2-text/escaping

Test purpose:

Test escaping in string literals.

Test method:

Given:

One or more data sources containing string literals with embedded single quotation (') and/or BELL, and/or BACKSPACE, and/or HORIZONTAL TAB, and/or NEWLINE, and/or VERTICAL TAB, and/or FORM FEED, and/or CARRIAGE RETURN characters.

When:

Decode each string literal.

Then:

assert that the escaped embedded characters have been correctly recovered.

A.2. Conformance Class "CQL2 JSON"

Conformance Class

http://www.opengis.net/spec/cql2/1.0/conf/cql2-json

Target type

Servers that evaluate filter expressions

Requirements class

Requirements Class "CQL2 JSON"

Dependency

Conditional Dependency

Case-insensitive Comparisons

Conditional Dependency

Conditional Dependency

Accent-insensitive Comparisons

Conditional Dependency

Basic Spatial Functions with additional Spatial Literals

Conditional Dependency

Conditional Dependency

Spatial Functions

Conditional Dependency

Temporal Functions

Conditional Dependency

Array Functions

Conditional Dependency

Property-Property Comparisons

Conditional Dependency

Functions

Conditional Dependency

Arithmetic Expressions

A.2.1. Conformance Test 3

Test id:

/conf/cql2-json/validate

Requirements:

all requirements

Test purpose:

Validate that CQL2 JSON is supported by the server

Test method:

Given:

A filter expression

When:

Execute conformance tests for all supported conformance classes with the parameter "Filter Language". Use the value "CQL2 JSON". Note that the filter expressions in the test cases have to be converted to a CQL2 JSON representation.

Then:

assert the validation is successful.

A.3. Conformance Class "Basic-CQL2"

Conformance Class

http://www.opengis.net/spec/cql2/1.0/conf/basic-cql2

Target type

Servers that evaluate filter expressions

Parameter

Filter Language: "CQL2 Text" or "CQL2 JSON"

Requirements class

Requirements Class "Basic-CQL2"

A.3.1. Conformance Test 4

Test id:

/conf/basic-cql2/basic-test

Requirements:

n/a

Test purpose:

Implementation under test provides sufficient information to construct filter expressions and supports comparison predicates

Test method:

Given:

One or more data sources, each with a list of queryables.

When:

n/a

Then:

assert that there is at least one queryable for each data source;
assert that the data type (String, Number, Integer, Boolean, Timestamp, Date, Interval, Point, MultiPoint, LineString, MultiLineString, Polygon, MultiPolygon, Geometry, GeometryCollection, or Array) is specified for each queryable;
assert that at least one queryable for each data source is of data type String, Boolean, Number, Integer, Timestamp or Date.

A.3.2. Conformance Test 5

Test id:

/conf/basic-cql2/comparison

Requirements:

/req/basic-cql2/cql2-filter, /req/basic-cql2/property, /req/basic-cql2/binary-comparison-predicate

Test purpose:

Test comparison predicates

Test method:

Given:

One or more data sources, each with a list of queryables.
Test '/conf/basic-cql2/basic-test' passes.

When:

For each queryable {queryable} of one of the data types String, Boolean, Number, Integer, Timestamp or Date, evaluate the following filter expressions

{queryable} = {value}
{queryable} <> {value}
{queryable} > {value}
{queryable} < {value}
{queryable} >= {value}
{queryable} <= {value}

where {value} depends on the data type:

String: 'foo'
Boolean: true
Number: 3.14
Integer: 1
Timestamp: TIMESTAMP('2022-04-14T14:48:46Z')
Date: DATE('2022-04-14')

Then:

assert successful execution of the evaluation;
assert that the two result sets for each queryable for the operators = and <> have no item in common;
assert that the two result sets for each queryable for the operators > and <= have no item in common;
assert that the two result sets for each queryable for the operators < and >= have no item in common;
store the valid predicates for each data source.

A.3.3. Conformance Test 6

Test id:

/conf/basic-cql2/is-null

Requirements:

/req/basic-cql2/cql2-filter, /req/basic-cql2/property, /req/basic-cql2/null-predicate

Test purpose:

Test IS NULL predicate

Test method:

Given:

One or more data sources, each with a list of queryables.
Test '/conf/basic-cql2/basic-test' passes.

When:

For each queryable {queryable}, evaluate the following filter expressions

{queryable} IS NULL
{queryable} is not null

Then:

assert successful execution of the evaluation;
assert that the two result sets for each queryable have no item in common;
store the valid predicates for each data source.

A.3.4. Conformance Test 7

Test id:

/conf/basic-cql2/boolean

Requirements:

/req/basic-cql2/cql2-filter

Test purpose:

Test boolean filter expression

Test method:

Given:

One or more data sources.
Test '/conf/basic-cql2/basic-test' passes.

When:

For each data source, evaluate the following filter expressions

true
false

Then:

assert successful execution of the evaluation;
assert that the result sets for false are empty;
store the valid predicates for each data source.

A.3.5. Conformance Test 8

Test id:

/conf/basic-cql2/test-data

Requirements:

all requirements

Test purpose:

Test predicates against the test dataset

Test method:

Given:

The implementation under test uses the test dataset.

When:

Evaluate each predicate in Predicates and expected results.

Then:

assert successful execution of the evaluation;
assert that the expected result is returned;
store the valid predicates for each data source.

Table 7. Predicates and expected results
Data Source	Predicate	Expected number of items
ne_110m_admin_0_countries	`NAME='Luxembourg'`	1
ne_110m_admin_0_countries	`NAME>='Luxembourg'`	84
ne_110m_admin_0_countries	`NAME>'Luxembourg'`	83
ne_110m_admin_0_countries	`NAME<='Luxembourg'`	94
ne_110m_admin_0_countries	`NAME<'Luxembourg'`	93
ne_110m_admin_0_countries	`NAME<>'Luxembourg'`	176
ne_110m_admin_0_countries	`POP_EST=37589262`	1
ne_110m_admin_0_countries	`POP_EST>=37589262`	39
ne_110m_admin_0_countries	`POP_EST>37589262`	38
ne_110m_admin_0_countries	`POP_EST<=37589262`	139
ne_110m_admin_0_countries	`POP_EST<37589262`	138
ne_110m_admin_0_countries	`POP_EST<>37589262`	176
ne_110m_populated_places_simple	`name IS NOT NULL`	243
ne_110m_populated_places_simple	`name IS NULL`	0
ne_110m_populated_places_simple	`name='København'`	1
ne_110m_populated_places_simple	`name>='København'`	137
ne_110m_populated_places_simple	`name>'København'`	136
ne_110m_populated_places_simple	`name<='København'`	107
ne_110m_populated_places_simple	`name<'København'`	106
ne_110m_populated_places_simple	`name<>'København'`	242
ne_110m_populated_places_simple	`pop_other IS NOT NULL`	243
ne_110m_populated_places_simple	`pop_other IS NULL`	0
ne_110m_populated_places_simple	`pop_other=1038288`	1
ne_110m_populated_places_simple	`pop_other>=1038288`	123
ne_110m_populated_places_simple	`pop_other>1038288`	122
ne_110m_populated_places_simple	`pop_other<=1038288`	121
ne_110m_populated_places_simple	`pop_other<1038288`	120
ne_110m_populated_places_simple	`pop_other<>1038288`	242
ne_110m_populated_places_simple	`"date" IS NOT NULL`	3
ne_110m_populated_places_simple	`"date" IS NULL`	240
ne_110m_populated_places_simple	`"date"=DATE('2022-04-16')`	1
ne_110m_populated_places_simple	`"date">=DATE('2022-04-16')`	2
ne_110m_populated_places_simple	`"date">DATE('2022-04-16')`	1
ne_110m_populated_places_simple	`"date"<=DATE('2022-04-16')`	2
ne_110m_populated_places_simple	`"date"<DATE('2022-04-16')`	1
ne_110m_populated_places_simple	`"date"<>DATE('2022-04-16')`	2
ne_110m_populated_places_simple	`start IS NOT NULL`	3
ne_110m_populated_places_simple	`start IS NULL`	240
ne_110m_populated_places_simple	`start=TIMESTAMP('2022-04-16T10:13:19Z')`	1
ne_110m_populated_places_simple	`start<=TIMESTAMP('2022-04-16T10:13:19Z')`	2
ne_110m_populated_places_simple	`start<TIMESTAMP('2022-04-16T10:13:19Z')`	1
ne_110m_populated_places_simple	`start>=TIMESTAMP('2022-04-16T10:13:19Z')`	2
ne_110m_populated_places_simple	`start>TIMESTAMP('2022-04-16T10:13:19Z')`	1
ne_110m_populated_places_simple	`start<>TIMESTAMP('2022-04-16T10:13:19Z')`	2
ne_110m_populated_places_simple	`boolean IS NOT NULL`	3
ne_110m_populated_places_simple	`boolean IS NULL`	240
ne_110m_populated_places_simple	`boolean=true`	2
ne_110m_populated_places_simple	`boolean=false`	1

A.3.6. Conformance Test 9

Test id:

/conf/basic-cql2/logical

Requirements:

/req/basic-cql2/cql2-filter

Test purpose:

Test filter expressions with AND, OR and NOT including sub-expressions

Test method:

Given:

One or more data sources.
The stored predicates for each data source.

When:

Evaluate each predicate in Combinations of predicates and expected results.

For the data source 'ne_110m_populated_places_simple', evaluate the filter expression (NOT ({p2}) AND {p1}) OR ({p3} and {p4}) or not ({p1} OR {p4}) for each combination of predicates {p1} to {p4} in Combinations of predicates and expected results.

Then:

assert successful execution of the evaluation;
assert that the expected result is returned.

Table 8. Combinations of predicates and expected results
p1	p2	p3	p4	Expected number of items
`pop_other<>1038288`	`name<>'København'`	`pop_other IS NULL`	`name<'København'`	1
`pop_other<>1038288`	`name>'København'`	`name<='København'`	`boolean=true`	107
`start IS NULL`	`pop_other IS NOT NULL`	`pop_other IS NOT NULL`	`pop_other>1038288`	124
`pop_other<1038288`	`pop_other>1038288`	`pop_other IS NULL`	`start<TIMESTAMP('2022-04-16T10:13:19Z')`	121
`start=TIMESTAMP('2022-04-16T10:13:19Z')`	`pop_other<1038288`	`start=TIMESTAMP('2022-04-16T10:13:19Z')`	`name<>'København'`	2
`start<=TIMESTAMP('2022-04-16T10:13:19Z')`	`name<>'København'`	`boolean=true`	`name<'København'`	2
`pop_other=1038288`	`start IS NULL`	`start<>TIMESTAMP('2022-04-16T10:13:19Z')`	`boolean IS NOT NULL`	242
`start IS NULL`	`pop_other>1038288`	`start IS NOT NULL`	`name>'København'`	122
`pop_other<1038288`	`name<>'København'`	`name='København'`	`start<TIMESTAMP('2022-04-16T10:13:19Z')`	2
`start>=TIMESTAMP('2022-04-16T10:13:19Z')`	`name IS NOT NULL`	`start IS NULL`	`pop_other<1038288`	120
`name>='København'`	`start IS NOT NULL`	`boolean=true`	`start>=TIMESTAMP('2022-04-16T10:13:19Z')`	137
`start IS NOT NULL`	`name>='København'`	`start IS NOT NULL`	`name IS NOT NULL`	3
`name IS NULL`	`name<'København'`	`pop_other IS NOT NULL`	`boolean IS NOT NULL`	243
`start>=TIMESTAMP('2022-04-16T10:13:19Z')`	`name>'København'`	`pop_other=1038288`	`name<'København'`	3
`start<TIMESTAMP('2022-04-16T10:13:19Z')`	`name<='København'`	`boolean IS NULL`	`name>'København'`	138
`pop_other IS NOT NULL`	`start IS NULL`	`pop_other>=1038288`	`name>'København'`	62
`name='København'`	`start=TIMESTAMP('2022-04-16T10:13:19Z')`	`boolean=true`	`pop_other IS NULL`	243
`name>'København'`	`pop_other<1038288`	`pop_other>1038288`	`name<='København'`	122
`pop_other<>1038288`	`name='København'`	`name<='København'`	`start>TIMESTAMP('2022-04-16T10:13:19Z')`	243
`start<TIMESTAMP('2022-04-16T10:13:19Z')`	`start>=TIMESTAMP('2022-04-16T10:13:19Z')`	`pop_other=1038288`	`start IS NULL`	3
`name<>'København'`	`boolean=true`	`start=TIMESTAMP('2022-04-16T10:13:19Z')`	`start IS NULL`	2
`name IS NULL`	`start<>TIMESTAMP('2022-04-16T10:13:19Z')`	`start<TIMESTAMP('2022-04-16T10:13:19Z')`	`name IS NULL`	243
`start<>TIMESTAMP('2022-04-16T10:13:19Z')`	`name>'København'`	`start<=TIMESTAMP('2022-04-16T10:13:19Z')`	`name IS NOT NULL`	3
`name<>'København'`	`pop_other<>1038288`	`pop_other<1038288`	`start>=TIMESTAMP('2022-04-16T10:13:19Z')`	2
`boolean IS NULL`	`pop_other>1038288`	`boolean IS NOT NULL`	`pop_other IS NULL`	122
`pop_other=1038288`	`start IS NULL`	`start>TIMESTAMP('2022-04-16T10:13:19Z')`	`pop_other IS NOT NULL`	2
`pop_other<>1038288`	`start IS NULL`	`pop_other>1038288`	`boolean=true`	2
`start>TIMESTAMP('2022-04-16T10:13:19Z')`	`pop_other<1038288`	`name<='København'`	`pop_other=1038288`	2
`start>=TIMESTAMP('2022-04-16T10:13:19Z')`	`start<=TIMESTAMP('2022-04-16T10:13:19Z')`	`name<='København'`	`name<>'København'`	107
`boolean=true`	`name IS NOT NULL`	`boolean IS NULL`	`pop_other=1038288`	1
`start=TIMESTAMP('2022-04-16T10:13:19Z')`	`pop_other=1038288`	`pop_other<1038288`	`name<>'København'`	122
`pop_other<>1038288`	`start<=TIMESTAMP('2022-04-16T10:13:19Z')`	`start IS NOT NULL`	`start=TIMESTAMP('2022-04-16T10:13:19Z')`	3
`name<>'København'`	`pop_other<>1038288`	`pop_other IS NOT NULL`	`name IS NOT NULL`	243
`name='København'`	`pop_other<1038288`	`start IS NOT NULL`	`pop_other<>1038288`	3
`name<'København'`	`start<>TIMESTAMP('2022-04-16T10:13:19Z')`	`start>TIMESTAMP('2022-04-16T10:13:19Z')`	`start=TIMESTAMP('2022-04-16T10:13:19Z')`	2
`boolean=true`	`pop_other<1038288`	`name IS NOT NULL`	`start<=TIMESTAMP('2022-04-16T10:13:19Z')`	3
`pop_other<=1038288`	`name<'København'`	`pop_other<1038288`	`pop_other<1038288`	243
`pop_other IS NULL`	`name<='København'`	`name='København'`	`start>TIMESTAMP('2022-04-16T10:13:19Z')`	2
`pop_other<1038288`	`name<>'København'`	`pop_other<>1038288`	`name<>'København'`	243
`start<=TIMESTAMP('2022-04-16T10:13:19Z')`	`pop_other IS NULL`	`start<TIMESTAMP('2022-04-16T10:13:19Z')`	`name IS NOT NULL`	2
`start<>TIMESTAMP('2022-04-16T10:13:19Z')`	`name='København'`	`boolean IS NULL`	`pop_other<>1038288`	241
`boolean=true`	`pop_other<=1038288`	`name<>'København'`	`pop_other IS NULL`	2
`name IS NOT NULL`	`pop_other<=1038288`	`start IS NOT NULL`	`boolean IS NOT NULL`	124
`pop_other<=1038288`	`pop_other<1038288`	`start>TIMESTAMP('2022-04-16T10:13:19Z')`	`pop_other>1038288`	1
`start IS NOT NULL`	`boolean IS NOT NULL`	`name>='København'`	`pop_other IS NOT NULL`	137
`start<>TIMESTAMP('2022-04-16T10:13:19Z')`	`start IS NOT NULL`	`pop_other>1038288`	`pop_other<1038288`	1
`pop_other<=1038288`	`name<='København'`	`boolean IS NULL`	`start IS NOT NULL`	198
`name>='København'`	`name>='København'`	`name<='København'`	`name>='København'`	107
`boolean=true`	`start<TIMESTAMP('2022-04-16T10:13:19Z')`	`boolean IS NOT NULL`	`name<'København'`	2
`start>TIMESTAMP('2022-04-16T10:13:19Z')`	`start>=TIMESTAMP('2022-04-16T10:13:19Z')`	`pop_other IS NULL`	`pop_other<=1038288`	1
`pop_other<1038288`	`name='København'`	`start>=TIMESTAMP('2022-04-16T10:13:19Z')`	`name<'København'`	181
`pop_other<1038288`	`pop_other<=1038288`	`pop_other IS NULL`	`start IS NOT NULL`	121
`name>='København'`	`pop_other>=1038288`	`boolean=true`	`name IS NOT NULL`	79
`boolean IS NULL`	`name<>'København'`	`boolean IS NULL`	`pop_other IS NOT NULL`	240
`pop_other<1038288`	`start>=TIMESTAMP('2022-04-16T10:13:19Z')`	`name>'København'`	`pop_other<=1038288`	199
`name<='København'`	`start>TIMESTAMP('2022-04-16T10:13:19Z')`	`name<'København'`	`boolean IS NULL`	106
`pop_other IS NOT NULL`	`name<>'København'`	`pop_other<1038288`	`pop_other<=1038288`	121
`name>='København'`	`start IS NOT NULL`	`name>='København'`	`name IS NOT NULL`	137
`pop_other<1038288`	`start<TIMESTAMP('2022-04-16T10:13:19Z')`	`name IS NULL`	`pop_other>=1038288`	1
`pop_other>=1038288`	`name>'København'`	`boolean IS NOT NULL`	`start IS NOT NULL`	184
`start IS NOT NULL`	`name<>'København'`	`name<='København'`	`name IS NULL`	241
`name>='København'`	`pop_other<>1038288`	`start=TIMESTAMP('2022-04-16T10:13:19Z')`	`name<>'København'`	2
`boolean IS NOT NULL`	`pop_other<=1038288`	`pop_other=1038288`	`start=TIMESTAMP('2022-04-16T10:13:19Z')`	1
`name IS NOT NULL`	`start IS NOT NULL`	`start IS NOT NULL`	`name>='København'`	241
`pop_other=1038288`	`pop_other IS NOT NULL`	`start IS NOT NULL`	`name<>'København'`	2
`start=TIMESTAMP('2022-04-16T10:13:19Z')`	`start IS NULL`	`pop_other>1038288`	`pop_other<=1038288`	1
`name IS NULL`	`start IS NOT NULL`	`start=TIMESTAMP('2022-04-16T10:13:19Z')`	`name IS NOT NULL`	1
`boolean IS NOT NULL`	`name='København'`	`boolean IS NOT NULL`	`name IS NOT NULL`	3
`pop_other<>1038288`	`pop_other<>1038288`	`pop_other=1038288`	`pop_other<=1038288`	1
`pop_other IS NULL`	`start<>TIMESTAMP('2022-04-16T10:13:19Z')`	`start>TIMESTAMP('2022-04-16T10:13:19Z')`	`boolean IS NOT NULL`	241
`start<TIMESTAMP('2022-04-16T10:13:19Z')`	`boolean IS NULL`	`start>TIMESTAMP('2022-04-16T10:13:19Z')`	`name<'København'`	2
`pop_other>1038288`	`pop_other<>1038288`	`start<>TIMESTAMP('2022-04-16T10:13:19Z')`	`name<>'København'`	2
`start>=TIMESTAMP('2022-04-16T10:13:19Z')`	`start=TIMESTAMP('2022-04-16T10:13:19Z')`	`pop_other=1038288`	`name IS NOT NULL`	2
`pop_other<=1038288`	`start IS NOT NULL`	`start<=TIMESTAMP('2022-04-16T10:13:19Z')`	`boolean IS NOT NULL`	242
`boolean=true`	`start>TIMESTAMP('2022-04-16T10:13:19Z')`	`pop_other<1038288`	`pop_other<>1038288`	122
`pop_other>=1038288`	`pop_other>1038288`	`boolean IS NULL`	`pop_other=1038288`	121
`name<'København'`	`pop_other>1038288`	`start=TIMESTAMP('2022-04-16T10:13:19Z')`	`boolean=true`	44

A.4. Conformance Class "Advanced Comparison Operators"

Conformance Class

http://www.opengis.net/spec/cql2/1.0/conf/advanced-comparison-operators

Target type

Servers that evaluate filter expressions

Parameter

Filter Language: "CQL2 Text" or "CQL2 JSON"

Requirements class

Dependency

/req/advanced-comparison-operators/like-predicate

A.4.1. Conformance Test 10

Test id:

/conf/advanced-comparison-operators/like

Requirements:

Test purpose:

Test LIKE predicate

Test method:

Given:

One or more data sources, each with a list of queryables.

When:

For each queryable {queryable} of type String, evaluate the following filter expressions

{queryable} LIKE '%'
{queryable} like '_%'
{queryable} like ''
{queryable} like '%%'
{queryable} like '\\%\\_'

Then:

assert successful execution of the evaluation;
assert that the two result sets for each queryable for the pattern expression '_%' and '' have no item in common;
assert that the two result sets for each queryable for the pattern expression '%' and '%%' are identical;
store the valid predicates for each data source.

A.4.2. Conformance Test 11

Test id:

/conf/advanced-comparison-operators/between

Requirements:

/req/advanced-comparison-operators/between-predicate

Test purpose:

Test BETWEEN predicate

Test method:

Given:

One or more data sources, each with a list of queryables.

When:

for each queryable {queryable} of type Number or Integer, evaluate the following filter expressions

{queryable} BETWEEN 0 AND 100
{queryable} between 100.0 and 1.0

Then:

assert successful execution of the evaluation;
store the valid predicates for each data source.

A.4.3. Conformance Test 12

Test id:

/conf/advanced-comparison-operators/in

Requirements:

/req/advanced-comparison-operators/in-predicate

Test purpose:

Test IN predicate

Test method:

Given:

One or more data sources, each with a list of queryables.

When:

for each queryable {queryable} of type Number or Integer, evaluate the following filter expression {queryable} IN (1, 2, 3);
for each queryable {queryable} of type String, evaluate the following filter expression {queryable} in ('foo', 'bar');
for each queryable {queryable} of type Boolean, evaluate the following filter expression {queryable} in (true);
for each queryable {queryable} of type Timestamp, evaluate the following filter expression {queryable} in ('2022-04-14T14:52:56Z', '2022-04-14T15:52:56Z');
for each queryable {queryable} of type Date, evaluate the following filter expression {queryable} in ('2022-04-14', '2022-04-15');

Then:

assert successful execution of the evaluation;
store the valid predicates for each data source.

A.4.4. Conformance Test 13

Test id:

/conf/advanced-comparison-operators/test-data

Requirements:

all requirements

Test purpose:

Test predicates against the test dataset

Test method:

Given:

The implementation under test uses the test dataset.

When:

Evaluate each predicate in Predicates and expected results.

Then:

assert successful execution of the evaluation;
assert that the expected result is returned;
store the valid predicates for each data source.

Table 9. Predicates and expected results
Data Source	Predicate	Expected number of items
ne_110m_populated_places_simple	`name LIKE 'B_r%'`	3
ne_110m_populated_places_simple	`name NOT LIKE 'B_r%'`	240
ne_110m_populated_places_simple	`pop_other between 1000000 and 3000000`	75
ne_110m_populated_places_simple	`pop_other not between 1000000 and 3000000`	168
ne_110m_populated_places_simple	`name IN ('Kiev','kobenhavn','Berlin','athens','foo')`	2
ne_110m_populated_places_simple	`name NOT IN ('Kiev','kobenhavn','Berlin','athens','foo')`	241
ne_110m_populated_places_simple	`pop_other in (1038288,1611692,3013258,3013257,3013259)`	3
ne_110m_populated_places_simple	`pop_other not in (1038288,1611692,3013258,3013257,3013259)`	240
ne_110m_populated_places_simple	`"date" in (DATE('2021-04-16'),DATE('2022-04-16'),DATE('2022-04-18'))`	2
ne_110m_populated_places_simple	`"date" not in (DATE('2021-04-16'),DATE('2022-04-16'),DATE('2022-04-18'))`	1
ne_110m_populated_places_simple	`start in (TIMESTAMP('2022-04-16T10:13:19Z'))`	1
ne_110m_populated_places_simple	`start not in (TIMESTAMP('2022-04-16T10:13:19Z'))`	2
ne_110m_populated_places_simple	`boolean in (true)`	2
ne_110m_populated_places_simple	`boolean not in (false)`	2

A.4.5. Conformance Test 14

Test id:

/conf/advanced-comparison-operators/logical

Requirements:

n/a

Test purpose:

Test filter expressions with AND, OR and NOT including sub-expressions

Test method:

Given:

The stored predicates for each data source, including from the dependencies.

When:

For each data source, select at least 10 random combinations of four predicates ({p1} to {p4}) from the stored predicates and evaluate the filter expression ((NOT {p1} AND {p2}) OR ({p3} and NOT {p4}) or not ({p1} AND {p4})).

Then:

assert successful execution of the evaluation.

A.5. Conformance Class "Case-insensitive Comparison"

Conformance Class

http://www.opengis.net/spec/cql2/1.0/conf/case-insensitive-comparison

Target type

Servers that evaluate filter expressions

Parameter

Filter Language: "CQL2 Text" or "CQL2 JSON"

Requirements class

Requirements Class "Case-insensitive Comparison"

Dependency

Conditional Dependency

/req/case-insensitive-comparison/casei-function

A.5.1. Conformance Test 15

Test id:

/conf/case-insensitive-comparison/casei

Requirements:

Test purpose:

Test the CASEI function in comparisons

Test method:

Given:

One or more data sources, each with a list of queryables.

When:

For each queryable {queryable} of type String, evaluate the following filter expressions

CASEI({queryable}) = casei('foo')
CASEI({queryable}) <> casei('FOO')

Then:

assert successful execution of the evaluation;
assert that the two result sets for each queryable have no item in common;
store the valid predicates for each data source.

A.5.2. Conformance Test 16

Test id:

/conf/case-insensitive-comparison/casei-like

Requirements:

/req/case-insensitive-comparison/casei-function

Test purpose:

Test the CASEI function in LIKE predicates

Test method:

Given:

One or more data sources, each with a list of queryables.
The conformance class Advanced Comparison Operators passes.

When:

For each queryable {queryable} of type String, evaluate the following filter expressions

CASEI({queryable}) LIKE casei('foo%')
CASEI({queryable}) LIKE casei('FOO%')

Then:

assert successful execution of the evaluation;
assert that the two result sets for each queryable are identical;
store the valid predicates for each data source.

A.5.3. Conformance Test 17

Test id:

/conf/case-insensitive-comparison/test-data

Requirements:

all requirements

Test purpose:

Test predicates against the test dataset

Test method:

Given:

The implementation under test uses the test dataset.

When:

Evaluate each predicate in Predicates and expected results, if the conditional dependency is met.

Then:

assert successful execution of the evaluation;
assert that the expected result is returned;
store the valid predicates for each data source.

Table 10. Predicates and expected results
Dependency	Data Source	Predicate	Expected number of items
n/a	ne_110m_populated_places_simple	`CASEI(name)=casei('KIEV')`	1
n/a	ne_110m_populated_places_simple	`CASEI(name)=casei('kiev')`	1
n/a	ne_110m_populated_places_simple	`CASEI(name)=casei('Kiev')`	1
n/a	ne_110m_populated_places_simple	`CASEI(name)=casei('København')`	1
n/a	ne_110m_populated_places_simple	`CASEI(name)=casei('københavn')`	1
n/a	ne_110m_populated_places_simple	`CASEI(name)=casei('KØBENHAVN')`	1
Advanced Comparison Operators	ne_110m_populated_places_simple	`CASEI(name) LIKE casei('B_r%')`	3
Advanced Comparison Operators	ne_110m_populated_places_simple	`CASEI(name) LIKE casei('b_r%')`	3
Advanced Comparison Operators	ne_110m_populated_places_simple	`CASEI(name) LIKE casei('B_R%')`	3
Advanced Comparison Operators	ne_110m_populated_places_simple	`CASEI(name) IN (casei('Kiev'), casei('kobenhavn'), casei('Berlin'), casei('athens'), casei('foo'))`	3

A.5.4. Conformance Test 18

Test id:

/conf/case-insensitive-comparison/logical

Requirements:

n/a

Test purpose:

Test filter expressions with AND, OR and NOT including sub-expressions

Test method:

Given:

The stored predicates for each data source, including from the dependencies.

When:

Then:

assert successful execution of the evaluation.

A.6. Conformance Class "Accent-insensitive Comparison"

Conformance Class

http://www.opengis.net/spec/cql2/1.0/conf/accent-insensitive-comparison

Target type

Servers that evaluate filter expressions

Parameter

Filter Language: "CQL2 Text" or "CQL2 JSON"

Requirements class

Requirements Class "Accent-insensitive Comparison"

Dependency

Conditional Dependency

Case-insensitive Comparison

Conditional Dependency

A.6.1. Conformance Test 19

Test id:

/conf/accent-insensitive-comparison/accenti

Requirements:

/req/accent-insensitive-comparison/accenti-function

Test purpose:

Test the ACCENTI function in comparisons

Test method:

Given:

One or more data sources, each with a list of queryables.

When:

For each queryable {queryable} of type String, evaluate the following filter expressions

ACCENTI({queryable}) = accenti('äöüéáí')
ACCENTI({queryable}) <> accenti('aoueai')

Then:

assert successful execution of the evaluation;
assert that the two result sets for each queryable have no item in common;
store the valid predicates for each data source.

A.6.2. Conformance Test 20

Test id:

/conf/accent-insensitive-comparison/accenti-like

Requirements:

/req/accent-insensitive-comparison/accenti-function

Test purpose:

Test the ACCENTI function in LIKE predicates

Test method:

Given:

One or more data sources, each with a list of queryables.
The conformance class Advanced Comparison Operators passes.

When:

For each queryable {queryable} of type String, evaluate the following filter expressions

ACCENTI({queryable}) LIKE accenti('Ä%')
ACCENTI({queryable}) LIKE accenti('A%')

Then:

assert successful execution of the evaluation;
assert that the two result sets for each queryable are identical;
store the valid predicates for each data source.

A.6.3. Conformance Test 21

Test id:

/conf/accent-insensitive-comparison/accenti-casei

Requirements:

/req/accent-insensitive-comparison/accenti-function

Test purpose:

Test the ACCENTI function with the CASEI function

Test method:

Given:

One or more data sources, each with a list of queryables.
The conformance class Case-insensitive Comparison passes.

When:

For each queryable {queryable} of type String, evaluate the following filter expressions

ACCENTI(CASEI({queryable})) = accenti(casei('ÄÉ'))
ACCENTI(CASEI({queryable})) = accenti(casei('ae'))

Then:

assert successful execution of the evaluation;
assert that the two result sets for each queryable are identical;
store the valid predicates for each data source.

A.6.4. Conformance Test 22

Test id:

/conf/accent-insensitive-comparison/accenti-casei-like

Requirements:

/req/accent-insensitive-comparison/accenti-function

Test purpose:

Test the ACCENTI function with the CASEI function in LIKE predicates

Test method:

Given:

One or more data sources, each with a list of queryables.
The conformance class Case-insensitive Comparison passes.
The conformance class Advanced Comparison Operators passes.

When:

For each queryable {queryable} of type String, evaluate the following filter expressions

ACCENTI(CASEI({queryable})) LIKE accenti(casei('Ä%'))
ACCENTI(CASEI({queryable})) LIKE accenti(casei('a%'))

Then:

assert successful execution of the evaluation;
assert that the two result sets for each queryable are identical;
store the valid predicates for each data source.

A.6.5. Conformance Test 23

Test id:

/conf/accent-insensitive-comparison/test-data

Requirements:

all requirements

Test purpose:

Test predicates against the test dataset

Test method:

Given:

The implementation under test uses the test dataset.

When:

Evaluate each predicate in Predicates and expected results, if the conditional dependency is met.

Then:

assert successful execution of the evaluation;
assert that the expected result is returned;
store the valid predicates for each data source.

Table 11. Predicates and expected results
Dependency	Data Source	Predicate	Expected number of items
n/a	ne_110m_populated_places_simple	`ACCENTI(name)=accenti('Chișinău')`	1
n/a	ne_110m_populated_places_simple	`ACCENTI(name)=accenti('Chisinau')`	1
n/a	ne_110m_populated_places_simple	`ACCENTI(name)=accenti('Kiev')`	1
Case-insensitive Comparison	ne_110m_populated_places_simple	`ACCENTI(CASEI(name))=accenti(casei('chișinău'))`	1
Case-insensitive Comparison	ne_110m_populated_places_simple	`ACCENTI(CASEI(name))=accenti(casei('chisinau'))`	1
Case-insensitive Comparison	ne_110m_populated_places_simple	`ACCENTI(CASEI(name))=accenti(casei('CHISINAU'))`	1
Case-insensitive Comparison	ne_110m_populated_places_simple	`ACCENTI(CASEI(name))=accenti(casei('CHIȘINĂU'))`	1
Advanced Comparison Operators	ne_110m_populated_places_simple	`ACCENTI(name) LIKE accenti('Ch%')`	2
Case-insensitive Comparison, Advanced Comparison Operators	ne_110m_populated_places_simple	`ACCENTI(CASEI(name)) LIKE accenti(casei('Chiș%'))`	2
Case-insensitive Comparison, Advanced Comparison Operators	ne_110m_populated_places_simple	`ACCENTI(CASEI(name)) LIKE accenti(casei('cHis%'))`	2
Case-insensitive Comparison, Advanced Comparison Operators	ne_110m_populated_places_simple	`ACCENTI(CASEI(name)) IN (accenti(casei('Kiev')), accenti(casei('chișinău')), accenti(casei('Berlin')), accenti(casei('athens')), accenti(casei('foo')))`	4

A.6.6. Conformance Test 24

Test id:

/conf/accent-insensitive-comparison/logical

Requirements:

n/a

Test purpose:

Test filter expressions with AND, OR and NOT including sub-expressions

Test method:

Given:

The stored predicates for each data source, including from the dependencies.

When:

Then:

assert successful execution of the evaluation.

A.7. Conformance Class "Basic Spatial Functions"

Conformance Class

http://www.opengis.net/spec/cql2/1.0/conf/basic-spatial-functions

Target type

Servers that evaluate filter expressions

Parameter

Filter Language: "CQL2 Text" or "CQL2 JSON"

Requirements class

Dependency

/req/basic-spatial-functions/spatial-predicate, /req/basic-spatial-functions/spatial-functions, /req/basic-spatial-functions/spatial-data-types

The term "geometry data type" is used for the following data types: Point, MultiPoint, LineString, MultiLineString, Polygon, MultiPolygon, Geometry, or GeometryCollection.

A.7.1. Conformance Test 25

Test id:

/conf/basic-spatial-functions/s_intersects

Requirements:

Test purpose:

Test the S_INTERSECTS spatial comparison function with points and bounding boxes.

Test method:

Given:

One or more data sources, each with a list of queryables.
At least one queryable has a geometry data type.

When:

For each queryable {queryable} with a geometry data type, evaluate the following filter expressions

S_INTERSECTS({queryable},BBOX(-180,-90,180,90))
S_INTERSECTS({queryable},POINT(7.02 49.92))
S_INTERSECTS({queryable},POINT(90 180))
S_INTERSECTS({queryable},BBOX(-180,-90,-90,90)) AND S_INTERSECTS({queryable},BBOX(90,-90,180,90))

Then:

assert successful execution of the evaluation for the first two filter expressions;
assert unsuccessful execution of the evaluation for the third filter expressions (invalid coordinate);
store the valid predicates for each data source.

A.7.2. Conformance Test 26

Test id:

/conf/basic-spatial-functions/test-data

Requirements:

all requirements

Test purpose:

Test predicates against the test dataset

Test method:

Given:

The implementation under test uses the test dataset.

When:

Evaluate each predicate in Predicates and expected results.

Then:

assert successful execution of the evaluation;
assert that the expected result is returned;
store the valid predicates for each data source.

Table 12. Predicates and expected results
Data Source	Predicate	Expected number of items
ne_110m_admin_0_countries	`S_INTERSECTS(geom,BBOX(0,40,10,50))`	8
ne_110m_admin_0_countries	`S_INTERSECTS(geom,BBOX(150,-90,-150,90))`	10
ne_110m_admin_0_countries	`S_INTERSECTS(geom,POINT(7.02 49.92))`	1
ne_110m_admin_0_countries	`S_INTERSECTS(geom,BBOX(0,40,10,50)) and S_INTERSECTS(geom,BBOX(5,50,10,60))`	3
ne_110m_admin_0_countries	`S_INTERSECTS(geom,BBOX(0,40,10,50)) and not S_INTERSECTS(geom,BBOX(5,50,10,60))`	5
ne_110m_admin_0_countries	`S_INTERSECTS(geom,BBOX(0,40,10,50)) or S_INTERSECTS(geom,BBOX(-90,40,-60,50))`	10
ne_110m_populated_places_simple	`S_INTERSECTS(geom,BBOX(0,40,10,50))`	7
ne_110m_rivers_lake_centerlines	`S_INTERSECTS(geom,BBOX(-180,-90,0,90))`	4

A.7.3. Conformance Test 27

Test id:

/conf/basic-spatial-functions/logical

Requirements:

n/a

Test purpose:

Test filter expressions with AND, OR and NOT including sub-expressions

Test method:

Given:

The stored predicates for each data source, including from the dependencies.

When:

Then:

assert successful execution of the evaluation.

A.8. Conformance Class "Basic Spatial Functions with additional Spatial Literals"

Conformance Class

http://www.opengis.net/spec/cql2/1.0/conf/basic-spatial-functions-plus

Target type

Servers that evaluate filter expressions

Parameter

Filter Language: "CQL2 Text" or "CQL2 JSON"

Requirements class

Requirements Class "Basic Spatial Functions with additional Spatial Literals"

Dependency

/req/basic-spatial-functions-plus/spatial-predicate, /req/basic-spatial-functions-plus/spatial-functions, /req/basic-spatial-functions-plus/spatial-data-types

The term "geometry data type" is used for the following data types: Point, MultiPoint, LineString, MultiLineString, Polygon, MultiPolygon, or GeometryCollection.

A.8.1. Conformance Test 28

Test id:

/conf/basic-spatial-functions-plus/s_intersects

Requirements:

Test purpose:

Test the S_INTERSECTS spatial comparison function with points, multi-points, line strings, multi-line string, polygons, multi-polygons, geometry collections and bounding boxes.

Test method:

Given:

One or more data sources, each with a list of queryables.
At least one queryable has a geometry data type.

When:

For each queryable {queryable} with a geometry data type, evaluate the following filter expressions

S_INTERSECTS({queryable},MULTIPOINT(7.02 49.92, 90 180))
S_INTERSECTS({queryable},LINESTRING(-180 -45, 0 -45))
S_INTERSECTS({queryable},MULTILINESTRING((-180 -45, 0 -45), (0 45, 180 45)))
S_INTERSECTS({queryable},POLYGON((-180 -90, -90 -90, -90 90, -180 90, -180 -90), (-120 -50, -100 -50, -100 -40, -120 -40, -120 -50)))
S_INTERSECTS({queryable},MULTIPOLYGON(((-180 -90, -90 -90, -90 90, -180 90, -180 -90), (-120 -50, -100 -50, -100 -40, -120 -40, -120 -50)),((0 0, 10 0, 10 10, 0 10, 0 0))))
S_INTERSECTS({queryable},GEOMETRYCOLLECTION(POINT(7.02 49.92), POLYGON((0 0, 10 0, 10 10, 0 10, 0 0))))

Then:

assert successful execution of the evaluation for all filter expressions except the first;
assert unsuccessful execution of the evaluation for the first filter expressions (invalid coordinate);
store the valid predicates for each data source.

A.8.2. Conformance Test 29

Test id:

/conf/basic-spatial-functions-plus/test-data

Requirements:

all requirements

Test purpose:

Test predicates against the test dataset

Test method:

Given:

The implementation under test uses the test dataset.

When:

Evaluate each predicate in Predicates and expected results.

Then:

assert successful execution of the evaluation;
assert that the expected result is returned.

Table 13. Predicates and expected results
Data Source	Predicate	Expected number of items
ne_110m_admin_0_countries	`S_INTERSECTS(geom,LINESTRING(-180 -45, 0 -45))`	2
ne_110m_admin_0_countries	`S_INTERSECTS(geom,MULTILINESTRING((-180 -45, 0 -45), (0 45, 180 45)))`	14
ne_110m_admin_0_countries	`S_INTERSECTS(geom,POLYGON((-180 -90, -90 -90, -90 90, -180 90, -180 -90), (-120 -50, -100 -50, -100 -40, -120 -40, -120 -50)))`	8
ne_110m_admin_0_countries	`S_INTERSECTS(geom,MULTIPOLYGON(((-180 -90, -90 -90, -90 90, -180 90, -180 -90), (-120 -50, -100 -50, -100 -40, -120 -40, -120 -50)),((0 0, 10 0, 10 10, 0 10, 0 0))))`	15
ne_110m_admin_0_countries	`S_INTERSECTS(geom,GEOMETRYCOLLECTION(POINT(7.02 49.92), POLYGON((0 0, 10 0, 10 10, 0 10, 0 0))))`	8
ne_110m_admin_0_countries	`S_INTERSECTS(geom,POLYGON((-180 -90, -90 -90, -90 90, -180 90, -180 -90), (-120 -50, -100 -50, -100 -40, -120 -40, -120 -50))) or S_INTERSECTS(geom,POLYGON((0 0, 10 0, 10 10, 0 10, 0 0)))`	15
ne_110m_admin_0_countries	`S_INTERSECTS(geom,POLYGON((-180 -90, -90 -90, -90 90, -180 90, -180 -90), (-120 -50, -100 -50, -100 -40, -120 -40, -120 -50))) and not S_INTERSECTS(geom,POLYGON((-130 0, 0 0, 0 50, -130 50, -130 0)))`	3

A.9. Conformance Class "Spatial Functions"

Conformance Class

http://www.opengis.net/spec/cql2/1.0/conf/spatial-functions

Target type

Servers that evaluate filter expressions

Parameter

Filter Language: "CQL2 Text" or "CQL2 JSON"

Requirements class

Basic Spatial Functions with additional Spatial Literals

Dependency

A.9.1. Conformance Test 30

Test id:

/conf/spatial-functions/s_intersects

Requirements:

/req/spatial-functions/spatial-functions, /req/spatial-functions/spatial-data-types

Test purpose:

Test the S_INTERSECTS spatial function

Test method:

Given:

One or more data sources, each with a list of queryables.
At least one queryable has a geometry data type.

When:

For each queryable {queryable} with a geometry data type, evaluate the following filter expressions

S_INTERSECTS({queryable},BBOX(-180,-90,180,90))
S_INTERSECTS({queryable},POLYGON((-180 -90,180 -90,180 90,-180 90,-180 -90)))
S_INTERSECTS({queryable},LINESTRING(7 50, 10 51))
S_INTERSECTS({queryable},POINT(7.02 49.92))
S_INTERSECTS({queryable},POINT(90 180))

Then:

assert successful execution of the evaluation for the first four filter expressions;
assert unsuccessful execution of the evaluation for the fifth filter expressions (invalid coordinate);
assert that the two result sets of the first two filter expressions for each queryable are identical;
store the valid predicates for each data source.

A.9.2. Conformance Test 31

Test id:

/conf/spatial-functions/s_disjoint

Requirements:

/req/spatial-functions/spatial-functions, /req/spatial-functions/spatial-data-types

Test purpose:

Test the S_DISJOINT spatial function

Test method:

Given:

One or more data sources, each with a list of queryables.

When:

for each queryable {queryable} with a geometry data type, evaluate the following filter expressions

S_DISJOINT({queryable},BBOX(-180,-90,180,90))
S_DISJOINT({queryable},POLYGON((-180 -90,180 -90,180 90,-180 90,-180 -90)))
S_DISJOINT({queryable},LINESTRING(7 50,10 51))
S_DISJOINT({queryable},POINT(7.02 49.92))
S_DISJOINT({queryable},POINT(90 180))

Then:

assert successful execution of the evaluation for the first four filter expressions;
assert unsuccessful execution of the evaluation for the fifth filter expressions (invalid coordinate);
assert that the two result sets of the first two filter expressions for each queryable are empty;
assert that the results sets of the third and fourth filter expressions for each queryable do not have an item in common with the corresponding S_INTERSECTS expression;
store the valid predicates for each data source.

A.9.3. Conformance Test 32

Test id:

/conf/spatial-functions/s_equals

Requirements:

/req/spatial-functions/spatial-functions, /req/spatial-functions/spatial-data-types

Test purpose:

Test the S_EQUALS spatial function

Test method:

Given:

One or more data sources, each with a list of queryables.

When:

for each queryable {queryable} with a geometry data type, evaluate the following filter expressions

S_EQUALS({queryable},POLYGON((-180 -90,180 -90,180 90,-180 90,-180 -90)))
S_EQUALS({queryable},LINESTRING(7 50,10 51))
S_EQUALS({queryable},POINT(7.02 49.92))

Then:

assert successful execution of the evaluation;
assert that the two result sets of the first two filter expressions for each queryable are identical;
store the valid predicates for each data source.

A.9.4. Conformance Test 33

Test id:

/conf/spatial-functions/s_touches

Requirements:

/req/spatial-functions/spatial-functions, /req/spatial-functions/spatial-data-types

Test purpose:

Test the S_TOUCHES spatial function

Test method:

Given:

One or more data sources, each with a list of queryables.

When:

for each queryable {queryable} with a geometry data type, evaluate the following filter expressions

S_TOUCHES({queryable},BBOX(-180,-90,180,90))
S_TOUCHES({queryable},POLYGON((-180 -90,180 -90,180 90,-180 90,-180 -90)))
S_TOUCHES({queryable},LINESTRING(7 50,10 51))

Then:

assert successful execution of the evaluation;
store the valid predicates for each data source.

A.9.5. Conformance Test 34

Test id:

/conf/spatial-functions/s_crosses

Requirements:

/req/spatial-functions/spatial-functions, /req/spatial-functions/spatial-data-types

Test purpose:

Test the S_CROSSES spatial function

Test method:

Given:

One or more data sources, each with a list of queryables.

When:

for each queryable {queryable} of type Point, MultiPoint, LineString or MultiLineString, evaluate the following filter expressions

S_CROSSES({queryable},BBOX(-180,-90,180,90))
S_CROSSES({queryable},POLYGON((-180 -90,180 -90,180 90,-180 90,-180 -90)))
S_CROSSES({queryable},LINESTRING(7 50,10 51))

Then:

assert successful execution of the evaluation;
store the valid predicates for each data source.

A.9.6. Conformance Test 35

Test id:

/conf/spatial-functions/s_within

Requirements:

/req/spatial-functions/spatial-functions, /req/spatial-functions/spatial-data-types

Test purpose:

Test the S_WITHIN spatial function

Test method:

Given:

One or more data sources, each with a list of queryables.

When:

for each queryable {queryable} with a geometry data type, evaluate the following filter expressions

S_WITHIN({queryable},BBOX(-180,-90,180,90))
S_WITHIN({queryable},POLYGON((-180 -90,180 -90,180 90,-180 90,-180 -90)))
S_WITHIN({queryable},LINESTRING(7 50,10 51))
S_WITHIN({queryable},MULTIPOINT(7 50,10 51))

Then:

assert successful execution of the evaluation;
assert that the two result sets of the first two filter expressions for each queryable are identical;
store the valid predicates for each data source.

A.9.7. Conformance Test 36

Test id:

/conf/spatial-functions/s_contains

Requirements:

/req/spatial-functions/spatial-functions, /req/spatial-functions/spatial-data-types

Test purpose:

Test the S_CONTAINS spatial function

Test method:

Given:

One or more data sources, each with a list of queryables.

When:

for each queryable {queryable} with a geometry data type, evaluate the following filter expressions

S_CONTAINS({queryable},BBOX(-180,-90,180,90))
S_CONTAINS({queryable},POLYGON((-180 -90,180 -90,180 90,-180 90,-180 -90)))
S_CONTAINS({queryable},LINESTRING(7 50,10 51))
S_CONTAINS({queryable},MULTIPOINT(7 50,10 51))

Then:

assert successful execution of the evaluation;
assert that the two result sets of the first two filter expressions for each queryable are identical;
assert that the results sets for each queryable do not have an item in common with the corresponding S_WITHIN expression;
store the valid predicates for each data source.

A.9.8. Conformance Test 37

Test id:

/conf/spatial-functions/s_overlaps

Requirements:

/req/spatial-functions/spatial-functions, /req/spatial-functions/spatial-data-types

Test purpose:

Test the S_OVERLAPS spatial function

Test method:

Given:

One or more data sources, each with a list of queryables.

When:

For each queryable {queryable} of type Point or MultiPoint, evaluate the filter expression S_OVERLAPS({queryable},MULTIPOINT(7 50,10 51))
For each queryable {queryable} of type LineString or MultiLineString, evaluate the filter expression S_OVERLAPS({queryable},LINESTRING(7 50,10 51))
For each queryable {queryable} of type Polygon or MultiPolygon, evaluate the filter expression S_OVERLAPS({queryable},POLYGON((-180 -90,180 -90,180 90,-180 90,-180 -90)))

Then:

assert successful execution of the evaluation;
store the valid predicates for each data source.

A.9.9. Conformance Test 38

Test id:

/conf/spatial-functions/test-data

Requirements:

all requirements

Test purpose:

Test predicates against the test dataset

Test method:

Given:

The implementation under test uses the test dataset.

When:

Evaluate each predicate in Predicates and expected results.

Then:

assert successful execution of the evaluation;
assert that the expected result is returned;
store the valid predicates for each data source.

Table 14. Predicates and expected results
Data Source	Predicate	Expected number of items
ne_110m_admin_0_countries	`S_INTERSECTS(geom,POLYGON((0 40,10 40,10 50,0 50,0 40)))`	8
ne_110m_admin_0_countries	`S_INTERSECTS(geom,LINESTRING(0 40,10 50))`	4
ne_110m_populated_places_simple	`S_INTERSECTS(geom,POLYGON((0 40,10 40,10 50,0 50,0 40)))`	7
ne_110m_rivers_lake_centerlines	`S_INTERSECTS(geom,LINESTRING(-60 -90,-60 90))`	2
ne_110m_admin_0_countries	`S_DISJOINT(geom,BBOX(0,40,10,50))`	169
ne_110m_admin_0_countries	`S_DISJOINT(geom,POLYGON((0 40,10 40,10 50,0 50,0 40)))`	169
ne_110m_admin_0_countries	`S_DISJOINT(geom,LINESTRING(0 40,10 50))`	173
ne_110m_admin_0_countries	`S_DISJOINT(geom,POINT(7.02 49.92))`	176
ne_110m_populated_places_simple	`S_DISJOINT(geom,BBOX(0,40,10,50))`	236
ne_110m_populated_places_simple	`S_DISJOINT(geom,POLYGON((0 40,10 40,10 50,0 50,0 40)))`	236
ne_110m_rivers_lake_centerlines	`S_DISJOINT(geom,BBOX(-180,-90,0,90))`	9
ne_110m_rivers_lake_centerlines	`S_DISJOINT(geom,LINESTRING(-60 -90,-60 90))`	11
ne_110m_populated_places_simple	`S_EQUALS(geom,POINT(6.1300028 49.6116604))`	1
ne_110m_admin_0_countries	`S_TOUCHES(geom,POLYGON((6.043073357781111 50.128051662794235,6.242751092156993 49.90222565367873,6.186320428094177 49.463802802114515,5.897759230176348 49.44266714130711,5.674051954784829 49.529483547557504,5.782417433300907 50.09032786722122,6.043073357781111 50.128051662794235)))`	3
ne_110m_admin_0_countries	`S_TOUCHES(geom,POINT(6.043073357781111 50.128051662794235))`	3
ne_110m_admin_0_countries	`S_TOUCHES(geom,POINT(6.242751092156993 49.90222565367873))`	2
ne_110m_admin_0_countries	`S_TOUCHES(geom,LINESTRING(6.043073357781111 50.128051662794235,6.242751092156993 49.90222565367873))`	3
ne_110m_rivers_lake_centerlines	`S_CROSSES(geom,BBOX(0,40,10,50))`	1
ne_110m_rivers_lake_centerlines	`S_CROSSES(geom,LINESTRING(-60 -90,-60 90))`	2
ne_110m_admin_0_countries	`S_WITHIN(geom,BBOX(-180,-90,0,90))`	44
ne_110m_populated_places_simple	`S_WITHIN(geom,BBOX(-180,-90,0,90))`	74
ne_110m_rivers_lake_centerlines	`S_WITHIN(geom,BBOX(-180,-90,0,90))`	4
ne_110m_admin_0_countries	`S_CONTAINS(geom,BBOX(7,50,8,51))`	1
ne_110m_admin_0_countries	`S_CONTAINS(geom,LINESTRING(7 50,8 51))`	1
ne_110m_admin_0_countries	`S_CONTAINS(geom,POINT(7.02 49.92))`	1
ne_110m_admin_0_countries	`S_OVERLAPS(geom,BBOX(-180,-90,0,90))`	11

A.9.10. Conformance Test 39

Test id:

/conf/spatial-functions/logical

Requirements:

n/a

Test purpose:

Test filter expressions with AND, OR and NOT including sub-expressions

Test method:

Given:

The stored predicates for each data source, including from the dependencies.

When:

Then:

assert successful execution of the evaluation.

A.10. Conformance Class "Temporal Functions"

Conformance Class

http://www.opengis.net/spec/cql2/1.0/conf/temporal-functions

Target type

Servers that evaluate filter expressions

Parameter

Filter Language: "CQL2 Text" or "CQL2 JSON"

Requirements class

Dependency

/req/temporal-functions/temporal-predicates, /req/temporal-functions/temporal-functions

The term "temporal data type" is used for the following data types: Timestamp, Date, or Interval.

A.10.1. Conformance Test 40

Test id:

/conf/temporal-functions/temporal-functions-1

Requirements:

Test purpose:

Test the T_AFTER, T_BEFORE, T_DISJOINT, T_EQUALS, T_INTERSECTS temporal comparison functions.

Test method:

Given:

One or more data sources, each with a list of queryables with at least one queryable of type Timestamp or Date.

When:

For each queryable {queryable} of data type Timestamp, evaluate the following filter expressions

T_AFTER({queryable},TIMESTAMP('2022-04-24T07:59:57Z'))
T_AFTER({queryable},INTERVAL('2021-01-01T00:00:00Z','2021-12-31T23:59:59Z'))
T_BEFORE({queryable},TIMESTAMP('2022-04-24T07:59:57Z'))
T_BEFORE({queryable},INTERVAL('2021-01-01T00:00:00Z','2021-12-31T23:59:59Z'))
T_DISJOINT({queryable},TIMESTAMP('2022-04-24T07:59:57Z'))
T_DISJOINT({queryable},INTERVAL('2021-01-01T00:00:00Z','2021-12-31T23:59:59Z'))
T_EQUALS({queryable},TIMESTAMP('2022-04-24T07:59:57Z'))
T_EQUALS({queryable},INTERVAL('2021-01-01T00:00:00Z','2021-12-31T23:59:59Z'))
T_INTERSECTS({queryable},TIMESTAMP('2022-04-24T07:59:57Z'))
T_INTERSECTS({queryable},INTERVAL('2021-01-01T00:00:00Z','2021-12-31T23:59:59Z'))

For each queryable {queryable} of data type Date, evaluate the following filter expressions

T_AFTER({queryable},DATE('2022-04-24'))
T_AFTER({queryable},INTERVAL('2021-01-01','2021-12-31'))
T_BEFORE({queryable},DATE('2022-04-24'))
T_BEFORE({queryable},INTERVAL('2021-01-01','2021-12-31'))
T_DISJOINT({queryable},DATE('2022-04-24'))
T_DISJOINT({queryable},INTERVAL('2021-01-01','2021-12-31'))
T_EQUALS({queryable},DATE('2022-04-24'))
T_EQUALS({queryable},INTERVAL('2021-01-01','2021-12-31'))
T_INTERSECTS({queryable},DATE('2022-04-24'))
T_INTERSECTS({queryable},INTERVAL('2021-01-01','2021-12-31'))

Then:

assert successful execution of the evaluation;
store the valid predicates for each data source.

A.10.2. Conformance Test 41

Test id:

/conf/temporal-functions/temporal-functions-2

Requirements:

/req/temporal-functions/temporal-predicates, /req/temporal-functions/temporal-functions

Test purpose:

Test the temporal comparison functions with intervals

Test method:

Given:

One or more data sources, each with a list of queryables with at least two queryables of type Timestamp or Date.

When:

For each pair of queryables {queryable2} and {queryable2} of data type Timestamp, evaluate the following filter expressions

T_AFTER(INTERVAL({queryable1},{queryable2}),INTERVAL('2021-01-01T00:00:00Z','2021-12-31T23:59:59Z'))
T_BEFORE(INTERVAL({queryable1},{queryable2}),INTERVAL('2021-01-01T00:00:00Z','2021-12-31T23:59:59Z'))
T_DISJOINT(INTERVAL({queryable1},{queryable2}),INTERVAL('2021-01-01T00:00:00Z','2021-12-31T23:59:59Z'))
T_EQUALS(INTERVAL({queryable1},{queryable2}),INTERVAL('2021-01-01T00:00:00Z','2021-12-31T23:59:59Z'))
T_INTERSECTS(INTERVAL({queryable1},{queryable2}),INTERVAL('2021-01-01T00:00:00Z','2021-12-31T23:59:59Z'))
T_CONTAINS(INTERVAL({queryable1},{queryable2}),INTERVAL('2021-01-01T00:00:00Z','2021-12-31T23:59:59Z'))
T_DURING(INTERVAL({queryable1},{queryable2}),INTERVAL('2021-01-01T00:00:00Z','2021-12-31T23:59:59Z'))
T_FINISHEDBY(INTERVAL({queryable1},{queryable2}),INTERVAL('2021-01-01T00:00:00Z','2021-12-31T23:59:59Z'))
T_FINISHES(INTERVAL({queryable1},{queryable2}),INTERVAL('2021-01-01T00:00:00Z','2021-12-31T23:59:59Z'))
T_MEETS(INTERVAL({queryable1},{queryable2}),INTERVAL('2021-01-01T00:00:00Z','2021-12-31T23:59:59Z'))
T_METBY(INTERVAL({queryable1},{queryable2}),INTERVAL('2021-01-01T00:00:00Z','2021-12-31T23:59:59Z'))
T_OVERLAPPEDBY(INTERVAL({queryable1},{queryable2}),INTERVAL('2021-01-01T00:00:00Z','2021-12-31T23:59:59Z'))
T_OVERLAPS(INTERVAL({queryable1},{queryable2}),INTERVAL('2021-01-01T00:00:00Z','2021-12-31T23:59:59Z'))
T_STARTEDBY(INTERVAL({queryable1},{queryable2}),INTERVAL('2021-01-01T00:00:00Z','2021-12-31T23:59:59Z'))
T_STARTS(INTERVAL({queryable1},{queryable2}),INTERVAL('2021-01-01T00:00:00Z','2021-12-31T23:59:59Z'))

For each pair of queryables {queryable2} and {queryable2} of data type Date, evaluate the following filter expressions

T_AFTER(INTERVAL({queryable1},{queryable2}),INTERVAL('2021-01-01','2021-12-31'))
T_BEFORE(INTERVAL({queryable1},{queryable2}),INTERVAL('2021-01-01','2021-12-31'))
T_DISJOINT(INTERVAL({queryable1},{queryable2}),INTERVAL('2021-01-01','2021-12-31'))
T_EQUALS(INTERVAL({queryable1},{queryable2}),INTERVAL('2021-01-01','2021-12-31'))
T_INTERSECTS(INTERVAL({queryable1},{queryable2}),INTERVAL('2021-01-01','2021-12-31'))
T_CONTAINS(INTERVAL({queryable1},{queryable2}),INTERVAL('2021-01-01','2021-12-31'))
T_DURING(INTERVAL({queryable1},{queryable2}),INTERVAL('2021-01-01','2021-12-31'))
T_FINISHEDBY(INTERVAL({queryable1},{queryable2}),INTERVAL('2021-01-01','2021-12-31'))
T_FINISHES(INTERVAL({queryable1},{queryable2}),INTERVAL('2021-01-01','2021-12-31'))
T_MEETS(INTERVAL({queryable1},{queryable2}),INTERVAL('2021-01-01','2021-12-31'))
T_METBY(INTERVAL({queryable1},{queryable2}),INTERVAL('2021-01-01','2021-12-31'))
T_OVERLAPPEDBY(INTERVAL({queryable1},{queryable2}),INTERVAL('2021-01-01','2021-12-31'))
T_OVERLAPS(INTERVAL({queryable1},{queryable2}),INTERVAL('2021-01-01','2021-12-31'))
T_STARTEDBY(INTERVAL({queryable1},{queryable2}),INTERVAL('2021-01-01','2021-12-31'))
T_STARTS(INTERVAL({queryable1},{queryable2}),INTERVAL('2021-01-01','2021-12-31'))

Then:

assert successful execution of the evaluation;
store the valid predicates for each data source.

A.10.3. Conformance Test 42

Test id:

/conf/temporal-functions/test-data

Requirements:

all requirements

Test purpose:

Test predicates against the test dataset

Test method:

Given:

The implementation under test uses the test dataset.

When:

Evaluate each predicate in Predicates and expected results.

Then:

assert successful execution of the evaluation;
assert that the expected result is returned;
store the valid predicates for each data source.

Table 15. Predicates and expected results
Data Source	Predicate	Expected number of items
ne_110m_populated_places_simple	`t_after("date",date('2022-04-16'))`	1
ne_110m_populated_places_simple	`t_before("date",date('2022-04-16'))`	1
ne_110m_populated_places_simple	`t_disjoint("date",date('2022-04-16'))`	2
ne_110m_populated_places_simple	`t_equals("date",date('2022-04-16'))`	1
ne_110m_populated_places_simple	`t_intersects("date",date('2022-04-16'))`	1
ne_110m_populated_places_simple	`t_after("date",interval('2022-01-01','2022-12-31'))`	1
ne_110m_populated_places_simple	`t_before("date",interval('2022-01-01','2022-12-31'))`	1
ne_110m_populated_places_simple	`t_disjoint("date",interval('2022-01-01','2022-12-31'))`	2
ne_110m_populated_places_simple	`t_equals("date",interval('2022-01-01','2022-12-31'))`	0
ne_110m_populated_places_simple	`t_equals("date",interval('2022-04-16','2022-04-16'))`	1
ne_110m_populated_places_simple	`t_intersects("date",interval('2022-01-01','2022-12-31'))`	1
ne_110m_populated_places_simple	`t_after(start,timestamp('2022-04-16T10:13:19Z'))`	1
ne_110m_populated_places_simple	`t_before(start,timestamp('2022-04-16T10:13:19Z'))`	1
ne_110m_populated_places_simple	`t_disjoint(start,timestamp('2022-04-16T10:13:19Z'))`	2
ne_110m_populated_places_simple	`t_equals(start,timestamp('2022-04-16T10:13:19Z'))`	1
ne_110m_populated_places_simple	`t_intersects(start,timestamp('2022-04-16T10:13:19Z'))`	1
ne_110m_populated_places_simple	`t_after(start,interval('2022-01-01T00:00:00Z','2022-12-31T23:59:59Z'))`	0
ne_110m_populated_places_simple	`t_before(start,interval('2022-01-01T00:00:00Z','2022-12-31T23:59:59Z'))`	1
ne_110m_populated_places_simple	`t_disjoint(start,interval('2022-01-01T00:00:00Z','2022-12-31T23:59:59Z'))`	1
ne_110m_populated_places_simple	`t_equals(start,interval('2022-01-01T00:00:00Z','2022-12-31T23:59:59Z'))`	0
ne_110m_populated_places_simple	`t_intersects(start,interval('2022-01-01T00:00:00Z','2022-12-31T23:59:59Z'))`	2
ne_110m_populated_places_simple	`t_after(interval(start,end),interval('..','2022-04-16T10:13:19Z'))`	1
ne_110m_populated_places_simple	`t_before(interval(start,end),interval('2023-01-01T00:00:00Z','..'))`	2
ne_110m_populated_places_simple	`t_disjoint(interval(start,end),interval('2022-04-16T10:13:19Z','2022-04-16T10:15:09Z'))`	1
ne_110m_populated_places_simple	`t_equals(interval(start,end),interval('2021-04-16T10:15:59Z','2022-04-16T10:16:06Z'))`	1
ne_110m_populated_places_simple	`t_intersects(interval(start,end),interval('2022-04-16T10:13:19Z','2022-04-16T10:15:09Z'))`	2
ne_110m_populated_places_simple	`T_CONTAINS(interval(start,end),interval('2022-04-16T10:13:19Z','2022-04-16T10:15:10Z'))`	1
ne_110m_populated_places_simple	`T_DURING(interval(start,end),interval('2022-01-01T00:00:00Z','2022-12-31T23:59:59Z'))`	1
ne_110m_populated_places_simple	`T_FINISHES(interval(start,end),interval('2020-04-16T10:13:19Z','2022-04-16T10:16:06Z'))`	1
ne_110m_populated_places_simple	`T_FINISHEDBY(interval(start,end),interval('2022-04-16T10:13:19Z','2022-04-16T10:16:06Z'))`	1
ne_110m_populated_places_simple	`T_MEETS(interval(start,end),interval('2022-04-16T10:13:19Z','2022-04-16T10:15:10Z'))`	0
ne_110m_populated_places_simple	`T_METBY(interval(start,end),interval('2022-04-16T10:13:19Z','2022-04-16T10:15:10Z'))`	1
ne_110m_populated_places_simple	`T_OVERLAPPEDBY(interval(start,end),interval('2020-04-16T10:13:19Z','2022-04-16T10:15:10Z'))`	2
ne_110m_populated_places_simple	`T_OVERLAPS(interval(start,end),interval('2022-04-16T10:13:19Z','2023-04-16T10:15:10Z'))`	1
ne_110m_populated_places_simple	`T_STARTEDBY(interval(start,end),interval('2022-04-16T10:13:19Z','2022-04-16T10:15:10Z'))`	1
ne_110m_populated_places_simple	`T_STARTS(interval(start,end),interval('2022-04-16T10:13:19Z','2022-04-16T10:15:10Z'))`	0

A.10.4. Conformance Test 43

Test id:

/conf/temporal-functions/logical

Requirements:

n/a

Test purpose:

Test filter expressions with AND, OR and NOT including sub-expressions

Test method:

Given:

The stored predicates for each data source, including from the dependencies.

When:

Then:

assert successful execution of the evaluation.

A.11. Conformance Class "Array Functions"

Conformance Class

http://www.opengis.net/spec/cql2/1.0/conf/array-functions

Target type

Servers that evaluate filter expressions

Parameter

Filter Language: "CQL2 Text" or "CQL2 JSON"

Requirements class

Dependency

/req/array-functions/array-predicates

A.11.1. Conformance Test 44

Test id:

/conf/array-functions/array-predicates

Requirements:

Test purpose:

Test the array comparison functions

Test method:

Given:

One or more data sources, each with a list of queryables.
At least one queryable has an array data type.

When:

For each queryable {queryable} with an array data type, evaluate the following filter expressions

A_CONTAINS({queryable},("foo","bar"))
A_CONTAINEDBY({queryable},("foo","bar"))
A_EQUALS({queryable},("foo","bar"))
A_OVERLAPS({queryable},("foo","bar"))

Then:

assert successful execution of the evaluation;
store the valid predicates for each data source.

A.11.2. Conformance Test 45

Test id:

/conf/array-functions/logical

Requirements:

n/a

Test purpose:

Test filter expressions with AND, OR and NOT including sub-expressions

Test method:

Given:

The stored predicates for each data source, including from the dependencies.

When:

Then:

assert successful execution of the evaluation.

A.12. Conformance Class "Property-Property Comparisons"

Conformance Class

http://www.opengis.net/spec/cql2/1.0/conf/property-property

Target type

Servers that evaluate filter expressions

Parameter

Filter Language: "CQL2 Text" or "CQL2 JSON"

Requirements class

Requirements Class "Property-Property Comparisons"

Dependency

Conditional Dependency

Conditional Dependency

/req/property-property/withdraw-permissions

Conditional Dependency

Spatial Functions

Conditional Dependency

Temporal Functions

A.12.1. Conformance Test 46

Test id:

/conf/property-property/comparison-value-property

Requirements:

Test purpose:

Test comparison predicates with properties on the right-hand side and values on the left-hand side

Test method:

Given:

One or more data sources, each with a list of queryables.

When:

For each queryable {queryable} of one of the data types String, Boolean, Number, Integer, Timestamp or Date, evaluate the following filter expressions

{value} = {queryable}
{value} <> {queryable}
{value} > {queryable}
{value} < {queryable}
{value} >= {queryable}
{value} <= {queryable}

where {value} depends on the data type:

String: 'foo'
Boolean: true
Number: 3.14
Integer: 1
Timestamp: TIMESTAMP('2022-04-14T14:48:46Z')
Date: DATE('2022-04-14')

Then:

assert successful execution of the evaluation;
assert that the two result sets for each queryable for the operators = and <> have no item in common;
assert that the two result sets for each queryable for the operators > and <= have no item in common;
assert that the two result sets for each queryable for the operators < and >= have no item in common;
store the valid predicates for each data source.

A.12.2. Conformance Test 47

Test id:

/conf/property-property/comparison-property-property

Requirements:

/req/property-property/withdraw-permissions

Test purpose:

Test comparison predicates with properties on both sides

Test method:

Given:

One or more data sources, each with a list of queryables.

When:

For each queryable {queryable} of one of the data types String, Boolean, Number, Integer, Timestamp or Date, evaluate the following filter expressions

{queryable} = {queryable}
{queryable} <> {queryable}
{queryable} > {queryable}
{queryable} < {queryable}
{queryable} >= {queryable}
{queryable} <= {queryable}

Then:

assert successful execution of the evaluation;
assert that the result sets for each queryable for the operators <>, < and > is empty;
assert that the result sets for each queryable for the operators =, >= and <= are identical;
store the valid predicates for each data source.

A.12.3. Conformance Test 48

Test id:

/conf/property-property/comparison-value-value

Requirements:

/req/property-property/withdraw-permissions

Test purpose:

Test comparison predicates with values on both sides

Test method:

Given:

When:

Evaluate the following filter expressions

{value} = {value}
{value} <> {value}
{value} > {value}
{value} < {value}
{value} >= {value}
{value} <= {value}

for each {value} from the following list:

'foo'
true
3.14
1
TIMESTAMP('2022-04-14T14:48:46Z')
DATE('2022-04-14')

Then:

assert successful execution of the evaluation;
assert that the result sets for each queryable for the operators <>, < and > is empty;
assert that the result sets for each queryable for the operators =, >= and <= are identical;
store the valid predicates for each data source.

A.12.4. Conformance Test 49

Test id:

/conf/property-property/test-data

Requirements:

all requirements

Test purpose:

Test predicates against the test dataset

Test method:

Given:

The implementation under test uses the test dataset.

When:

Evaluate each predicate in Predicates and expected results, if the conditional dependency is met.

Then:

assert successful execution of the evaluation;
assert that the expected result is returned;
store the valid predicates for each data source.

Table 16. Predicates and expected results
Dependency	Data Source	Predicate	Expected number of items
n/a	ne_110m_populated_places_simple	`'København'=name`	1
n/a	ne_110m_populated_places_simple	`'København'<=name`	137
n/a	ne_110m_populated_places_simple	`'København'<name`	136
n/a	ne_110m_populated_places_simple	`'København'>=name`	107
n/a	ne_110m_populated_places_simple	`'København'>name`	106
n/a	ne_110m_populated_places_simple	`'København'<>name`	242
n/a	ne_110m_populated_places_simple	`name=nameascii`	230
n/a	ne_110m_populated_places_simple	`name>=nameascii`	243
n/a	ne_110m_populated_places_simple	`name>nameascii`	13
n/a	ne_110m_populated_places_simple	`name<=nameascii`	230
n/a	ne_110m_populated_places_simple	`name<nameascii`	0
n/a	ne_110m_populated_places_simple	`name<>nameascii`	13
n/a	ne_110m_populated_places_simple	`1038288=pop_other`	1
n/a	ne_110m_populated_places_simple	`1038288<=pop_other`	123
n/a	ne_110m_populated_places_simple	`1038288<pop_other`	122
n/a	ne_110m_populated_places_simple	`1038288>=pop_other`	121
n/a	ne_110m_populated_places_simple	`1038288>pop_other`	120
n/a	ne_110m_populated_places_simple	`1038288<>pop_other`	242
n/a	ne_110m_populated_places_simple	`pop_min=pop_max`	27
n/a	ne_110m_populated_places_simple	`pop_min<=pop_max`	243
n/a	ne_110m_populated_places_simple	`pop_min<pop_max`	216
n/a	ne_110m_populated_places_simple	`pop_min>=pop_max`	27
n/a	ne_110m_populated_places_simple	`pop_min>pop_max`	0
n/a	ne_110m_populated_places_simple	`pop_min<>pop_max`	216
n/a	ne_110m_populated_places_simple	`start=end`	0
n/a	ne_110m_populated_places_simple	`start<=end`	3
n/a	ne_110m_populated_places_simple	`start<end`	3
n/a	ne_110m_populated_places_simple	`start>=end`	0
n/a	ne_110m_populated_places_simple	`start>end`	0
n/a	ne_110m_populated_places_simple	`start<>end`	3
Advanced Comparison Operators	ne_110m_populated_places_simple	`'København' LIKE 'K_benhavn'`	243
Advanced Comparison Operators	ne_110m_populated_places_simple	`'København' NOT LIKE 'K_benhavn'`	0
Advanced Comparison Operators	ne_110m_populated_places_simple	`pop_other between pop_min and pop_max`	94
Advanced Comparison Operators	ne_110m_populated_places_simple	`pop_other not between pop_min and pop_max`	149
Basic Spatial Functions	ne_110m_admin_0_countries	`S_INTERSECTS(BBOX(0,40,10,50),geom)`	8
Basic Spatial Functions	ne_110m_admin_0_countries	`S_INTERSECTS(BBOX(150,-90,-150,90),geom)`	10
Basic Spatial Functions	ne_110m_admin_0_countries	`S_INTERSECTS(POINT(7.02 49.92),geom)`	1
Basic Spatial Functions	ne_110m_populated_places_simple	`S_INTERSECTS(BBOX(0,40,10,50),geom)`	7
Basic Spatial Functions	ne_110m_rivers_lake_centerlines	`S_INTERSECTS(BBOX(-180,-90,0,90),geom)`	4
Spatial Functions	ne_110m_admin_0_countries	`S_INTERSECTS(POLYGON((0 40,10 40,10 50,0 50,0 40)),geom)`	8
Spatial Functions	ne_110m_admin_0_countries	`S_INTERSECTS(LINESTRING(0 40,10 50),geom)`	4
Spatial Functions	ne_110m_populated_places_simple	`S_INTERSECTS(POLYGON((0 40,10 40,10 50,0 50,0 40)),geom)`	7
Spatial Functions	ne_110m_rivers_lake_centerlines	`S_INTERSECTS(LINESTRING(-60 -90,-60 90),geom)`	2
Spatial Functions	ne_110m_admin_0_countries	`S_DISJOINT(BBOX(0,40,10,50),geom)`	169
Spatial Functions	ne_110m_admin_0_countries	`S_DISJOINT(POLYGON((0 40,10 40,10 50,0 50,0 40)),geom)`	169
Spatial Functions	ne_110m_admin_0_countries	`S_DISJOINT(LINESTRING(0 40,10 50),geom)`	173
Spatial Functions	ne_110m_admin_0_countries	`S_DISJOINT(POINT(7.02 49.92),geom)`	176
Spatial Functions	ne_110m_populated_places_simple	`S_DISJOINT(BBOX(0,40,10,50),geom)`	236
Spatial Functions	ne_110m_populated_places_simple	`S_DISJOINT(POLYGON((0 40,10 40,10 50,0 50,0 40)),geom)`	236
Spatial Functions	ne_110m_rivers_lake_centerlines	`S_DISJOINT(BBOX(-180,-90,0,90),geom)`	9
Spatial Functions	ne_110m_rivers_lake_centerlines	`S_DISJOINT(LINESTRING(-60 -90,-60 90),geom)`	11
Spatial Functions	ne_110m_populated_places_simple	`S_EQUALS(POINT(6.1300028 49.6116604),geom)`	1
Spatial Functions	ne_110m_admin_0_countries	`S_TOUCHES(POLYGON((6.043073357781111 50.128051662794235,6.242751092156993 49.90222565367873,6.186320428094177 49.463802802114515,5.897759230176348 49.44266714130711,5.674051954784829 49.529483547557504,5.782417433300907 50.09032786722122,6.043073357781111 50.128051662794235)),geom)`	3
Spatial Functions	ne_110m_admin_0_countries	`S_TOUCHES(POINT(6.043073357781111 50.128051662794235),geom)`	3
Spatial Functions	ne_110m_admin_0_countries	`S_TOUCHES(POINT(6.242751092156993 49.90222565367873),geom)`	2
Spatial Functions	ne_110m_admin_0_countries	`S_TOUCHES(LINESTRING(6.043073357781111 50.128051662794235,6.242751092156993 49.90222565367873),geom)`	3
Spatial Functions	ne_110m_rivers_lake_centerlines	`S_CROSSES(BBOX(0,40,10,50),geom)`	1
Spatial Functions	ne_110m_rivers_lake_centerlines	`S_CROSSES(LINESTRING(-60 -90,-60 90),geom)`	2
Spatial Functions	ne_110m_admin_0_countries	`S_CONTAINS(BBOX(-180,-90,0,90),geom)`	44
Spatial Functions	ne_110m_populated_places_simple	`S_CONTAINS(BBOX(-180,-90,0,90),geom)`	74
Spatial Functions	ne_110m_rivers_lake_centerlines	`S_CONTAINS(BBOX(-180,-90,0,90),geom)`	4
Spatial Functions	ne_110m_admin_0_countries	`S_WITHIN(BBOX(7,50,8,51),geom)`	1
Spatial Functions	ne_110m_admin_0_countries	`S_WITHIN(LINESTRING(7 50,8 51),geom)`	1
Spatial Functions	ne_110m_admin_0_countries	`S_WITHIN(POINT(7.02 49.92),geom)`	1
Spatial Functions	ne_110m_admin_0_countries	`S_OVERLAPS(BBOX(-180,-90,0,90),geom)`	11
Temporal Functions	ne_110m_populated_places_simple	`t_after(date('2022-04-16'),"date")`	1
Temporal Functions	ne_110m_populated_places_simple	`t_before(date('2022-04-16'),"date")`	1
Temporal Functions	ne_110m_populated_places_simple	`t_disjoint(date('2022-04-16'),"date")`	2
Temporal Functions	ne_110m_populated_places_simple	`t_equals(date('2022-04-16'),"date")`	1
Temporal Functions	ne_110m_populated_places_simple	`t_intersects(date('2022-04-16'),"date")`	1
Temporal Functions	ne_110m_populated_places_simple	`t_after(interval('2022-01-01','2022-12-31'),"date")`	1
Temporal Functions	ne_110m_populated_places_simple	`t_before(interval('2022-01-01','2022-12-31'),"date")`	1
Temporal Functions	ne_110m_populated_places_simple	`t_disjoint(interval('2022-01-01','2022-12-31'),"date")`	2
Temporal Functions	ne_110m_populated_places_simple	`t_equals(interval('2022-01-01','2022-12-31'),"date")`	0
Temporal Functions	ne_110m_populated_places_simple	`t_equals(interval('2022-04-16','2022-04-16'),"date")`	1
Temporal Functions	ne_110m_populated_places_simple	`t_intersects(interval('2022-01-01','2022-12-31'),"date")`	1
Temporal Functions	ne_110m_populated_places_simple	`t_after(timestamp('2022-04-16T10:13:19Z'),start)`	1
Temporal Functions	ne_110m_populated_places_simple	`t_before(timestamp('2022-04-16T10:13:19Z'),start)`	1
Temporal Functions	ne_110m_populated_places_simple	`t_disjoint(timestamp('2022-04-16T10:13:19Z'),start)`	2
Temporal Functions	ne_110m_populated_places_simple	`t_equals(timestamp('2022-04-16T10:13:19Z'),start)`	1
Temporal Functions	ne_110m_populated_places_simple	`t_intersects(timestamp('2022-04-16T10:13:19Z'),start)`	1
Temporal Functions	ne_110m_populated_places_simple	`t_after(interval('2022-01-01T00:00:00Z','2022-12-31T23:59:59Z'),start)`	1
Temporal Functions	ne_110m_populated_places_simple	`t_before(interval('2022-01-01T00:00:00Z','2022-12-31T23:59:59Z'),start)`	0
Temporal Functions	ne_110m_populated_places_simple	`t_disjoint(interval('2022-01-01T00:00:00Z','2022-12-31T23:59:59Z'),start)`	1
Temporal Functions	ne_110m_populated_places_simple	`t_equals(interval('2022-01-01T00:00:00Z','2022-12-31T23:59:59Z'),start)`	0
Temporal Functions	ne_110m_populated_places_simple	`t_intersects(interval('2022-01-01T00:00:00Z','2022-12-31T23:59:59Z'),start)`	2
Temporal Functions	ne_110m_populated_places_simple	`t_after(interval('2023-01-01T00:00:00Z','..'),interval(start,end))`	2
Temporal Functions	ne_110m_populated_places_simple	`t_before(interval('..','2022-04-16T10:13:19Z'),interval(start,end))`	1
Temporal Functions	ne_110m_populated_places_simple	`t_disjoint(interval('2022-04-16T10:13:19Z','2022-04-16T10:15:09Z'),interval(start,end))`	1
Temporal Functions	ne_110m_populated_places_simple	`t_equals(interval('2021-04-16T10:15:59Z','2022-04-16T10:16:06Z'),interval(start,end))`	1
Temporal Functions	ne_110m_populated_places_simple	`t_intersects(interval('2022-04-16T10:13:19Z','2022-04-16T10:15:09Z'),interval(start,end))`	2
Temporal Functions	ne_110m_populated_places_simple	`T_CONTAINS(interval('2021-04-16T10:13:19Z','2023-04-16T10:15:10Z'),interval(start,end))`	2
Temporal Functions	ne_110m_populated_places_simple	`T_DURING(interval('2022-07-01T00:00:00Z','2022-12-31T23:59:59Z'),interval(start,end))`	1
Temporal Functions	ne_110m_populated_places_simple	`T_FINISHES(interval('2022-04-16T10:13:19Z','2022-04-16T10:16:06Z'),interval(start,end))`	1
Temporal Functions	ne_110m_populated_places_simple	`T_FINISHEDBY(interval('2022-04-16T10:13:19Z','2022-04-16T10:16:06Z'),interval(start,end))`	0
Temporal Functions	ne_110m_populated_places_simple	`T_MEETS(interval('2022-04-16T10:13:19Z','2022-04-16T10:15:10Z'),interval(start,end))`	1
Temporal Functions	ne_110m_populated_places_simple	`T_METBY(interval('2022-04-16T10:13:19Z','2022-04-16T10:15:10Z'),interval(start,end))`	0
Temporal Functions	ne_110m_populated_places_simple	`T_OVERLAPPEDBY(interval('2020-04-16T10:13:19Z','2022-04-16T10:15:10Z'),interval(start,end))`	0
Temporal Functions	ne_110m_populated_places_simple	`T_OVERLAPS(interval('2022-04-16T10:13:19Z','2023-04-16T10:15:10Z'),interval(start,end))`	0
Temporal Functions	ne_110m_populated_places_simple	`T_STARTEDBY(interval('2022-04-16T10:13:19Z','2022-04-16T10:15:10Z'),interval(start,end))`	0
Temporal Functions	ne_110m_populated_places_simple	`T_STARTS(interval('2022-04-16T10:13:19Z','2022-04-16T10:15:10Z'),interval(start,end))`	1

A.12.5. Conformance Test 50

Test id:

/conf/property-property/logical

Requirements:

n/a

Test purpose:

Test filter expressions with AND, OR and NOT including sub-expressions

Test method:

Given:

The stored predicates for each data source, including from the dependencies.

When:

Then:

assert successful execution of the evaluation.

A.13. Conformance Class "Functions"

Conformance Class

http://www.opengis.net/spec/cql2/1.0/conf/functions

Target type

Servers that evaluate filter expressions

Parameter

Filter Language: "CQL2 Text" or "CQL2 JSON"

Requirements class

Requirements Class "Functions"

Dependency

http://www.opengis.net/spec/cql2/1.0/conf/arithmetic

A.13.1. Conformance Test 51

Test id:

/conf/functions/functions

Requirements:

/req/functions/functions

Test purpose:

Test predicates with functions

Test method:

Given:

The list of functions with arguments and return type supported by the implementation under test.

When:

For each function construct multiple valid filter expressions involving different operators.

Then:

assert successful execution of the evaluation.

A.14. Conformance Class "Arithmetic Expressions"

Conformance Class

Target type

Servers that evaluate filter expressions

Parameter

Filter Language: "CQL2 Text" or "CQL2 JSON"

Requirements class

Requirements Class "Arithmetic Expressions"

Dependency

Conditional Dependency