lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Male (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-4388) ShapeMatcher and ShapeValues
Date Sun, 16 Sep 2012 09:20:08 GMT

    [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message