Skip to main content
Check out the best practices for handling geometries to learn more about the different aspects to consider when working with geometries, including antimeridian crossings and pole coverings.
When querying, you can specify arbitrary geometries as an area of interest. Tilebox currently supports Polygon and MultiPolygon geometries as query filters.

Filtering by Area of Interest

To filter by an area of interest, use a Polygon or MultiPolygon geometry as the spatial extent parameter. Here is how to query Sentinel-2 L2A data over Colorado for a specific day in April 2025.

Spatial filter modes

The spatial filter mode controls the relationship between the filter geometry and each returned datapoint geometry. Containment mode names identify which geometry contains the other.
Examples of intersects, filter contains geometry, and geometry contains filter modesExamples of intersects, filter contains geometry, and geometry contains filter modes

The three spatial filter modes

Intersects

The intersects mode is the default for spatial queries. It matches all datapoints whose geometries intersect with the filter geometry.
Output

Filter contains geometry

The filter_contains_geometry mode matches datapoints whose geometries are fully contained within the filter geometry.
Output

Geometry contains filter

The geometry_contains_filter mode matches datapoints whose geometries fully contain the filter geometry. For example, a small filter geometry within Colorado can match a datapoint whose geometry covers the entire state.

Antimeridian Crossings

In many applications, geometries that cross the antimeridian cause issues. Since such geometries are common in satellite data, Tilebox does take extra care to handle them out of the box correctly, by building the necessary internal spatial index structures in a way that correctly handles antimeridian crossings and pole coverings. To get accurate results also at query time, it’s recommend to use the spherical coordinate reference system for querying (which is the default), as it correctly handles the non-linearity introduced by the antimeridian in cartesian space.
Even if you stick to the spherical coordinate reference system when querying, it’s still recommended to follow the best practices for handling geometries. In doing so, you can ensure that no geometry related issues will arise even when interfacing with other libraries and tools that may not properly support non-linearities in geometries.

Coordinate reference system

Geometry intersection and containment checks can either be performed in a 3D spherical coordinate system or in a standard 2D cartesian lat/lon coordinate system.
Spherical coordinate reference systemSpherical coordinate reference system

Spherical coordinate reference system

Cartesian coordinate reference systemCartesian coordinate reference system

Cartesian coordinate reference system

Spherical

The spherical coordinate reference system is the default and recommended choice. It correctly handles antimeridian crossings and is the most robust option, regardless of how datapoint geometries are cut along the antimeridian.
To learn more about antimeridian crossings and how to handle them correctly, check out the Antimeridian Crossings section above.
When querying with the spherical coordinate reference system, Tilebox automatically converts all geometries to their x, y, z coordinates on the unit sphere and performs the intersection and containment checks in 3D.

Cartesian

Tilebox can also be configured to use a standard 2D cartesian lat/lon coordinate system for geometry intersection and containment checks. This is done by specifying the cartesian coordinate reference system when querying.
When using the cartesian coordinate system, antimeridian crossings may cause issues if datapoint geometries or the query geometry do not properly respect the antimeridian cut. Check out the best practices for handling geometries to learn more about how to avoid such issues.