[
https://issues.apache.org/jira/browse/LUCENE-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Male updated LUCENE-2152:
-------------------------------
Attachment: LUCENE-2152-alt.patch
Attaching a new patch based on the above discussion.
This patch introduces the interface DocumentDistanceSource, which provides a
single place to retrieve the distances for documents. It uses the new
PointDecoder interface (a simplified version of the LocationDataSet in the
previous patches) and the GeoDistanceCalculators to determine the distance for
a document.
It comes with 2 implementations, SimpleDocumentDistanceSource which does the
calculations always and does not cache, and MapCachingDocumentDistanceSource,
which does some simple map caching of distances.
By using a combination of these impls, its possible for the user to choose
whether they want the calculated distances to be stored or not. It also moves
the storage out from the Filter, returning the filter to a more stateless impl.
> Abstract Spatial distance filtering process and supported field formats
> -----------------------------------------------------------------------
>
> Key: LUCENE-2152
> URL: https://issues.apache.org/jira/browse/LUCENE-2152
> Project: Lucene - Java
> Issue Type: Improvement
> Components: contrib/spatial
> Affects Versions: 3.1
> Reporter: Chris Male
> Attachments: LUCENE-2152-alt.patch, LUCENE-2152.patch,
> LUCENE-2152.patch, LUCENE-2152.patch
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
