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?
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?
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?)
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?)
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.