Open Geospatial Consortium

Submission Date: <yyyy-mm-dd>

Approval Date:  <yyyy-mm-dd>

Publication Date:  <yyyy-mm-dd>

External identifier of this OGC® document: http://www.opengis.net/doc/IS/ogcapi-features-n/1.0

Internal reference number of this OGC® document:    19-079

Version: 1.0.0-SNAPSHOT (Editor’s draft)

Latest Published Draft: n/a

Category: OGC® Implementation Specification

Editors: TBD

OGC API - Features - Part 3: Common Query Language

Copyright notice

Copyright © 2019 Open Geospatial Consortium

To obtain additional rights of use, visit http://www.opengeospatial.org/legal/

Warning

This document is not an OGC Standard. This document is distributed for review and comment. This document is subject to change without notice and may not be referred to as an OGC Standard.

Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

Document type:    OGC® Standard

Document subtype:    Interface

Document stage:    Draft

Document language:  English

 
License Agreement

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD.

THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

Table of Contents

i. Abstract

OGC API standards define modular API building blocks to spatially enable Web API in a consistent way. The OpenAPI specification is used to define the API building blocks.

OGC API Features provides API building blocks to create, modify and query features on the Web. OGC API Features is comprised of multiple parts, each of them is a separate standard.

A fundamental operation performed on a collection of resources is that of querying in order to obtain a subset of the data which contains resource instances that satisfy some filtering criteria. This part, part 4, defines an encoding for specifying enhanced filtering criteria in a request to a server, beyond what is supported in the core called the Common Query Language.

The common query language defined in this document is used to specify how resource instances in a source collection should be filter to identify a result set. Typically, CQL is used in query operations to identify the subset of resources that should be included in a response document. However, CQL may also be used in other operations (e.g. updates) to identify the subset of resources that should be affected by an operation.

Each resource instance in the source collection is evaluated using a filtering expression encoded using the common query language. The overall filter expression always evaluates to true or false. If the expression evaluates to true, the resource instance satisfies the expression and is marked as being in the result set. If the overall filter expression evaluates to false, the data instance is not in the result set. Thus, the net effect of evaluating a filter expression is a set of resources that satisfy the predicates in the expression.

Caution
 This is a DRAFT version of the nth part of the OGC API - Features standards. This draft is not complete and there are open issues that are still under discussion.

ii. Keywords

The following are keywords to be used by search engines and document catalogues.

common query language, filter, expression, query, SQL, CQL, where clause, selection clause,

iii. Preface

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium Inc. shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

iv. Submitting organizations

The following organizations submitted this document to the Open Geospatial Consortium (OGC):

  • …

v. Submitters

All questions regarding this submission should be directed to the editors or the submitters:

Name

Affiliation

NN (editor)

NN

Scope

This document specifies an extension to the OGC API - Features - Part 1: Core standard that defines the behaviour of a server that supports enhanced filtering capabilities expressed using a common query language (CQL).

Enhanced filtering capabilities in this case means that the server supports the ability to define selection clauses using predicates beyond those supported by the OGC API Common specification (i.e. bbox and datetime).

This document defines a text encoding for a CQL filter suitable for use as a query parameter in a URL.

This document defines a JSON encoding for a CQL filter suitable for use in a HTTP POST body.

This document defines the schema for a JSON document that exposes the set of properties or keys that may be used to construct CQL expressions.

Conformance

This standard defines the following conformance classes:

The main conformance class is:

The Simple Cql conformance class specifies requirements that all implemenations of this extension shall support. This conformance class defines the following URL query parameters:

  • filter

  • filter-lang

This conformance class also defines the JSON schema for a document that contains the list of resources properties or keys that may be used to construct a CQL expression.

The Simple CQL conformance class allows query predicates to be constructed using the following operators:

  • Logical operators:

    • and

    • or

    • not

  • Comparison operators:

    • equal to

    • less than

    • less than or equal to

    • greater than

    • greater than or equal to

    • like

    • is null

    • between

    • in

  • Spatial operators:

    • intersects.

  • Temporal operators:

    • anyinteracts

  • Schema interogation operators:

    • exists

The Simple CQL conformance class is intended to be a minimal useful set of predicates that support enhanced fine-grained read-access to collections of resources. In this case enhanced means filtering capabilities beyond those supported by the core OGC API Common specification (i.e. bbox and datetime).

The Enhanced Spatial conformance class specifies requirements for servers that support spatial operators in addition to the intersects operator. The list of additional spatial operators that must be supported is:

  • equals

  • disjoint

  • touches

  • within

  • overlaps

  • crosses

  • contains

Note
 Do we need to add DWITHIN and BEYOND?

The Enhanced Temporal conformance class specifies requirements for servers that support temporal operators in addition to the anyinteracts operator. The list of additional spatial operators that must be supported is:

  • after

  • before

  • begins

  • begunby

  • tcontains

  • during

  • endedby

  • ends

  • tequals

  • meets

  • metby

  • toverlaps

  • overlappedby

  • intersects

Conformance with this standard shall be checked using all the relevant tests specified in Annex A of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site.

References

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

Terms and Definitions

This document uses the terms defined in Sub-clause 5.3 of [OGC 06-121r9], which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this standard.

For the purposes of this document, the following additional terms and definitions apply in addition to the terms defined in OGC API - Features - Part 1: Core.

term 1

definition [source]

term 2

definition [source]

Conventions and background

See OGC API - Features - Part 1: Core, Clauses 5 and 6.

Requirements Class "Simple CQL"

Overview

The OGC API - Common standard defines support for two filtering operators: bbox and datetime.

The OGC API - Features - Part 1: Core standard adds support, beyond OGC API - Common for simple equality predicates logically joined using the AND operator.

This extension defines the behaviour of a server that supports additional parameters for filter and that supports additional operators that may be used to construct filtering expressions.

Queryables

This extension does not assume that the schema (internal or external) of a resource is available for inspection and thus a means needs to exist to interrogate an endpoint to determine the names and types of the the properties or keys that may be used to construct a filter expression.

Requirement 1

/req/simple-cql/get-queryables-op-global

A

A server that implements this conformance class shall support the HTTP GET operation at the /queryables path.

B

The queryables accessed at this path shall be valid for all collections identified in the collections response (path /collections).

Requirement 2

/req/simple-cql/get-queryables-op-local

A

For every collection identified in the collections response (path /collections), the server SHALL support the HTTP GET operation at the path /collections/{collectionId}/queryables.

B

The parameter collectionId is each id property in the collections response (JSONPath: $.collections[*].id).

Requirement 3

/req/simple-cql/get-queryables-response

A

A successful execution of the operation SHALL be reported as a response wit h a HTTP status code 200.

B

The content of the response shall have the following characteristics (using an OpenAPI Specification 3.0 fragment):

type: object
required:
  - queryables
properties:
  queryables:
    type: array
    items:
      type: object
      required:
      - queryable
      - type
      properties:
         queryable:
            description: the token that may be used in a CQL predicate
            type: string
         title:
            description: a human readble title for the queryable
            type: string
         description:
         description: a human-readable narrative describing the queryable
            type: string
         language:
            description: the language used for the title and description
            type: string
            default:
               - en
         type:
            description: the data type of the queryable
            type: string
         type-ref:
            description: a reference to the formal definition of the type
            type: string
            format: url
Example 1. Queryables example
{
   "queryables": [
      {
         "queryable": "elevation",
         "title": "Elevation",
         "description": "The average distance of the road segment above sea level.",
         "type": "double"
      },
      {
         "queryable": "nlanes",
         "title": "Temperature",
         "description": "The total number of lanes in all directions.",
         "type": "integer"
      },
      {
         "queryable": "geom",
         "title": "Segment Geometry",
         "description": "The geometry of the road segment",
         "type": "linestring"
      },
      {
         "queryable": "name",
         "title": "Segment Name",
         "description": "The common name of the road segment.",
         "type": "string"
      }
   ]
}

Parameter filter

Requirement 4

/req/simple-cql/filter-definition

A

The HTTP GET operation on the path that fetches resource instances (e.g. /collections/{collectionId}/items) shall support a parameter filter with the following characteristics (using an OpenAPI Specification 3.0 fragment):

name: filter
in: query
required: false
schema:
  type: string
style: form
explode: false

Requirement 5

/req/simple-cql/filter-lang-definition

A

The HTTP GET operation on the path that fetches resource instances (e.g. /collections/{collectionId}/items) shall support a parameter filter-lang with the following characteristics (using an OpenAPI Specification 3.0 fragment):

name: filter-lang
in: query
required: false
schema:
  type: string
  enum:
     - 'cql'
     - 'cql-json'
  default: "cql"
style: form

Other query languages may be used but are not discussed in this extension.

Requirement 6

/req/simple-cql/filter-crs-definition

A

If the server implementing this extension also support the Coords Reference Systems by Reference extension, then the HTTP GET operation on the path that fetches resource instances (e.g. /collections/{collectionId}/items') shall support a parameter `filter-crs that asserts the crs being used to encode geomerty coordinates in a CQL filter expression

B

The following YAML fragment defines the filter-crs parameter:

[source,YAML[

name: filter-lang
in: query
required: false
schema:
  type: string
  enum:
     - 'cql'
     - 'cql-json'
  default: "cql"
style: form

Requirement 7

/req/simple-cql/filter-response

A

A CQL filter expression shall be evaluated for each item of a collection.

B

If the CQL filter experssion evalutes to TRUE then the item shall be included in the result set.

C

If the CQL filter expression evaluates to FALSE then the item shall be excluded from the result set.

Text encoding of CQL

CQL filter expression

A CQL filter expression is a character string that defines a logically connected set of predicates that are evaluated for each item of a collection. A CQL filter expression produces a Boolean value of ‘TRUE` is the collection item satisfies all the requirements of the expression; otherwise the CQL filter expression evaluates to `FALSE’.

A CQL filter expression can be constructed by logically connecting zero or more of the following classes of predicates:

  • comparison predicates

  • spatial predicates

  • temporal predicates

  • existence predicates

  • list predicates

Requirement 8

/req/simple-cql/filter-expression

A

A server that implements this conformance class shall be able to parse a CQL filter expression defined by the following BNF fragment:

cqlFilter = booleanValueExpression;

booleanValueExpression = booleanTerm | booleanValueExpression "OR" booleanTerm;

booleanTerm = booleanFactor | booleanTerm "AND" booleanFactor;

booleanFactor = ["NOT"] booleanPrimary;

booleanPrimary = predicate
               | leftParen cqlFilter rightParen;

predicate = comparisonPredicate
         | spatialPredicate
         | temporalPredicate
         | existencePredicate
         | inPredicate;

Scalar expressions

A scalar expression is one of a property name, a character literal or a numeric literal.

Requirement 9

/req/simple-cql/scalar-expressions

A

A server that implements this conformance class shall be able to parse a scalar expressions defined by the following BNF fragment:

scalarExpression = propertyName
                 | characterLiteral
                 | numericLiteral;

propertyName = identifier;
identifier = identifierStart [ {identifierPart} ];

identifierStart = alpha [{octothorp|dollar|underscore|alpha|digit}];

identifierPart = alpha | digit;

characterLiteral = characterStringLiteral
                 | bitStringLiteral
                 | hexStringLiteral;

characterStringLiteral = quote [ {character} ] quote;

character = alpha | digit | specialCharacter | quoteQuote;

quoteQuote = quote quote;

bitStringLiteral = "B" quote [ {bit} ] quote;

hexStringLiteral = "X" quote [ {hexit} ] quote;

numericLiteral = unsignedNumericLiteral | signedNumericLiteral;

unsignedNumericLiteral = exactNumericLiteral | approximateNumericLiteral;

signedNumericLiteral = [sign] exactNumericLiteral | approximateNumericLiteral;

exactNumericLiteral = unsignedInteger [ period [ unsignedInteger ] ]
                      | period unsignedInteger;

approximateNumericLiteral = mantissa "E" exponent;

mantissa = exactNumericLiteral;

exponent = signedInteger;

signedInteger = [ sign ] unsignedInteger;

unsignedInteger = {digit};

sign = plusSign | minusSign;

alpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" |
        "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" |
        "W" | "X" | "Y" | "Z" |
        "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" |
        "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" |
        "w" | "x" | "y" | "z";

digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9";

hexit = digit | "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f";

specialCharacter = percent | ampersand | leftParen | rightParen | asterisk
                 | plusSign | comma | minusSign | period | solidus | colon
                 | semicolon | lt | gt | eq | questionMark | underscore
                 | verticalBar | doubleQuote ;

octothorp = "#";

dollar = "$";

underscore = "_";

quote = "'";

plusSign = "+";

minusSign = "-";

period = ".";

doubleQuote = "\"";

percent = "%";

ampersand = "&";

leftParen = "(";

rightParen = ")";

asterisk = "*";

comma = ",";

solidus = "/";

colon = ":";

semicolon = ";";

lt = "<";

eq = "=";

gt = ">";

questionMark = "?";

verticalBar = "|

bit = "0" | "1";
Note
 The alpha production is just an examples that allows the BNF validators that I used to work. In reality thi should really be the list of valid UTF-8 characters.

Comparison predicates

A comparison predicate is created with an comparison operator, a left expression and a right expression and evaluates to the Boolean value TRUE if the requirements of the comparison operator are satisfied; otherwise the comparison predicate evaluates to the Boolean value FALSE.

Requirement 10

/req/simple-cql/comparison-predicates

A

A server that implements this conformance class shall be able to parse comparison predicates defined by the following BNF fragment:

comparisonPredicate = binaryComparisonPredicate
                    | propertyIsLikePredicate
                    | propertyIsBetweenPredicate
                    | propertyIsNullPredicate;

binaryComparisonPredicate = scalarExpression comparisonOperator scalarExpression;

propertyIsLikePredicate =  scalarExpression "LIKE" regularExpression;

propertyIsBetweenPredicate = scalarExpression "BETWEEN"
                             scalarExpression "AND" scalarExpression;

propertyIsNullPredicate = scalarExpression "IS" ["NOT"] "NULL";

regularExpression = characterLiteral;

comparisonOperator = eq | neq | lt | gt | lteq | gteq;

neq = lt gt;

gteq = gt eq;

lteq = lt eq;

Spatial predicates

A spatial predicate is created with an spatial operator, a left expression and a right expression and evaluates to the Boolean value TRUE if the requirements of the spatial operator are satisfied; otherwise the spatial predicate evaluates to the Boolean value FALSE.

Requirement 11

/req/simple-cql/spatial-predicates

A

A server that implements this conformance class shall be able to parse spatial predicates defined by the following BNF fragment:

spatialPredicate = spatialOperator leftParen geomExpression comma geomExpression rightParen;

spatialOperator = "INTERSECTS";

# A geometric expression is a property name of a geometry-valued property,
# a geometric literal (expressed as WKT) or a function that returns a
# geometric value.
#
geomExpression = propertyName
               | geomLiteral;

geomLiteral = pointTaggedText
            | linestringTaggedText
            | polygonTaggedText
            | multipointTaggedText
            | multilinestringTaggedText
            | multipolygonTaggedText
            | geometryCollectionTaggedText
            | envelopeTaggedText;

pointTaggedText = "POINT" pointText;

linestringTaggedText = "LINESTRING" lineStringText;

polygonTaggedText = "POLYGON" polygonText;

multipointTaggedText = "MULTIPOINT" multiPointText;

multilinestringTaggedText = "MULTILINESTRING" multiLineStringText;

multipolygonTaggedText = "MULTIPOLYGON" multiPolygonText;

geometryCollectionTaggedText = "GEOMETRYCOLLECTION" geometryCollectionText;

pointText = leftParen point rightParen;

point = xCoord yCoord [zCoord];

xCoord = signedNumericLiteral;

yCoord = signedNumericLiteral;

zCoord = signedNumericLiteral;

lineStringText = leftParen point {comma point} rightParen;

polygonText =  leftParen lineStringText {comma lineStringText} rightParen;

multiPointText = leftParen pointText {comma pointText} rightParen;

multiLineStringText = leftParen lineStringText {comma lineStringText} rightParen;

multiPolygonText = leftParen polygonText {comma polygonText} rightParen;

geometryCollectionText = leftParen geomLiteral {comma geomLiteral} rightParen;

envelopeTaggedText = "ENVELOPE" envelopeText;

envelopeText = leftParen westBoundLon comma eastBoundLon comma northBoundLat comma southBoundLat [comma minElev comma maxElev] rightParen;

westBoundLon = signedNumericLiteral;

eastBoundLon = signedNumericLiteral;

northBoundLat = signedNumericLiteral;

southBoundLat = signedNumericLiteral;

minElev = signedNumericLiteral;

maxElev = signedNumericLiteral;

Requirement 12

/req/simple-cql/crs/crs84

A

If a server implementing this extension does not support the Coordinate Reference Systems by Reference extension, then all geometry coordinate values shall be expressed using CRS84 as per OGC API - Features - Part 1: Core.

Requirement 13

/req/simple-cql/crs/storage-other

A

If a server implementing this standard also supports the Coor dinate Reference Systems by Reference extension, then all geometry coordinate values encoded in a CQL expression shall be expressed using the crs specified by the filter-crs parameter.

Temporal predicates

A temporal predicate is created with a temporal operator, a left expression and a right expression and evaluates to the Boolean value TRUE if the requirements of the temporal operator are satisfied; otherwise the temporal predicate evaluates to the Boolean value FALSE.

Requirement 14

/req/simple-cql/temporal-predicates

A

A server that implements this conformance class shall be able to parse temporal predicates defined by the following BNF fragment:

temporalPredicate = temporalExpression temporalOperator temporalExpression;

temporalExpression = propertyName
                   | temporalLiteral;

temporalOperator =  "ANYINTERACTS";

temporalLiteral = instant | interval;

instant = fullDate | fullDate "T" utcTime;

interval = instantInInterval solidus instantInInterval;

instantInInterval = period period | "" | instant;

fullDate   = dateYear minusSign dateMonth minusSign dateDay;

dateYear   = digit digit digit digit;

dateMonth  = digit digit;

dateDay    = digit digit;

utcTime  = timeHour colon timeMinute colon timeSecond [timeZoneOffset];

timeZoneOffset = "Z" | sign timeHour;

timeHour   = digit digit;

timeMinute = digit digit;

timeSecond = digit digit [period digit {digit}];

Existence predicate

An existence predicate interrogates the server to determine if the named property is (i.e. EXISTS) or is not (i.e. DOES NOT EXIST) a property of the resource being evaluated by the CQL filter expression. If the named property satsifies the requirements of the operator (i.e. EXISTS or DOES NOT EXIST) then the existence predicate evaluates to the Boolean value TRUE; otherwise the existence predicate evaluates to the Boolean value FALSE;

Requirement 15

/req/simple-cql/existence-predicate

A

A server that implements this conformance class shall be able to parse existence predicates defined by the following BNF fragment:

existencePredicate = propertyName "EXISTS"
                   | propertyName "DOES" "NOT" "EXIST";

List predicate

A list predicate tests for equality the value of a named property against a list of literal values. If the value of the named property is equal to one or more of the values in the list of literals the list predicate evaluates to TRUE; otherwise the list predicate evaluates to FALSE.

Requirement 16

/req/simple-cql/in-predicate

A

A server that implements this conformance class shall be able to parse an list predicate defined by the following BNF fragment:

inPredicate = propertyName "IN" leftParen { characterLiteral |
                                            numericLiteral |
                                            geomLiteral |
                                            temporalLiteral } rightParen;

Interaction with existing predicates

Requirement 17

/req/simple-cql/in-predicate

A

Existing predicates not defined in this standard shall be logically connected with the AND operator when mixed with CQL expressions.

Media Types

See OGC API - Features - Part 1: Core, Clause 10.

(( add additional text as needed ))

Security Considerations

See OGC API - Features - Part 1: Core, Clause 11.

(( add additional text as needed ))

Annex A: Abstract Test Suite (Normative)

(( add test cases ))

(( include::abstract_tests/cc/TEST001.adoc[] ))

Annex B: Revision History

Date Release Editor Primary clauses modified Description

2019-xx-xx

1.0.0-SNAPSHOT

J. Doe

all

initial version

Annex C: Bibliography