Add Geography support for ST_KNN
- Dominant language
- Java
- Stars
- 2.4k
- Forks
- 784
- Avg merge
- 1d 12h
- Merged PRs (30d)
- 58
Description
## What's missing
`ST_KNN` is geometry-only, so a k-nearest-neighbour join cannot rank candidates by geodesic
distance over geography columns.
```sql
-- wanted
SELECT ... FROM trips t JOIN buildings b ON ST_KNN(t.geog, b.geog, 5);
```
For geography, spherical ranking is the definition rather than an option, so a 3-argument
signature seems the natural one — the geometry overload's `use_spheroid` flag has no meaning
when the inputs are already geographic.
## Why
This blocks the geography form of SpatialBench Q12, which ranks trip pickups by the average
distance to their five nearest buildings. It is the only one of the twelve SpatialBench
queries with no geography formulation on any engine today, so it is defined in the docs but
not carried in the runnable suite: https://github.com/apache/sedona-spatialbench/blob/main/spatialbench-queries/print_geography_queries.py
## Note
SedonaDB does not have this either — tracked as apache/sedona-db#1086 — so the two engines are
in the same position here.
Part of https://github.com/apache/sedona/issues/2830.
Contributor guide
Research direction
Start with the existing geometry overload of ST_KNN and the SpatialBench Q12 definition in print_geography_queries.py. Verify how the three-argument geography form should rank candidates by geodesic distance, then ensure the geography formulation is included in the runnable suite with coverage for the requested five-nearest-building query.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- sql
- Domain
- databases
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100