Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Won't Fix
-
3.1
-
None
-
None
-
New
Description
Currently the second stage of the filtering process in the spatial contrib involves calculating the exact distance for the remaining documents, and filtering out those that fall out of the search radius. Currently this is done through the 2 impls of DistanceFilter, LatLngDistanceFilter and GeoHashDistanceFilter. The main difference between these 2 impls is the format of data they support, the former supporting lat/lngs being stored in 2 distinct fields, while the latter supports geohashed lat/lngs through the GeoHashUtils. This difference should be abstracted out so that the distance filtering process is data format agnostic.
The second issue is that the distance filtering algorithm can be considerably optimized by using multiple-threads. Therefore it makes sense to have an abstraction of DistanceFilter which has different implementations, one being a multi-threaded implementation and the other being a blank implementation that can be used when no distance filtering is to occur.
Attachments
Attachments
Issue Links
- incorporates
-
LUCENE-1732 Multi-threaded Spatial Search
- Closed
- is depended upon by
-
LUCENE-2395 Add a scoring DistanceQuery that does not need caches and separate filters
- Resolved
-
LUCENE-2139 Cleanup and Improvement of Spatial Contrib
- Closed
- is part of
-
LUCENE-2350 Refactor/Cleanup Lucene Spatial
- Resolved