[
https://issues.apache.org/jira/browse/LUCENE-4388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13456561#comment-13456561
]
Chris Male commented on LUCENE-4388:
------------------------------------
Interesting idea. I like the idea of Strategys exposing ShapeValues and then
having a standard DistanceValueSource which accepted a Shape, ShapeValues and a
DistanceCalculator. I like that it would also make it easier to retrieve the
Shape if it was needed in other places.
I am little worried that this could encourage consumers, whether they be other
Strategy impls or something else, to use un-inverted index structures instead
of inverted and subsequently suffer in performance and in memory consumption.
bq. And a strategy could support any query shape simply by implementing
makeShapeValues().
I don't understand this. Can you elaborate?
bq. I've been thinking about how the API handles strategies supporting indexing
multiple shapes and I wonder if that could happen simply via a new
MultiShape<Shape>
One of the challenges with this API is that whether multiple values are
supported is a per Strategy decision, yet whether there are multiple values is
a per Document decision. Document 1 might have only a single Shape, Document 2
might have multiple Shapes. I just wonder whether we want to force Strategys
which support multiple values to always use MultiShape, or whether it should
change per Document and then force the consumer to check.
> ShapeMatcher and ShapeValues
> ----------------------------
>
> Key: LUCENE-4388
> URL: https://issues.apache.org/jira/browse/LUCENE-4388
> Project: Lucene - Core
> Issue Type: New Feature
> Components: modules/spatial
> Reporter: David Smiley
> Attachments: LUCENE-4388_ShapeValues_and_ShapeMatcher.patch
>
>
> This patch provides two key interfaces: ShapeMatcher and ShapeValues. The
> ShapeMatcher concept is borrowed from [~ryantxu]'s JtsGeoStrategy which has a
> similar GeometryTester. ShapeValues is basically a
> ValueSource/FunctionValues for shapes. This isn't working; I didn't modify
> any existing classes.
> I haven't completely thought this through but a SpatialStrategy might expose
> a makeShapeValues(IndexReader) and/or makeCenterShapeValues(IndexReader) (the
> latter is the center points of indexed data). A generic Distance ValueSource
> could easily be implemented in terms of makeCenterShapeValues(). And a
> strategy could support any query shape simply by implementing
> makeShapeValues().
> I've been thinking about how the API handles strategies supporting indexing
> multiple shapes and I wonder if that could happen simply via a new
> MultiShape<Shape>.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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]
