[
https://issues.apache.org/jira/browse/LUCENE-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795293#action_12795293
]
Chris Male commented on LUCENE-2152:
------------------------------------
I agree that we need to decouple the sort from the Filter. My current patches
don't do that well enough unfortunately so I want to address that.
I like what you are suggesting, but I think there are a couple of things to
consider. The storage of the distances is not just for sorting sake, as you
say its also needed in the CustomScoreQuery for boosting, and also for
presentation of the results. Given that, I'm still sort of favouring
separating the distance calculation function from the storage mechanism.
If we added a DistanceCollector abstraction, then we could create a Remote impl
for the Collector, and we could create a distance function (which I refer to as
GeoDistanceCalculator in one of my other patches) which uses an existing
DistanceCollector as a cache.
We could also make a NoOpDistanceCollector for those who don't want to actually
store anything, and a RangeDistanceCollector for collecting values in ranges
(which could be a space saving optimization, and could also help with distance
range faceting).
> 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.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
