[ 
https://issues.apache.org/jira/browse/LUCENE-4167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13423072#comment-13423072
 ] 

David Smiley commented on LUCENE-4167:
--------------------------------------

I spent some time working on TwoDoublesStrategy to make it not use makeQuery 
and to simplify it and fix the dateline bug.  Then it a realization hit me: if 
makeQuery() goes away (the default impl gets used) and the input is a circle 
and sorting is desired, the distances will wind up getting calculated twice.  
The first is for the filter, the 2nd is makeDistanceValueSource called via 
default impl of makeQuery().  I still think makeQuery() should go away, albeit 
I have less conviction about that now.

Remember my suggestion of having some sort of object which I proposed be called 
SpatialSearch that is returned from a method on the strategy?  This would have 
a makeFilter() and makeDistanceValueSource() instead of them being directly on 
the strategy.  The SpatialSearch instance is per-search and affords the 
opportunity to cache intermediate results across method calls.  Ryan told me 
about wanting to do this for a specialized use-case he has with JtsStrategy (in 
Spatial4j right now) where he unfortunately resorts to a ThreadLocal 
work-around to share the results.  I can also imagine a sort strategy for 
RecursivePrefixTreeStrategy in which the filter is informed it should calculate 
matching distances in addition to its filtering job, so that they can be 
retrieved later.  Of course the filtering would be slower the more points that 
are covered by the search radius, but it's viable for some use-cases.
                
> Remove the use of SpatialOperation
> ----------------------------------
>
>                 Key: LUCENE-4167
>                 URL: https://issues.apache.org/jira/browse/LUCENE-4167
>             Project: Lucene - Core
>          Issue Type: Bug
>          Components: modules/spatial
>            Reporter: Chris Male
>         Attachments: LUCENE-4167.patch, 
> LUCENE-4167_migrate_com_spatial4j_core_query_to_Lucene_spatial.patch, 
> LUCENE-4167_migrate_com_spatial4j_core_query_to_Lucene_spatial.patch
>
>
> Looking at the code in TwoDoublesStrategy I noticed 
> SpatialOperations.BBoxWithin vs isWithin which confused me.  Looking over the 
> other Strategys I see that really only isWithin and Intersects is supported.  
> Only TwoDoublesStrategy supports IsDisjointTo.  The remainder of 
> SpatialOperations are not supported.
> I don't think we should use SpatialOperation as this stage since it is not 
> clear what Operations are supported by what Strategys, many Operations are 
> not supported, and the code for handling the Operations is usually the same.  
> We can spin off the code for TwoDoublesStrategy's IsDisjointTo support into a 
> different Strategy.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to