ES|QL ST_DISTANCE Function

[craigtaverner]

Initial work in support of #108212

This PR covers the addition of one new spatial function:

• ST_DISTANCE(geomA, geomB) which returns a double value

This function can be used for calcualting distance, filtering results by distance and sorting by distance:

Distance calculations

FROM airports
| EVAL distance = ST_DISTANCE(location, city_location)

Filtering results

FROM airports
| WHERE ST_DISTANCE(location, TO_GEOPOINT("POINT(12 55)")) < 500000

Sorting results

FROM airports
| EVAL distance = ST_DISTANCE(location, TO_GEOPOINT("POINT(12 55)"))
| SORT distance ASC

Example

We can use it for all three capabilities in the same query:

FROM airports
| WHERE ST_DISTANCE(location, TO_GEOPOINT("POINT(12.565 55.673)")) < 600000
| EVAL distance = ROUND(ST_DISTANCE(location, TO_GEOPOINT("POINT(12.565 55.673)"))/1000,2)
| EVAL city_distance = ROUND(ST_DISTANCE(city_location, TO_GEOPOINT("POINT(12.565 55.673)"))/1000,2)
| KEEP abbrev, name, location, country, city, city_location, distance, city_distance
| SORT distance ASC
| LIMIT 10

Which results in something like:

abbrev:k | name:text               | location:geo_point                       | country:k | city:k          | city_location:geo_point | distance:d | city_distance:d    
CPH      | Copenhagen              | POINT(12.6493508684508 55.6285017221528) | Denmark   | Copenhagen      | POINT(12.5683 55.6761)  | 7.24       | 0.4
GOT      | Gothenburg              | POINT(12.2938269092573 57.6857493534879) | Sweden    | Gothenburg      | POINT(11.9675 57.7075)  | 224.42     | 229.15
HAM      | Hamburg                 | POINT(10.005647830925 53.6320011640866)  | Germany   | Norderstedt     | POINT(10.0103 53.7064)  | 280.34     | 273.42
TXL      | Berlin-Tegel Int'l      | POINT(13.2903090925074 52.5544287044101) | Germany   | Hohen Neuendorf | POINT(13.2833 52.6667)  | 349.97     | 337.53
BRE      | Bremen                  | POINT(8.7858617703132 53.052287104156)   | Germany   | Bremen          | POINT(8.8 53.0833)      | 380.5      | 377.22
NRK      | Norrköping Airport      | POINT(16.2339407695814 58.5833805017541) | Sweden    | Norrköping      | POINT(16.2 58.6)        | 392.0      | 392.35
GDN      | Gdansk Lech Walesa      | POINT(18.4684422165911 54.3807025352925) | Poland    | Gdańsk          | POINT(18.6453 54.3475)  | 402.61     | 414.59
NYO      | Stockholm-Skavsta       | POINT(16.9216055584254 58.7851041303448) | Sweden    | Nyköping        | POINT(17.0086 58.7531)  | 433.99     | 434.43
OSL      | Oslo Gardermoen         | POINT(11.0991032762581 60.1935783171386) | Norway    | Oslo            | POINT(10.7389 59.9133)  | 510.03     | 483.71
DRS      | Dresden                 | POINT(13.7649671440047 51.1250912428871) | Germany   | Dresden         | POINT(13.74 51.05)      | 511.9      | 519.91

This function was conceptually based on the similarly named PostGIS function, ST_DISTANCE, but also satisfies the needs of a related PostGIS function, ST_DWITHIN.

There are a few differences between ES|QL and PostGIS:

• In PostGIS the geometries can be any supported spatial geometry, and the closest distance between the geometries will be calculated. In ES|QL we only support distances between points. Supporting closest distance between shapes could be considered in future.
• In PostGIS the ST_DISTANCE function cannot benefit directly from the spatial index, and is usually used in combination with a bounding box query to achieve higher performance results. PostGIS recommends the usage of ST_DWITHIN for index-based distance filtering in WHERE clauses. In ES|QL we can optimise ST_DISTANCE for filtering, and so do not need to implement ST_DWITHIN at all.
• In PostGIS the distance is always the cartesian distance for the CRS, while in ES|QL with geo_point data types we perform a haversin distance. This is because ES|QL prioritises compatibility with Elasticsearch's _search API (and the underlying Lucene implementation) over perfect compatibility with OGC or PostGIS.

Things not done in the PR and planned for followup work:

• Lucene pushdown for the WHERE clause. In this case we plan to re-write compatible ST_DISTANCE functions into ST_DWITHIN functions and then push the ST_DWITHIN down to lucene, using geo_distance
• Sorting at the index level, using the _geo_distance sort field
• Aggregations based on distance

[elasticsearchmachine]

Hi @craigtaverner, I've created a changelog YAML for you.

[elasticsearchmachine]

Hi @craigtaverner, I've updated the changelog YAML for you.

[iverase]

The PR is suppose to add a distance function, but it seems you are adding two functions here. I disagree on introducing two functions for the same thing. Let's keep it simple and only add ST_DISTANCE?

[elasticsearchmachine]

Hi @craigtaverner, I've updated the changelog YAML for you.

[iverase]

LGTM

[craigtaverner]

@elasticsearchmachine update branch

[craigtaverner]

The work done on ST_DWITHIN has been moved into a separate PR for later consideration at #109985

[astefan]

LGTM

[luigidellaquila]

Thanks Craig, LGTM!

[craigtaverner]

@elasticsearchmachine update branch