[
https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14646121#comment-14646121
]
Karl Wright commented on LUCENE-6699:
-------------------------------------
bq. Essentially the BKD tree needs a way to recursively chop up the earth
surface into smaller and smaller curved-rectangle-like (I think?) shapes on the
earth's surface, both at indexing time and at search time.
With x/y/z splitting, actually you're not quite doing that. Instead, you are
chopping up the space that the entire world lives in (not just its surface).
One these 3d rectangles may or may not actually intersect the surface (which is
where all the geo shapes actually lie). If it does intersect, it might
intersect on only one side of the world, or it might intersect on two sides of
the world. A long, thin 3d rectangle could well encompass a little bit of
territory in (say) the UK as well as Alaska, for instance. But as you describe
the algorithm, I'm not sure that this is important at all to know.
bq. At search time, for a given cell, it needs to "relate" to the query shape
to know if the query shape full contains the cell, does not overlap with the
cell, or partially overlaps.
The GeoArea interface gives you all of that, which is why I wanted to implement
objects that *aren't* limited to the surface but *do* implement GeoArea.
bq. But I don't understand the "degenerate in X/Y" Area objects... it seems
like GeoArea would be used for the lat/lon "approximation" (outer bounding
box?) to a GeoShape? Seems like it's better if we can do all functions using
proper earth-surface shapes?
GeoArea objects are not constrained to be surface objects. Right now the only
implementers of GeoArea are bounding boxes, bounded in latitude and longitude,
but that's merely due to lack of need for anything else. The relationship
types GeoArea objects can determine are against general GeoShape objects (which
*are* surface objects), so the semantics are perfect for what you are trying to
do. You can determine whether a lat/lon rectangle overlaps, contains, is
within, or doesn't intersect at all with, any arbitrary spatial3d surface shape.
But let's be clear: for BKD in the x,y,z space, GeoArea objects bounding in
lat/lon are useless. So we need to invent GeoArea objects that represent 3d
rectangles. If we try to talk about a general XYZ-bounded area, then there
will be up to two bounds for X (min and max), two bounds for Y (min and max),
and two bounds for Z (min and max). The degenerate cases come into play when
min-X == max-X, or min-Y == max-Y, etc, or when there *is* no min-X bound but
just a max-X one, for instance. This can be conditional logic but the whole
thing is faster and more efficient if there's an object for each funky case.
Hope this helps.
> 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]
