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