lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-4388) ShapeMatcher and ShapeValues
Date Mon, 17 Sep 2012 04:25:10 GMT

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


Mime
View raw message