[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lucene-dev
Subject:    [jira] Commented: (LUCENE-2152) Abstract Spatial distance filtering
From:       "Chris Male (JIRA)" <jira () apache ! org>
Date:       2009-12-30 12:21:29
Message-ID: 961708441.1262175689400.JavaMail.jira () brutus ! apache ! org
[Download RAW message or body]


    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]