[
https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14701038#comment-14701038
]
Karl Wright commented on LUCENE-6699:
-------------------------------------
[~mikemccand]: I take part of this back.
The Bkd query code looks in part like this:
{code}
case GeoArea.OVERLAPS:
// They do overlap but neither
contains the other:
//System.out.println("
crosses1");
return
BKD3DTreeReader.Relation.CROSSES;
case GeoArea.WITHIN:
// Cell fully contains the shape:
//System.out.println("
crosses2");
return
BKD3DTreeReader.Relation.CROSSES;
{code}
So, you are already treating WITHIN and OVERLAPS the same.
As for the case where, instead of CONTAINS, an OVERLAPS result may occur, I
believe that will simply mean that the algorithm needs to work harder than it
strictly should, in that case. Please tell me if I am wrong! (FWIW, there
aren't any current examples of this behavior that I know of, other than to use
GeoCompositeShape to glue together other shapes.)
So I guess what I'm saying is that we *should* be able to get bkd working
without changing geo3d's code further, unless there are other bugs.
FWIW, this is why the problem hasn't been noted until now; the spatial4j
definitions are loose enough to allow the current degree of behavior. Given
the difficulty of changing that behavior, I may simply change the comments, if
we can get bkd working.
> Integrate lat/lon BKD and spatial3d
> -----------------------------------
>
> Key: LUCENE-6699
> URL: https://issues.apache.org/jira/browse/LUCENE-6699
> Project: Lucene - Core
> Issue Type: New Feature
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch,
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch,
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch,
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch,
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch
>
>
> I'm opening this for discussion, because I'm not yet sure how to do
> this integration, because of my ignorance about spatial in general and
> spatial3d in particular :)
> Our BKD tree impl is very fast at doing lat/lon shape intersection
> (bbox, polygon, soon distance: LUCENE-6698) against previously indexed
> points.
> I think to integrate with spatial3d, we would first need to record
> lat/lon/z into doc values. Somewhere I saw discussion about how we
> could stuff all 3 into a single long value with acceptable precision
> loss? Or, we could use BinaryDocValues? We need all 3 dims available
> to do the fast per-hit query time filtering.
> But, second: what do we index into the BKD tree? Can we "just" index
> earth surface lat/lon, and then at query time is spatial3d able to
> give me an enclosing "surface lat/lon" bbox for a 3d shape? Or
> ... must we index all 3 dimensions into the BKD tree (seems like this
> could be somewhat wasteful)?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
