[
https://issues.apache.org/jira/browse/LUCENE-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795282#action_12795282
]
Simon Willnauer commented on LUCENE-2152:
-----------------------------------------
Chris, indeed this is a tricky one. One problem with arises related to the map
used for distance caching is when you want to use spatial with a filter and
sort in contrib/remote. At least in the current code (not your patch - haven't
looked at it yet though) the sort instance is obtained from the filter and
depends on the map instance filled by the filter. After serialization the
instance disappears and sort doesn't work anymore on the remote side. if we
could decouple the distance storage from the filter implementation we could
also come up with a solution for the sorting problem like providing a
remoteCollector that has any key value lookup function (internally) that can be
used by the sort function to lookup the calculated values.
I personally would go one step further and introduce an exchangeable distance
calculation function in the first step and a collector in the second. It is
even possible to introduce a delegation approach like the following example:
{code}
DistanceFunction func = new MapCachingDistFunc(new DefaultDistanceFunc(new
CustomFieldDecoder());
for docId in docs:
if func(docid, reader, point) <= dist:
bitSet.set(docid)
{code}
That way we could completely separate the problem into a function interface /
abstract class and can provide several implementations. It would also be
possible to solve our problem with sorting where we can pass a special
RemoteDistanceFunction to both the sort and filter impl. I don't know how it
would look like in the impl though.
Maybe we can even use this function interface in the customscorequery as well.
Just some random ideas....
> 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
