[
https://issues.apache.org/jira/browse/LUCENE-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795300#action_12795300
]
Chris Male commented on LUCENE-2152:
------------------------------------
Ha, genius. I hadn't thought about the reuse between searches. That would
make a huge difference in a situation where a user is changing their zoom on a
map.
I'm with you now and agree whole heartedly with what you are suggesting. I
really love the idea of having a single consistent way of retrieving a distance
for a document, whether it be the Filter itself, the Sort, a Query, or some
output mechanism. That would really hide away alot of the logic.
Would you then also put the task of loading/decoding the appropriate lat/lng
info for Documents inside this distance function idea as well? (I think this
was what you were suggesting a couple of posts ago).
> 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
