What's missing
ST_KNN is geometry-only, so a k-nearest-neighbour join cannot rank candidates by geodesic
distance over geography columns.
-- 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 #2830.
What's missing
ST_KNNis geometry-only, so a k-nearest-neighbour join cannot rank candidates by geodesicdistance over geography columns.
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_spheroidflag has no meaningwhen 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 #2830.