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

Ryan McKinley commented on LUCENE-4167:
---------------------------------------

This is essentially a java API vs 'query string' question.  As is we 
essentially pass the query string all the way to the SpatialStrategy before it 
checks the operation; Chris proposes that the operation should be parsed 
*before* it gets to the strategy and have real java functions for each 
operation.

I support:
 * removing the make* functions from SpatialStrategy
 * for each possible strategy, we would create an interface like:

{code:java}
interface IntersectsSpatialQueryBuilder {
  public Query makeIntersectsQuery(SpatialArgs args);
  public Filter makeIntersectsFilter(SpatialArgs args);
}

interface IsWithinSpatialQueryBuilder {
  public Query makeIsWithinQuery(SpatialArgs args);
  public Filter makeIsWithinFilter(SpatialArgs args);
}
{code}

and then concrete SpatialStrategy implementations would implement everything 
they can do.  This may be just Intersects, or it may be a list of 10 things it 
can do.


The advantage to this approach would be:
 * clear java API and good place in javadocs to give the inevitable caveats for 
the operation implementation details
 * testing can check for instances of 'IsWithinSpatialQueryBuilder' 

The end user query string can still look like "INTERSECTS( xxxx )" but this 
would let us take that parsing out of the indexing class.

- - - -

I'm going to go ahead and push the BBox strategy into trunk because it is a 
strategy with a bunch of operations, and i want to make sure general operations 
remain a top level concept.


                
> Remove the use of SpatialOperation
> ----------------------------------
>
>                 Key: LUCENE-4167
>                 URL: https://issues.apache.org/jira/browse/LUCENE-4167
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: modules/spatial
>            Reporter: Chris Male
>         Attachments: LUCENE-4167.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