[
https://issues.apache.org/jira/browse/LUCENE-4167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13402286#comment-13402286
]
Chris Male commented on LUCENE-4167:
------------------------------------
{quote}
Intersects – equivalent to IsWithin when index data is points
BBoxWIntersects – again, equivalent to BBoxIsWithin when the indexed data is
points.
{quote}
I don't see the need to differentiate BBoxIntersects and Intersects. If the
user wants to find those Documents related to the bounding box of a Shape, then
they can call shape.getBoundingBox() and pass that into the Strategy. The
Strategys shouldn't have to worry about the Shape (although TwoDoubles does but
that needs to be re-thought separately). The Strategys should just take the
Shape given and roll with it. Is that what you're suggesting?
{quote}
My concern with your suggestion to remove SpatialOperation is that I do think
it will return. I know I want to work on an IsWithin when indexed data is
shapes with area. And it is serving the purpose of SpatialArgsParser parsing
out the operation you want to do, which I don't think should go away (i.e. the
query string shouldn't assume an intersect, it should include "Intersects(...)"
Perhaps the unsupported operations could be commented out?
{quote}
I can see the need for different behaviour for different Shape relationships
to. But I think we should perhaps do that using method specialization. We
already have the PrefixTreeStrategy abstraction, so you could write a
WithinRecursivePrefixTreeStrategy which specialized makeQuery differently.
That way it is clear to the user what the Strategy does, we won't need the
runtime checks and we won't have Strategys like TwoDoubles which has methods
for each of the different behaviours in the same class.
So I think we can remove the need for SpatialOperation now and support the idea
differently in the future.
(As a side note, this actually makes me think we should decouple the indexing
code of Strategys from the querying code).
{quote}
Separately, I think com.spatial4j.core.query.* belongs in Lucene spatial. It's
not used by any of the rest of Spatial4j, yet it's tightly related to the
concept of querying which is Lucene spatial's business, and is not the business
of Spatial4j.
{quote}
+1. As a short term solution I think we just replicate the code that we need
in Lucene now and then drop it from Spatial4J in the next release.
> 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
>
> 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
