[
https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700857#comment-14700857
]
Karl Wright commented on LUCENE-6699:
-------------------------------------
[~mikemccand]: In order to reliably distinguish between the case of an edge
just touching a shape and actually crossing into it, which is what I need here,
I need to count the number of crossings per edge. This is fundamentally easy
to do, for a single edge. However, there are quite a number of downstream
complications, because shapes include a number of edges, not just one, and we
have to put it all together. For example, if one shape happens to go through
an endpoint where two edges intersect, it should really count as one
intersection, not two. Making matters more complicated, composite shapes may
consist of simple shapes that overlap and thus the algorithm will be even more
fraught and need correspondingly more thought.
The upshot of this is that the infrastructure I currently have in place needs a
substantial upgrade in order to be able to reliably distinguish WITHIN from
OVERLAP in the corner case where the shape just abuts the solid. This will
take me a couple of days, most likely. Unfortunately, there's also a corner
case with composite shapes where OVERLAP may be returned instead of CONTAINS,
so this clearly *has* to be fixed for BKD to work correctly for all shapes. So
I apologize for the delay.
Stay tuned.
> 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
>
>
> 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]
