[
https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14647778#comment-14647778
]
Michael McCandless commented on LUCENE-6699:
--------------------------------------------
I can't follow all the spatial-heavy discussion here, but:
bq. Since BKD splits a sorted space, and it can exploit file system cache?
BKD tree's "tree" (the internal nodes) is already forced into heap, at least in
the current impl. So walking that tree should always be fast, and then there's
only seeking once we hit the leaf nodes. But that seeking should be sequential
walk through the file...
bq. If the decision is made to use (x,y,z) encoding rather than (lat,lon),
bq. So, if you turn the BKD descent into something other than (x,y,z), it would
imply that you store points for records in something other than (x,y,z) too, no?
I think the encoding for each point's value can be different from what the BKD
tree uses?
I suspect the points shoudl use (x,y,z) encoding when stored in doc-values per
document, because when we need to filter hits for the BKD leaf cells
overlapping the shape's boundary, we want to take advantage of the fast math in
(x,y,z) space that spatial3d gives us?
But then, for the inner-nodes (split values) for the BKD tree, we could use
either (lat,lon) or (x,y,z), whichever gives us fastest shape relation
computations? At each step in the recursion, BKD tree must check a split in
one dimension against the query shape.
> 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
>
>
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
