[
https://issues.apache.org/jira/browse/LUCENE-4388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13456757#comment-13456757
]
Chris Male commented on LUCENE-4388:
------------------------------------
bq. The reasoning is similar to how a standard DistanceValueSource could then
exist. For a makeFilter / makeQuery, there could be a standard ShapeFilter that
consults makeShapeValues to intersect with the query shape. Of course, it
should be preceded by a bbox filter or something similar.
That's going to be so slow. Iterating over every Shape of every Document to
see if intersects? That harks back to WildcardQuery performance of old. Even
with a BBox, you could have 100,000 points within a city. I don't think we
should ever support this. If a user wants to create it themselves then fine,
but we should be striving for performance.
bq. I'm not sure what you mean. But a problem with the other approach (forcing
MultiShape for createFields) is that it would make Solr support difficult,
perhaps requiring a UpdateRequestProcessor to join separate field values into
one. But even putting that aside, I don't think use of a MultiShape needs to be
forced, but it should be supported by the Strategy if it declares that it
handles multi-valued shapes.
Given this issue is about ShapeValues, I'm talking about retrieving Shapes
through ShapeValues, not about indexing. What I was saying is given the
ShapeValues interface:
{code}
S shape(int docId, IndexReader reader);
{code}
We need to decide what S is going to be. If S is always Shape then the
consumer would need to check if the actual value returned was a MultiShape or
not, in order to retrieve the multiple Shapes. If S was always MultiShape,
then the ShapeValues impl would need to return a MultiShape even when there
might only be one Shape associated with the given docId.
This isn't a blocking problem, I was merely suggesting that we need to think
through the use cases we want to support and how MultiShape fits in.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
