[
https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14646934#comment-14646934
]
Karl Wright commented on LUCENE-6699:
-------------------------------------
bq. Right, but, that approach seems wasteful? I mean it should work correctly,
but as you said some cells will span strange parts of the surface. It should
work fine but seems inefficient ... Like, if there is a way instead to make
smaller and smaller surface shapes in the BKD tree that would be best? I.e. fix
BKD to operate entirely on the surface ...
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 am unsure whether the additional cost of representing records with, say,
lat/lon, and doing the conversion to (x,y,z) at search time for every records
encountered would be more or less expensive than having a somewhat wasteful
representation for the tree itself. I expect the conversion for every record
would turn out to be more expensive, but maybe this is something we'd just have
to try. The obvious alternative would be to store just lat/lon, exactly like
is done for Nicholas's code, and use the same BKD tree. The only difference
would be: (a) you'd need to construct a GeoBBox, using GeoBBoxFactory,
representing your area, and then use getRelationship() to determine
intersection, contains, within, or disjoint for the shape, and (b) you'd have
to create a GeoPoint at search time for every record encountered.
> 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: [email protected]
For additional commands, e-mail: [email protected]
