jiayuasu opened a new issue, #1087:
URL: https://github.com/apache/sedona-db/issues/1087
## Description
`docs/reference/sql/st_collect_agg.qmd` and
`docs/reference/sql/st_makeline.qmd` declare only a `geometry` kernel:
```yaml
# st_collect_agg.qmd
kernels:
- returns: geometry
args: [geometry]
# st_makeline.qmd
kernels:
- returns: geometry
args: [geometry, geometry]
```
But 0.4.0 accepts **geography** for both, and returns geography:
```python
import json, sedonadb
sd = sedonadb.connect()
opts = json.dumps({"geom_type": "Point", "bounds": [0, 0, 10, 10], "seed":
11})
sd.sql(f"SELECT id, ST_GeogFromWKB(ST_AsBinary(geometry)) AS geog, "
f"ST_GeomFromWKB(ST_AsBinary(geometry)) AS geom "
f"FROM sd_random_geometry('{opts}') LIMIT 50").to_view("t",
overwrite=True)
sd.sql("SELECT id, geog, geom FROM t").to_view("u", overwrite=True)
sd.sql("SELECT ST_GeometryType(ST_Collect_Agg(geog)) FROM t").to_pandas()
# -> ST_MultiPoint
sd.sql("SELECT ST_Area(ST_ConvexHull(ST_Collect_Agg(geog))) FROM
t").to_pandas()
# -> 970542623930.96 (m^2 -- the spherical path)
sd.sql("""SELECT ST_Length(ST_MakeLine(a.geog, b.geog))
FROM t a, u b WHERE a.id = 1 AND b.id = 2""").to_pandas()
# -> 865168.17 (metres)
sd.sql("""SELECT ST_Length(ST_MakeLine(a.geom, b.geom))
FROM t a, u b WHERE a.id = 1 AND b.id = 2""").to_pandas()
# -> 7.87 (degrees -- same two points, geometry overload)
```
865 168 m vs 7.87 degrees for the same pair of points confirms these are
really going through the geography path, not silently downcasting to geometry.
## Suggested fix
Add the geography overloads to the `kernels:` blocks:
```yaml
# st_collect_agg.qmd
kernels:
- returns: geometry
args: [geometry]
- returns: geography
args: [geography]
# st_makeline.qmd
kernels:
- returns: geometry
args: [geometry, geometry]
- returns: geography
args: [geography, geography]
```
It would also be worth auditing the other `.qmd` kernel lists against the
registry, in case more geography overloads are undocumented — a generated check
would keep them honest.
## Why it matters
The `kernels:` metadata is the natural place to look when working out what
the geography type can do. Taking it at face value, I concluded that
SpatialBench's Q5 (`ST_Collect_Agg` + `ST_ConvexHull`) and Q7 (`ST_MakeLine` +
`ST_Length`) had no geography formulation, and shipped them as
documented-but-unimplemented. Both in fact work on 0.4.0, so ten of the twelve
SpatialBench queries have a working geography version rather than eight.
## Environment
- `sedonadb` 0.4.0 (PyPI wheel), Python 3.13, macOS arm64
- `sedonadb.__features__ == ['s2geography']`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
