geo_distance filter draws a circle around the specified location and
finds all documents that have a geo-point within that circle:
The central point can be specified as a string, an array, or (as in this example) an object. See Lat/Lon Formats.
A geo-distance calculation is expensive. To optimize performance, Elasticsearch draws a box around the circle and first uses the less expensive bounding-box calculation to exclude as many documents as it can. It runs the geo-distance calculation on only those points that fall within the bounding box.
Do your users really require an accurate circular filter to be applied to their results? Using a rectangular bounding box is much more efficient than geo-distance and will usually serve their purposes just as well.
The distance between two points can be calculated using algorithms, which trade performance for accuracy:
The slowest but most accurate is the
arccalculation, which treats the world as a sphere. Accuracy is still limited because the world isn’t really a sphere.
planecalculation, which treats the world as if it were flat, is faster but less accurate. It is most accurate at the equator and becomes less accurate toward the poles.
So called because it uses the
SloppyMathLucene class to trade accuracy for speed, the
sloppy_arccalculation uses the Haversine formula to calculate distance. It is four to five times as fast as
arc, and distances are 99.9% accurate. This is the default calculation.
You can specify a different calculation as follows:
Will your users really care if a restaurant is a few meters outside their specified radius? While some geo applications require great accuracy, less-accurate but faster calculations will suit the majority of use cases just fine.
The only difference between the
filters is that the latter has a doughnut shape and excludes documents within
the central hole.
Instead of specifying a single
distance from the center, you specify a
minimum distance (with
gte) and maximum distance (with
lte), just like a