Skip to main content
This page shows one example of each kind of spatial query in WherobotsDB. For how WherobotsDB plans each join, with physical plans and more variants, see Optimizers.

Transform the Coordinate Reference System

Planar distances in Spatial SQL use the unit of the geometries in the Geometry column, degrees or meters. To convert the Coordinate Reference System of the Geometry column in the spatialdf view from Load Data From External Storage, use ST_Transform. This saves the result as the countydf view, which the range and KNN queries below read:
The first EPSG code, EPSG:4326, is the source CRS of the geometries. It is WGS84, the most common degree-based CRS. The second EPSG code, EPSG:3857, is the target CRS, the most common meter-based CRS. For the supported CRS formats and grid files, see CRS Transformation.

Range query

Use ST_Contains, ST_Intersects, ST_Within to run a range query over a single column. The following example finds all counties that are within the given polygon:
Read Spatial SQL API to learn how to create a Geometry type query window

KNN query

Use ST_Distance to calculate the distance and rank the distance. The following code returns the 5 nearest neighbor of the given polygon.

Range join

A range join finds geometries from A and geometries from B such that each geometry pair satisfies a certain predicate, such as ST_Contains, ST_Intersects, or ST_Within:
WherobotsDB join performance is heavily affected by the number of partitions. If the join performance is not ideal, please increase the number of partitions by doing df.repartition(XXX) right after you create the original DataFrame.
For the supported predicates and the physical plan, see Range join.

Distance join

A distance join finds geometries from A and geometries from B such that the distance of each geometry pair is less than or equal to a certain distance:
ST_Distance is a planar distance in the unit of the geometries, so for longitude and latitude data the distance is in degrees. For distances in meters, use ST_DistanceSpheroid or ST_DistanceSphere:
For the other distance functions, the difference between < and <=, and the limits of geodesic distance joins, see Distance join.

Broadcast index join

A broadcast index join broadcasts one side of a range join or distance join and builds a spatial index on it, so the other side keeps its partitioning and isn’t shuffled. Add a broadcast hint to the side to broadcast:
When one table is smaller than a threshold, WherobotsDB chooses a broadcast index join automatically. For the supported join types and the threshold, see Broadcast index join.

K Nearest-Neighbor join / KNN join

A KNN join returns the k nearest geometries from the objects side table for each geometry in the queries side table:
This query returns the 4 nearest neighbors from the OBJECTS table for each geometry in the QUERIES table based on planar Euclidean distance, measured in the geometries’ coordinate units. Set the fourth argument to TRUE to use great-circle distance on a sphere, in meters. For the distance models, the optional search radius, the approximate ST_AKNN join, and more examples, see Nearest-Neighbor Searching.

Create a User-Defined Function (UDF)

User-Defined Functions (UDFs) are user-created procedures that can perform operations on a single row of information. To cover almost all use cases, we will showcase 4 types of UDFs for a better understanding of how to use geometry with UDFs. Sedona’s serializer deserializes the SQL geometry type to JTS Geometry (Scala/Java) or Shapely Geometry (Python). You can implement any custom logic using the rich ecosystem around these two libraries.

Geometry to primitive

This UDF example takes a geometry type input and returns a primitive type output:
Output:

Geometry to Geometry

This UDF example takes a geometry type input and returns a geometry type output:
Output of the Scala and Java examples:
The Python UDF buffers with Shapely, which approximates each quarter circle with 16 segments where JTS uses 8, so its polygon has more vertices and differs after the first one: it starts POLYGON ((1 -4.5, 0.4609057281874175 -4.4735159....

Geometry, primitive to geometry

This UDF example takes a geometry type input and a primitive type input and returns a geometry type output:
Output of the Scala and Java examples:
For the same reason, the Python UDF’s polygon starts POLYGON ((1 -9, 0.0198285967043955 -8.951847266....

Geometry, primitive to Geometry, primitive

This UDF example takes a geometry type input and a primitive type input and returns a geometry type and a primitive type output:
Output of the Scala and Java examples:
The Python UDF buffers with Shapely, which approximates each quarter circle with 16 segments where JTS uses 8, so it returns a length of 66.22083670146812.

Spatial vectorized UDFs (Python only)

By default, when you create a user defined function (UDF) in Python, that function isn’t vectorized. Processing User-Defined Functions (UDFs) one row at a time often leads to slower performance. A faster alternative is to use vectorized UDFs, which leverage Apache Arrow to handle data in batches. To create a vectorized UDF, use the @sedona_vectorized_udf decorator. Currently, @sedona_vectorized_udf supports scalar UDFs. Vectorized UDFs offer significantly improved performance, potentially running up to 2x faster than standard UDFs.
When you use geometry as an input type, please include the BaseGeometry type, like Point from shapely or geopandas GeoSeries, when you use GEO_SERIES vectorized UDF. That’s how Sedona infers the type and knows if the data should be cast.
The decorator’s signature is the following:
udf_type is the type of the UDF function. Supported UDF types are:
  • SHAPELY_SCALAR
  • GEO_SERIES
Let’s examine the two examples below, which create buffers from a given geometry:

Shapely scalar UDF

GeoSeries UDF

To call the UDFs, you can use the following code:

S2/H3 based approximate equi-join

When the performance of the WherobotsDB-optimized join doesn’t suit your workflow needs, possibly because of intricate and overlapping geometries, WherobotsDB also provides Google S2 or Uber H3-based approximate equi-joins. Generate cell IDs for both tables with ST_S2CellIDs or ST_H3CellIDs, then join the tables on the cell ID:
For the full steps, including how to refine and de-duplicate the results and how to run a distance join this way, see S2 or H3 based approximate equi-join.

Other queries

There are lots of other functions can be combined with these queries. Please read Spatial SQL API.