GeoWave User Guide

Introduction

Purpose of this Guide

This user guide focuses on the various ways a user can interact with GeoWave without writing code. It covers the Command-Line Interface (CLI), the ingest process, the vector query language, analytics, visibility management, as well as the GeoServer plugin.

Assumptions

This guide assumes that the reader is familiar with the basics of GeoWave discussed in the Overview. It also assumes that GeoWave has already been installed and is available on the command-line. See the Installation Guide for help with the installation process.

External Components

Some commands in this guide are intended to be used alongside external third party components. The following are not required, but the versions supported by GeoWave are listed below. The installation and configuration of these external components is outside the scope of this document.

Component	Supported Version(s)
GeoServer	2.14.x
Apache Accumulo	[ 1.7.x, 1.9.x ]
Apache HBase	[ 1.1.x, 1.4.x ]
Apache Hadoop	2.x
GDAL	1.9.2
Cloudera CDH5	5.9

Component

Supported Version(s)

2.14.x

[ 1.7.x, 1.9.x ]

[ 1.1.x, 1.4.x ]

2.x

1.9.2

5.9

Command-Line Interface (CLI)

Overview

The Command-Line Interface provides a way to execute a multitude of common operations on GeoWave data stores without having to use the Programmatic API. It allows users to manage data stores, indices, statistics, and more. While this guide covers the basics of the CLI, the GeoWave CLI Documentation contains an exhaustive overview of each command and their options.

Configuration

The CLI uses a local configuration file to store sets of data store connection parameters aliased by a store name. Most GeoWave commands ask for a store name and use the configuration file to determine which connection parameters should be used. It also stores connection information for GeoServer, AWS, and HDFS for commands that use those services. This configuration file is generally stored in the user’s home directory, although an alternate configuration file can be specified when running commands.

General Usage

The root of all GeoWave CLI commands is the base geowave command.

$ geowave

This will display a list of all available top-level commands along with a brief description of each.

Version

$ geowave --version

The --version flag will display various information about the installed version of GeoWave, including the version, build arguments, and revision information.

General Flags

These flags can be optionally supplied to any GeoWave command, and should be supplied before the command itself.

Config File

The --config-file flag causes GeoWave to use an alternate configuration file. The supplied file path should include the file name (e.g. --config-file /mnt/config.properties). This can be useful if you have multiple projects that use GeoWave and want to keep the configuration for those data stores separate from each other.

$ geowave --config-file <path_to_file> <command>

Debug

The --debug flag causes all DEBUG, INFO, WARN, and ERROR log events to be output to the console. By default, only WARN and ERROR log events are displayed.

$ geowave --debug <command>

Help Command

Adding help before any CLI command will show that command’s options and their defaults.

$ geowave help <command>

For example, using the help command on index add would result in the following output:

$ geowave help index add
Usage: geowave index add [options] <store name> <index name>
  Options:
    -np, --numPartitions
       The number of partitions.  Default partitions will be 1.
       Default: 1
    -ps, --partitionStrategy
       The partition strategy to use.  Default will be none.
       Default: NONE
       Possible Values: [NONE, HASH, ROUND_ROBIN]
  * -t, --type
       The type of index, such as spatial, or spatial_temporal

Explain Command

The explain command is similar to the help command in it’s usage, but shows all options, including hidden ones. It can be a great way to make sure your parameters are correct before issuing a command.

$ geowave explain <command>

For example, if you wanted to add a spatial index to a store named test-store but weren’t sure what all of the options available to you were, you could do the following:

$ geowave explain index add -t spatial test-store spatial-idx
Command: geowave [options] <subcommand> ...

                VALUE  NEEDED  PARAMETER NAMES
----------------------------------------------
{                    }         -cf, --config-file,
{                    }         --debug,
{                    }         --version,

Command: add [options]

                VALUE  NEEDED  PARAMETER NAMES
----------------------------------------------
{           EPSG:4326}         -c, --crs,
{               false}         -fp, --fullGeometryPrecision,
{                   7}         -gp, --geometryPrecision,
{                   1}         -np, --numPartitions,
{                NONE}         -ps, --partitionStrategy,
{               false}         --storeTime,
{             spatial}         -t, --type,

Expects: <store name> <index name>
Specified:
test-store spatial-idx

The output is broken down into two sections. The first section shows all of the options available on the geowave command. If you wanted to use any of these options, they would need to be specified before index add. The second section shows all of the options available on the index add command. Some commands contain options that, when specified, may reveal more options. In this case, the -t spatial option has revealed some additional configuration options that we could apply to the spatial index. Another command where this is useful is the store add command, where each data store type specified by the -t <store_type> option has a different set of configuration options.

Top-Level Commands

The GeoWave CLI is broken up into several top-level commands that each focus on a different aspect of GeoWave.

Store Commands

The store command contains commands for managing the GeoWave data stores. This includes commands to add, remove, and copy data stores.

Index Commands

The index command contains commands for listing, adding, and removing GeoWave indices from a data store.

Type Commands

The type command contains commands for listing, describing, and removing types at a data store level.

Ingest Commands

The ingest command contains commands for ingesting data into a GeoWave data store.

Statistics Commands

The statistics or stat command contains commands for listing, removing, or recalculating statistics.

Analytic Commands

The analytic command contains commands for performing analytics on existing GeoWave datasets. Results of analytic jobs consist of vector or raster data stored in GeoWave.

Vector Commands

The vector command contains commands that are specific to vector data, this includes various export options.

Raster Commands

The raster command contains commands that are specific to raster data, such as resize commands.

Config Commands

The config command contains commands that affect the local GeoWave configuration. This includes commands to configure GeoServer, AWS, and HDFS.

GeoServer Commands

The geoserver or gs command contains commands for managing GeoWave data on a GeoServer instance. It includes several subcommands for managing workspaces, stores, layers, and styles.

Util Commands

The util command contains a lot of the miscellaneous operations that don’t really warrant their own top-level command. This includes commands to start standalone data stores and services.

Adding Data Stores

In order to start using GeoWave on a key/value store through the CLI, the store must be added to the GeoWave configuration. This is done through the store add command. For example:

$ geowave store add -t rocksdb example

This command takes in several options that are specific to the key/value store that is being used. It is important to note that this command does not create any data or make any modifications to the key/value store itself, it simply adds a configuration to GeoWave so that all of the connection parameters required to connect to the store are easily accessible to the CLI and can be referred to in future commands by a simple store name. For an exhaustive list of the configuration options available for each data store type, see the store add documentation.

Adding Indices

Before ingesting any data, an index must be added to GeoWave that understands how the ingested data should be organized in the key/value store. GeoWave provides out-of-the-box implementations for spatial, temporal, and spatial-temporal indices. These indices can be added to a data store through the index add command. For example:

$ geowave index add -t spatial example spatial_idx

When an index is added to GeoWave, the appropriate data store implementation will create a table in the key/value store for the indexed data, and information about the index will be added to the metadata. Because of this, when one user adds an index to a GeoWave data store, all users that connect to the same data store with the same configuration parameters will be able to see and use the index. All indices that are added to GeoWave are given an index name that can be used by other CLI operations to refer to that index. For more information about adding different types of indices to a data store, see the index add documentation.

Ingesting Data

Overview

In addition to raw data, the ingest process requires an adapter to translate the native data into a format that can be persisted into the data store. It also requires an index to determine how the data should be organized. The index keeps track of which common fields from the source data need to be maintained within the table to be used by fine-grained and secondary filters.

There are various ways to ingest data into a GeoWave store. The standard ingest localToGW command is used to ingest files from a local file system or from an AWS S3 bucket into GeoWave in a single process. For a distributed ingest (recommended for larger datasets) the ingest sparkToGW and ingest mrToGW commands can be used. Ingests can also be performed directly from HDFS or utilizing Kafka.

The full list of GeoWave ingest commands can be found in the GeoWave CLI Documentation.

For an example of the ingest process in action, see the Quickstart Guide.

Ingest Plugins

The CLI contains support for several ingest formats out of the box. You can list the available formats by utilizing the ingest listplugins command.

$ geowave ingest listplugins

This command lists all of the ingest format plugins that are currently installed and should yield a result similar to the following:

Available ingest formats currently registered as plugins:

  twitter:
    Flattened compressed files from Twitter API

  geotools-vector:
    all file-based vector datastores supported within geotools

  geolife:
    files from Microsoft Research GeoLife trajectory data set

  gdelt:
    files from Google Ideas GDELT data set

  stanag4676:
    xml files representing track data that adheres to the schema defined by STANAG-4676

  geotools-raster:
    all file-based raster formats supported within geotools

  gpx:
    xml files adhering to the schema of gps exchange format

  tdrive:
    files from Microsoft Research T-Drive trajectory data set

  avro:
    This can read an Avro file encoded with the SimpleFeatureCollection schema.  This schema is also used by the export tool, so this format handles re-ingesting exported datasets.

Statistics

When ingesting a large amount of data, it can be beneficial to configure the statistics on the data types to be ingested prior to actually ingesting any data in order to avoid having to run full table scans to calculate the initial value of those statistics. This can be done by performing the following steps:

Add the data types for the data that will be ingested by using the type add command, which is nearly identical to ingest localToGW, but does not ingest any data. If the data that is going to be ingested is not local, this command can still be used as long as there is a local source that matches the schema of the data to be ingested, such as a file with a single feature exported from the full data set.
Add any number of statistics to those data types by using the stat add command.
Ingest the data using any of the ingest commands.

Using this method, the initial values of all added statistics will be calculated during the ingest process.

Time Configuration

Sometimes it is necessary to provide additional configuration information for a vector ingest. For example, if you have multiple time fields and need to specify which one should be use for a temporal index. In these cases, the system property SIMPLE_FEATURE_CONFIG_FILE may be assigned to the name of a locally accessible JSON file defining the configuration.

Example

$ GEOWAVE_TOOL_JAVA_OPT="-DSIMPLE_FEATURE_CONFIG_FILE=myconfigfile.json"
$ geowave ingest localtogw ./ingest_data mystore myindex

If GeoWave was installed using the standalone installer, this property can be supplied to the geowave command by prepending it with -J:

$ geowave -J-DSIMPLE_FEATURE_CONFIG_FILE=myconfigfile.json ingest localtogw ./ingest_data mystore myindex

This configuration file serves the following purposes:

Selecting which temporal attribute to use in temporal indices.
Setting the names of the indices to update in WFS-T transactions via the GeoServer plugin.

The JSON file is made up of a list of configurations. Each configuration is defined by a class name and a set of attributes and are grouped by the vector type name.

Temporal Configuration

Temporal configuration may be necessary if your vector feature type has more than one temporal attribute. The class name for this configuration is org.locationtech.geowave.core.geotime.util.TimeDescriptors$TimeDescriptorConfiguration.

There are three attributes for the temporal configuration:

timeName
startRangeName
endRangeName

These attributes are associated with the name of a simple feature type attribute that references a time value. To index by a single time attribute, set timeName to the name of the single attribute. To index by a range, set both startRangeName and endRangeName to the names of the simple feature type attributes that define start and end time values.

For example, if you had a feature type named myFeatureTypeName with two time attributes captureTime and processedTime, but wanted to tell GeoWave to use the captureTime attribute for the temporal index, the configuration would look like the following:

{
  "configurations": {
    "myFeatureTypeName" : [
      {
        "@class" : "org.locationtech.geowave.core.geotime.util.TimeDescriptors$TimeDescriptorConfiguration",
        "timeName":"captureTime",
        "startRangeName":null,
        "endRangeName":null
      }
    ]
  }
}

Primary Index Identifiers

The class org.locationtech.geowave.adapter.vector.index.SimpleFeaturePrimaryIndexConfiguration is used to maintain the configuration of primary indices used for adding or updating simple features via the GeoServer plugin.

Example Configuration

All of the above configurations can be combined into a single configuration file. This would result in a configuration that looks something like the following:

{
  "configurations": {
    "myFeatureTypeName" : [
      {
        "@class" : "`org.locationtech.geowave.core.geotime.util.TimeDescriptors$TimeDescriptorConfiguration`",
        "startRangeName":null,
        "endRangeName":null,
        "timeName":"captureTime"
      },
      {
        "@class": "org.locationtech.geowave.adapter.vector.index.SimpleFeaturePrimaryIndexConfiguration",
        "indexNames": ["SPATIAL_IDX"]
      }
    ]
  }
}

See the Visibility Management section of the appendix for information about visibility management.

Queries

Overview

In order to facilitate querying GeoWave data from the CLI, a basic query language is provided. The idea behind the GeoWave Query Language (GWQL) is to provide a familiar way to easily query, filter, and aggregate data from a GeoWave data store. The query language is similar to SQL, but currently only supports SELECT and DELETE statements. These queries can be executed using the query command.

$ geowave query <store name> "<query>"

The examples below use a hypothetical data store called example with a type called countries. This type contains all of the countries of the world with some additional attributes such as population and year established.

SELECT Statement

The SELECT statement can be used to fetch data from a GeoWave data store. It supports column selection, aggregation, filtering, and limiting.

Simple Queries

A standard SELECT statement has the following syntax:

SELECT <attributes> FROM <typeName> [ WHERE <filter> ]

In this syntax, attributes can be a comma-delimited list of attributes to select from the type, or * to select all of the attributes. Attributes can also be aliased by using the AS operator. If an attribute or type name has some nonstandard characters, such as -, it can be escaped by surrounding the name in double quotes ("column-name"), backticks (`column-name`), or square brackets ([column-name]).

Examples

Selecting all attributes of each country:

SELECT * FROM countries

Selecting the geom, population, and established attributes from each country, but renaming geom to geometry for the output:

SELECT geom AS geometry, population, established, FROM countries

Aggregation Queries

Aggregations can also be done by using aggregation functions. Aggregation functions usually take an attribute as an argument, however, some aggregation functions work on the whole row as well, in which case * is accepted.

The following table shows the aggregation functions currently available through the query language.

Aggregation Function Parameters Description

Aggregation Function	Parameters	Description
COUNT	Attribute Name or `*`	If an attribute name is supplied, counts the number of non-null values for that attribute. If `*` is supplied, counts the number of features.
BBOX	Geometry Attribute Name or `*`	If a geometry attribute name is supplied, calculates the bounding box of all non-null geometries under that attribute. If `*` is supplied, calculates the bounding box of features using the default geometry.
SUM	Numeric Attribute Name	Calculates the sum of non-null values for the supplied attribute over the result set.
MIN	Numeric Attribute Name	Finds the minimum value of the supplied attribute over the result set.
MAX	Numeric Attribute Name	Finds the maximum value of the supplied attribute over the result set.

COUNT

Attribute Name or *

If an attribute name is supplied, counts the number of non-null values for that attribute. If * is supplied, counts the number of features.

BBOX

Geometry Attribute Name or *

If a geometry attribute name is supplied, calculates the bounding box of all non-null geometries under that attribute. If * is supplied, calculates the bounding box of features using the default geometry.

SUM

Numeric Attribute Name

Calculates the sum of non-null values for the supplied attribute over the result set.

MIN

Numeric Attribute Name

Finds the minimum value of the supplied attribute over the result set.

MAX

Numeric Attribute Name

Finds the maximum value of the supplied attribute over the result set.

It’s important to note that aggregation queries cannot be mixed with non-aggregated columns. If one of the column selectors has an aggregation function, all of the column selectors need to have an aggregation function.

Examples

Counting the number of countries:

SELECT COUNT(*) FROM countries

Calculating the total population of all countries:

SELECT SUM(population) FROM countries

Getting the bounding box, minimum population, and maximum population of all countries, using aliases to rename the results:

SELECT BBOX(*) AS bounds, MIN(population) AS minPop, MAX(population) AS maxPop FROM countries

Limit

It is often the case where not all of the data that matches the query parameters is necessary, in this case we can add a LIMIT to the query to limit the number of results returned. This can be done using the following syntax:

SELECT <attributes> FROM <typeName> [ WHERE <filter> ] LIMIT <count>

While LIMIT can be specified for aggregation queries, it doesn’t often make sense and can produce different results based on the underlying data store implementation.

Examples

Getting a single country from the dataset:

SELECT * FROM countries LIMIT 1

Getting 5 countries that have a population over 100 million:

SELECT * FROM countries WHERE population > 100000000 LIMIT 5

DELETE Statement

The DELETE statement can be used to delete data from a GeoWave data store. It can either delete an entire type, or only data that matches a given filter. It has the following syntax:

DELETE FROM <typeName> [ WHERE <filter> ]

When all of the data of a given type is removed, that type is removed from the data store completely. Additionally, if that data represented the last data in an index, the index will also be removed.

Examples

Removing all countries from the data store:

DELETE FROM countries

Removing all countries that have a population less than 100 million:

DELETE FROM countries WHERE population < 100000000

Filtering

All GWQL queries support filtering through the use of filter expressions. GeoWave supports filtering on many different expression types, each of which have their own supported predicates and functions. Multiple filter expressions can also be combined using AND and OR operators (e.g. a > 10 AND b < 100. Filter expressions can also be inverted by prepending it with NOT (e.g. NOT strContains(name, 'abc'))

In GWQL, function casing is not important; STRCONTAINS(name, 'abc') is equivalent to strContains(name, 'abc').

Numeric Expressions

Numeric expressions support all of the standard comparison operators: <, >, ⇐, >=, =, <> (not equal), IS NULL, IS NOT NULL, and BETWEEN … AND …. Additionally the following mathematics operations are supported: +, -, *, /. The operands for any of these operations can be a numeric literal, a numeric attribute, or another numeric expression.

Functions

Numeric expressions support the following functions:

Function	Parameters	Description
ABS	Numeric Expression	Transforms the numeric expression into one that represents the absolute value of the input expression. For example, the literal -64 would become 64.

Function

Parameters

Description

ABS

Numeric Expression

Transforms the numeric expression into one that represents the absolute value of the input expression. For example, the literal -64 would become 64.

Examples

Selecting only countries that have a population over 100 million:

SELECT * FROM countries WHERE population > 100000000

Counting the number of countries in which the male population exceeds the female one (this assumes that each feature has an attribute for malePop and femalePop):

SELECT COUNT(*) FROM countries WHERE malePop > femalePop

Selecting only countries that have a population between 10 and 20 million:

SELECT * FROM countries WHERE population BETWEEN 10000000 AND 20000000

Selecting only countries where the difference between the male and female population exceeds 50000:

SELECT * FROM countries WHERE ABS(femalePop - malePop) > 50000

Text Expressions

Text expressions support all of the standard comparison operators: <, >, ⇐, >=, =, <> (not equal), IS NULL, IS NOT NULL, and BETWEEN … AND …. These operators will lexicographically compare the operands to determine if the filter is passed.

Functions

Text expressions support the following functions:

Function	Parameters	Description
CONCAT	Text Expression, Text Expression	Concatenates two text expressions into a single text expression.
STRSTARTSWITH	Text Expression, Text Expression [, Boolean]	A predicate function that returns true when the first text expression starts with the second text expression. A third boolean parameter can also be supplied that will specify whether or not to ignore casing. By default, casing will NOT be ignored.
STRENDSWITH	Text Expression, Text Expression [, Boolean]	A predicate function that returns true when the first text expression ends with the second text expression. A third boolean parameter can also be supplied that will specify whether or not to ignore casing. By default, casing will NOT be ignored.
STRCONTAINS	Text Expression, Text Expression [, Boolean]	A predicate function that returns true when the first text expression contains the second text expression. A third boolean parameter can also be supplied that will specify whether or not to ignore casing. By default, casing will NOT be ignored.

Function

Parameters

Description

CONCAT

Text Expression, Text Expression

Concatenates two text expressions into a single text expression.

STRSTARTSWITH

Text Expression, Text Expression [, Boolean]

A predicate function that returns true when the first text expression starts with the second text expression. A third boolean parameter can also be supplied that will specify whether or not to ignore casing. By default, casing will NOT be ignored.

STRENDSWITH

Text Expression, Text Expression [, Boolean]

A predicate function that returns true when the first text expression ends with the second text expression. A third boolean parameter can also be supplied that will specify whether or not to ignore casing. By default, casing will NOT be ignored.

STRCONTAINS

Text Expression, Text Expression [, Boolean]

A predicate function that returns true when the first text expression contains the second text expression. A third boolean parameter can also be supplied that will specify whether or not to ignore casing. By default, casing will NOT be ignored.

Examples

Selecting only countries that start with 'm' or greater

SELECT * FROM countries WHERE name > 'm'

Counting the number of countries that end with 'stan':

SELECT COUNT(*) FROM countries WHERE strEndsWith(name, 'stan')

Selecting only countries that contain 'state', ignoring case:

SELECT * FROM countries WHERE strContains(name, 'state', true)

Temporal Expressions

Temporal expressions support all of the standard comparison operators: <, >, ⇐, >=, =, <> (not equal), IS NULL, IS NOT NULL, and BETWEEN … AND …. Temporal expressions can also be compared using temporal comparison operators: BEFORE, BEFORE_OR_DURING, DURING, DURING_OR_AFTER, and AFTER.

Temporal expressions can represent either a time instant or a time range. An instant in time can be specified as text literals using one of the following date formats: yyyy-MM-dd HH:mm:ssZ, yyyy-MM-dd’T’HH:mm:ss’Z', yyyy-MM-dd, or as a numeric literal representing the epoch milliseconds since January 1, 1970 UTC. A time range can be specified as a text literal by combining two dates separated by a /. For example, a time range of January 8, 2020 at 11:56 AM to February 12, 2020 at 8:20 PM could be defined as '2020-01-08T11:56:00Z/2020-02-12T20:20:00Z'. Time ranges are inclusive on the start date and exclusive on the end date.

If the left operand of a temporal operator is a temporal field (such as Date), then the right operand can be inferred from a numeric or text literal. If the left operand of a temporal expression is a numeric or text literal, it can be cast to a temporal expression using the <expression>::date syntax.

Functions

Temporal expressions support the following functions:

Function	Parameters	Description
TCONTAINS	Temporal Expression, Temporal Expression	A predicate function that returns true if the first temporal expression fully contains the second.
TOVERLAPS	Temporal Expression, Temporal Expression	A predicate function that returns true when the first temporal expression overlaps the second temporal expression at any point

Function

Parameters

Description

TCONTAINS

Temporal Expression, Temporal Expression

A predicate function that returns true if the first temporal expression fully contains the second.

TOVERLAPS

Temporal Expression, Temporal Expression

A predicate function that returns true when the first temporal expression overlaps the second temporal expression at any point

Examples

Selecting only countries that were established after 1750

SELECT * FROM countries WHERE established AFTER '1750-12-31'

Counting the number of countries that were established in the 1700s:

SELECT COUNT(*) FROM countries WHERE established DURING '1700-01-01T00:00:00Z/1800-01-01T00:00:00Z'

Counting the number of countries that are still active:

SELECT COUNT(*) FROM countries WHERE dissolution IS NULL

Spatial Expressions

Spatial expressions are used to compare geometries. The only comparison operators that are supported are =, <> (not equal), IS NULL and IS NOT NULL. The equality operators will topologically compare the left spatial expression to the right spatial expression. Most comparisons with spatial expressions will be done through one of the provided predicate functions.

Literal spatial expressions can be defined by a well-known text (WKT) string such as 'POINT(1 1)'. If a text literal needs to be explicitly cast as a spatial expression, such as when it is the left operand of an equality check, it can be done using the <expression>::geometry syntax.

Functions

Spatial expressions support the following functions:

Function	Parameters	Description
BBOX	Spatial Expression, Min X, Min Y, Max X, Max Y, [, CRS code]	A predicate function that returns true if the spatial expression intersects the provided bounds. An optional CRS code can be provided if the bounding dimensions are not in the default WGS84 projection.
BBOXLOOSE	Spatial Expression, Min X, Min Y, Max X, Max Y, [, CRS code]	A predicate function that returns true if the spatial expression intersects the provided bounds. An optional CRS code can be provided if the bounding dimensions are not in the default WGS84 projection. This can provide a performance boost over the standard BBOX function at the cost of being overly inclusive with the results.
INTERSECTS	Spatial Expression, Spatial Expression	A predicate function that returns true if the first spatial expression intersects the second spatial expression.
INTERSECTSLOOSE	Spatial Expression, Spatial Expression	A predicate function that returns true if the first spatial expression intersects the second spatial expression. This can provide a performance boost over the standard INTERSECTS function at the cost of being overly inclusive with the results.
DISJOINT	Spatial Expression, Spatial Expression	A predicate function that returns true if the first spatial expression is disjoint (does not intersect) to the second spatial expression.
DISJOINTLOOSE	Spatial Expression, Spatial Expression	A predicate function that returns true if the first spatial expression is disjoint (does not intersect) to the second spatial expression. This can provide a performance boost over the standard INTERSECTS function at the cost of being overly inclusive with the results.
CROSSES	Spatial Expression, Spatial Expression	A predicate function that returns true if the first spatial expression crosses the second spatial expression.
CROSSES	Spatial Expression, Spatial Expression	A predicate function that returns true if the first spatial expression crosses the second spatial expression.
OVERLAPS	Spatial Expression, Spatial Expression	A predicate function that returns true if the first spatial expression overlaps the second spatial expression.
TOUCHES	Spatial Expression, Spatial Expression	A predicate function that returns true if the first spatial expression touches the second spatial expression.
WITHIN	Spatial Expression, Spatial Expression	A predicate function that returns true if the first spatial expression lies completely within the second spatial expression.
CONTAINS	Spatial Expression, Spatial Expression	A predicate function that returns true if the first spatial expression completely contains the second spatial expression.

Function

Parameters

Description

BBOX

Spatial Expression, Min X, Min Y, Max X, Max Y, [, CRS code]

BBOXLOOSE

Spatial Expression, Min X, Min Y, Max X, Max Y, [, CRS code]

A predicate function that returns true if the spatial expression intersects the provided bounds. An optional CRS code can be provided if the bounding dimensions are not in the default WGS84 projection. This can provide a performance boost over the standard BBOX function at the cost of being overly inclusive with the results.

INTERSECTS