[
https://issues.apache.org/jira/browse/LUCENE-4388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13456751#comment-13456751
]
David Smiley commented on LUCENE-4388:
--------------------------------------
bq. 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.
The only solution there is documentation -- e.g. javadocs. Some features
basically require these memory structures; it's hard to avoid them.
{quote}
bq. And a strategy could support any query shape simply by implementing
makeShapeValues().
I don't understand this. Can you elaborate?
{quote}
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.
RE MultiShape:
bq. or whether it should change per Document and then force the consumer to
check
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.
> 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]
