[
https://issues.apache.org/jira/browse/LUCENE-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated LUCENE-5408:
---------------------------------
Attachment: LUCENE-5408_SerializedDVStrategy.patch
Attached is a working patch with tests. I plan to commit it in 2 days.
I renamed it from GeometryStrategy to *SerializedDVStrategy* which is more
meaningful. If you call makeQuery you get an UnsupportedOperationException,
and if you call makeFilter and then try to grab the iterator, you'll get an
UnsupportedOperationException too. The main way the functionality is exposed
is via a makeShapeValueSource() that returns Shape instances from
FunctionValues.objectVal(doc). From this, I implemented a
DistanceToShapeValueSource (from the center of the shape), and a
ShapePredicateValueSource that's a boolean.
Exposing this via Solr will come in another issue. That's not as trivial as
the other strategies because this particular one needs to be used in a certain
way in Solr -- a PostFilter.
> GeometryStrategy -- match geometries in DocValues
> -------------------------------------------------
>
> Key: LUCENE-5408
> URL: https://issues.apache.org/jira/browse/LUCENE-5408
> Project: Lucene - Core
> Issue Type: New Feature
> Components: modules/spatial
> Reporter: David Smiley
> Assignee: David Smiley
> Fix For: 4.7
>
> Attachments: LUCENE-5408_GeometryStrategy.patch,
> LUCENE-5408_SerializedDVStrategy.patch
>
>
> I've started work on a new SpatialStrategy implementation I'm tentatively
> calling GeometryStrategy. It's similar to the [JtsGeoStrategy in
> Spatial-Solr-Sandbox|https://github.com/ryantxu/spatial-solr-sandbox/tree/master/LSE/src/main/java/org/apache/lucene/spatial/pending/jts]
> but a little different in the details -- certainly faster. Using Spatial4j
> 0.4's BinaryCodec, it'll serialize the shape to bytes (for polygons this in
> internally WKB format) and the strategy will put it in a
> BinaryDocValuesField. In practice the shape is likely a polygon but it
> needn't be. Then I'll implement a Filter that returns a DocIdSetIterator
> that evaluates a given document passed via advance(docid)) to see if the
> query shape matches a shape in DocValues. It's improper usage for it to be
> used in a situation where it will evaluate every document id via nextDoc().
> And in practice the DocValues format chosen should be a disk resident one
> since each value tends to be kind of big.
> This spatial strategy in and of itself has no _index_; it's O(N) where N is
> the number of documents that get passed thru it. So it should be placed last
> in the query/filter tree so that the other queries limit the documents it
> needs to see. At a minimum, another query/filter to use in conjunction is
> another SpatialStrategy like RecursivePrefixTreeStrategy.
> Eventually once the PrefixTree grid encoding has a little bit more metadata,
> it will be possible to further combine the grid & this strategy in such a way
> that many documents won't need to be checked against the serialized geometry.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
