[
https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14703980#comment-14703980
]
Karl Wright commented on LUCENE-6699:
-------------------------------------
In hopes of clarifying my own thinking, I'm going to lay down what the problem
is.
For the Z bound, pretend that you are looking from the north (or south) pole
onto the earth. There's a plane whose intersection with the earth you are
trying to compute the Z bounds for. From the pole, the earth, no matter how
oblate, is a circle in cross-section. The plane intersects part of that
circle. And here's the important point: if you construct another plane that is
perpendicular to the original plane, which also includes the Z axis, that plane
must pass directly through the points that have the greatest Z extent for the
intersection of the original plane and the earth. Got that? ;-)
Anyway, for the X and Y bounds, I basically just copied that code and instead
pretended I was looking up the X axis and up the Y axis, instead of the Z axis.
But if you have an oblate earth, then the cross section from either the X or
the Y axis is not a circle, but rather an ellipse. So a plane that is
perpendicular to the original plane passing through (say) the X axis will NOT
go through the points that have the greatest X extent for the intersection of
the original plane and the earth. The plane we want to use instead is parallel
to that one, but offset by some amount, which I don't yet know how to compute.
And that, in a nutshell, is the problem.
> 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, 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
