[ 
https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14647198#comment-14647198
 ] 

Karl Wright commented on LUCENE-6699:
-------------------------------------

bq. Just to note again, the conversion from lat/lon to ECEF XYZ is a 
non-iterative conversion (2 sines, 2 cosines, 1 sqrt).

Right, but you'd be comparing 2 sines, 2 cosines, and 1 sqrt against only the 
cost of unpacking, which for 1 billion records would be a noticeable amount of 
time.

bq. Since BKD splits a sorted space, and it can exploit file system cache? I 
suspect there aren't many random seeks? Seems benchmarking might be relatively 
straightforward?

Many Lucene systems (including ours) store the index in memory, using memory 
mapping, and SSDs would be expected too even when not, so I'd think a 
benchmarking should not overemphasize seeks as being costly.  But Mike is the 
expert as far as that is concerned.


> 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

Reply via email to