[
https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14645839#comment-14645839
]
Karl Wright commented on LUCENE-6699:
-------------------------------------
bq. So for this to work, I need to be able to efficiently ask the query shape
whether it separately overlaps with a range in each of the 3 dimensions. E.g.
"do you intersect 0.3 <= x < 0.7", and same for y and z. I assume this is
fast/simple to do with the spatial3d APIs?
Hmm. There's a "bounds()" method which obtains the lat/lon bounds of a shape.
But for 3d we'd not be able to use that. However:
bq. Hmm, one source of efficiency for the BKD tree is it can recognize at
search time when a given indexed cell is fully contained by the query shape,
and then it doesn't need to test every point against the shape (it just blindly
collects all docIDs in that cell). But in the 3D case, I think that
optimization would never apply?
Well, IF we presume that the records all lie on the surface of the world, then
you can ask the question, "do these x, y, z bounds, when intersected with the
world surface, all lie within the shape, or overlap the shape?" I'll have to
think about how efficient that can be made to work, but you ARE after all
describing a second surface shape by your x-y-z ranges, so in theory this
should be doable. In particular, the GeoBBox construct allows you to find the
relationship between a specific kind surface shape (currently only lat/lon
rectangles and their degenerate 3d equivalents) and any other GeoShape. We
could try to introduce x-y-z rectangles as shapes; they'd be completely
describable by planes, so really all the same logic would apply. I would need
to create a new GeoAreaFactory method, and a family of x-y-z bounding shapes,
e.g. GeoXYZArea, and it should all work.
To be sure, have a look at the functionality that GeoArea gives you. If that
looks like what you need, and you can convince yourself that it would be
reasonably efficient as far as BKD is concerned, then I'll go ahead and create
a patch that does what you need.
> 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
>
> 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]
