[
https://issues.apache.org/jira/browse/LUCENE-4167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13415154#comment-13415154
]
David Smiley commented on LUCENE-4167:
--------------------------------------
bq. We can maybe move the makeQuery as you defined to a utility class (maybe
with the stored-field stuff) which focuses on providing an easy API for the 90%
of use cases.
Why not just a static method on Strategy? I'm not sure there is much need for
a utility class yet.
bq. Can we rename makeValueSource to makeDistanceValueSource so that it is
clearer what it does? I'm not really sure how best to handle ValueSources
calculating scores from other factors just yet so lets just put that on the
backburner.
+1 my first reaction is that I love it, but I have a few questions:
* What should BBoxStrategy do? It's very existence is largely due to its
overlap percentage based relevancy -- pretty cool. Would it have a
makeDistanceValueSource() that does something different? -- perhaps one that
gets the center of the indexed shape and uses that? It could work via new
BBoxSimilarityValueSource(CenterDistanceSimilarity(...)) (hypothetical
implementation to be developed). And the current one might be
makeCustomValueSource with the ability for the caller to pass in
AreaSimilarity()
* Would a makeDistanceValueSource() make it inefficient to support an inverted
distance? This may be a stupid question but we ultimately want this as the
default for a query: LUCENE-4208 -- for example at the Solr layer.
bq. So how about we rename SpatialArgs to SpatialCommand?
Okay I guess. How about SpatialQueryCommand or SpatialArgsCommand?
> 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,
> 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
