lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Male (JIRA)" <>
Subject [jira] [Commented] (LUCENE-4388) ShapeMatcher and ShapeValues
Date Mon, 17 Sep 2012 04:45:08 GMT


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

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:

S shape(int docId, IndexReader reader);

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:
>             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:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message