[
https://issues.apache.org/jira/browse/LUCENE-5692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated LUCENE-5692:
---------------------------------
Attachment:
LUCENE-5692_Deprecate_DisjointSpatialFilter__RPT_stops_using_it.patch
> Deprecate spatial DisjointSpatialFilter
> ---------------------------------------
>
> Key: LUCENE-5692
> URL: https://issues.apache.org/jira/browse/LUCENE-5692
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial
> Affects Versions: 5.0
> Reporter: David Smiley
> Attachments:
> LUCENE-5692_Deprecate_DisjointSpatialFilter__RPT_stops_using_it.patch
>
>
> The spatial predicate "IsDisjointTo" is almost the same as the inverse of
> "Intersects", except that it shouldn't match documents without spatial data.
> In another sense it's as if the query shape were inverted.
> DisjointSpatialFilter is a utility filter that works (or worked, rather) by
> using the FieldCache to see which documents have spatial data
> (getDocsWithField()). Calculating that was probably very slow but it was at
> least cacheable. Since LUCENE-5666 (v5/trunk only), Rob replaced this to use
> DocValues. However for some SpatialStrategies (PrefixTree based) it wouldn't
> make any sense to use DocValues *just* so that at search time you could call
> getDocsWithField() when there's no other need for the un-inversion (e.g. no
> need to lookup terms by document).
> Perhaps an immediate fix is simply to revert the change made to
> DisjointSpatialFilter so that it uses the FieldCache again, if that works
> (though it's not public?). But stepping back a bit, this
> DisjointSpatialFilter is really something unfortunate that doesn't work as
> well as it could because it's not at the level of Solr or ES -- that is,
> there's no access to a filter-cache. So I propose I simply remove it, and if
> a user wants to do this for real, they should index a boolean field marking
> wether there's spatial data and then combine that with a NOT and Intersects,
> in a straight-forward way.
> Alternatively, some sort of inverting query shape could be developed,
> although it wouldn't work with the SpatialPrefixTree technique because there
> is no edge distinction -- the edge matches normally and notwithstanding
> changes to RPT algorithms it would also match the edge of an inverted shape.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
