Geo Optimizations and Features

Heya,

A considerable performance improvement to geo distance based filters and
computation has been pushed to master:
https://github.com/elasticsearch/elasticsearch/issues/1261.

Also, geo point type mapping features have been added. By default,
normalization will now be performed on points, and validation is by default
on as well: https://github.com/elasticsearch/elasticsearch/issues/1262.

In general, we can also do similar bounding box optimization to polygon
filter, by trying to derive the bounding box around it, but this only make
sense if either we assume the points do not cross the meridian (for
example), or, we assume the points are provided in some sort of order. This
can possibly be faster compared to "and'ing" with a bounding box filter
(less operations). What do people think?

Sounds like a great idea. Note the requirements and let people use it.

  • Craig

On Thu, Aug 18, 2011 at 10:29 PM, Shay Banon kimchy@gmail.com wrote:

Heya,

A considerable performance improvement to geo distance based filters and
computation has been pushed to master:
Geo Distance Filter Bounding Box Optimization · Issue #1261 · elastic/elasticsearch · GitHub.

Also, geo point type mapping features have been added. By default,
normalization will now be performed on points, and validation is by default
on as well: Geo Type Mapping: Add normalize flag (default to true), and default validate to true · Issue #1262 · elastic/elasticsearch · GitHub.

In general, we can also do similar bounding box optimization to polygon
filter, by trying to derive the bounding box around it, but this only make
sense if either we assume the points do not cross the meridian (for
example), or, we assume the points are provided in some sort of order. This
can possibly be faster compared to "and'ing" with a bounding box filter
(less operations). What do people think?

--

CRAIG BROWN
chief architect
youwho, Inc.

www.youwho.com http://www.youwho.com/

T: 801.855. 0921
M: 801.913. 0939

That improvement looks good, can't wait to try it out.

Re: polygons, the faster the better, but I think it's quite easy to have
polygons that cross the meridian though... how would we have to order the
points? It would be worth it for the performance, but maybe that
optimisation should be turned off by default? (and turned on by those who
knew what they were doing?)

By order I means some way to easily derive the bounding box around the
provided polygons.

On Sat, Aug 20, 2011 at 1:16 AM, Ian Clark ian.andrew.clark@gmail.comwrote:

That improvement looks good, can't wait to try it out.

Re: polygons, the faster the better, but I think it's quite easy to have
polygons that cross the meridian though... how would we have to order the
points? It would be worth it for the performance, but maybe that
optimisation should be turned off by default? (and turned on by those who
knew what they were doing?)