I’ve been looking for an answer to this around the internet, but I want to get some clarity before sinking time into it. The question is whether geo_shape geometry properly handles polar-encircling geometries. I haven’t been able to find documentation on how ES represents geometry beyond using a BKD tree. Does it have a notion that geometries are on a sphere, or is it an internal Cartesian representation with special handling of the antimeridian? Would love a clear statement of how ES treats its geometry. Thanks!
You are right that the Elasticsearch documentation does not sufficiently describe this, and we’ll try to improve the docs to make this clearer.
When I searched for existing explanations, the clearest description I found was in a blog post on Geospatial distance search with ES|QL, which explains that distance functions treat latitude and longitude as points on a sphere and compute Haversine distances assuming WGS84 coordinates.
However, the underlying Lucene index is planar and does not properly support geometries involving the poles, as you suspected. This applies to both geo_point and geo_shape. Elasticsearch does include special handling for the antimeridian (dateline), so geometries can cross the dateline correctly, but there is no equivalent support for the poles.
This also means that polygon edges are interpreted as straight lines in planar latitude/longitude space. These edges do not correspond to rhumb lines in a Mercator projection, nor to great-circle arcs on a sphere. For smaller geometries this difference is usually negligible, but for very large shapes it can lead to results that differ from systems using true spherical ‘geography’ data types.
In practice, Elasticsearch geo_shape behaves much more like a planar geometry type, with the notable exception that distance calculations are spherical. Full spherical support would require dedicated ‘geography’ data types, indexes, and calculations, which Elasticsearch does not currently implement.
2 Likes