[
https://issues.apache.org/jira/browse/LUCENE-4167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13415180#comment-13415180
]
Chris Male commented on LUCENE-4167:
------------------------------------
bq. Why not just a static method on Strategy? I'm not sure there is much need
for a utility class yet.
My problem with this and with having the stored-field stuff as static methods
too, is that having them on Strategy is that it seems that they are the
only/preferred/recommended way to do something and I don't feel that's the
case. Instead they are methods which we think do a good job in a certain
selection of use cases, possibly even the majority of use cases. I don't want
users to get the wrong idea.
bq. 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()
Yeah this is difficult but I like the idea of makeCustomValueSource. I don't
know much about BBoxStrategy but as long as it is possible to calculate the
distance between the centre of two BBoxes, then we should be fine with
makeDistanceValueSource, right? We can then document makeCustomValueSource as
being a generic method which Strategys may define custom behavior for (we can
perhaps have it default to just calling makeDistanceValueSource). If we get to
a situation where we have another Strategy-wide ValueSource idea, we can then
spin that off into another makeXXXValueSource method.
bq. 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.
We can have the DistanceCalculator or whatever is used to calculate the
distance, return the inverted distance. Certainly wrapping a ValueSource in
_another_ ValueSource just to invert the distance would be inefficient.
bq. Okay I guess. How about SpatialQueryCommand or SpatialArgsCommand?
I like SpatialQueryCommand.
> 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: [email protected]
For additional commands, e-mail: [email protected]
