What's missing
ST_X and ST_Y have no geography overload, so extracting longitude/latitude from a
geography point requires a conversion back to geometry.
-- wanted
SELECT ST_X(geog) AS lon, ST_Y(geog) AS lat FROM ...;
Why
Minor but papercut-ish. SpatialBench's geography Q1 projects the pickup longitude and latitude
alongside a geodesic distance; because these accessors are geometry-only, the query reads the
same WKB column twice — once as geography for ST_DWithin/ST_Distance and once as geometry
for the coordinates:
ST_X(ST_GeomFromWKB(t_pickuploc)) AS pickup_lon,
ST_Distance(ST_GeogFromWKB(t_pickuploc), ...) AS distance_to_center
That is correct — a point's coordinates are identical under either edge interpretation — but it
is awkward, and it means a geography-typed column would need ST_GeogToGeometry first.
Likely a good first issue: the value is a straight passthrough of the stored coordinate, with
no spherical maths involved.
Reference
SedonaDB implements ST_X(geography) and ST_Y(geography).
Part of #2830.
What's missing
ST_XandST_Yhave no geography overload, so extracting longitude/latitude from ageography point requires a conversion back to geometry.
Why
Minor but papercut-ish. SpatialBench's geography Q1 projects the pickup longitude and latitude
alongside a geodesic distance; because these accessors are geometry-only, the query reads the
same WKB column twice — once as geography for
ST_DWithin/ST_Distanceand once as geometryfor the coordinates:
That is correct — a point's coordinates are identical under either edge interpretation — but it
is awkward, and it means a geography-typed column would need
ST_GeogToGeometryfirst.Likely a good first issue: the value is a straight passthrough of the stored coordinate, with
no spherical maths involved.
Reference
SedonaDB implements
ST_X(geography)andST_Y(geography).Part of #2830.