lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karl Wright (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-6699) Integrate lat/lon BKD and spatial3d
Date Wed, 19 Aug 2015 22:25:45 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14703847#comment-14703847
] 

Karl Wright commented on LUCENE-6699:
-------------------------------------

So, there are two problems.  One I just fixed, which was that pointOnSurface() was being too
strict about accuracy.  But:

{code}
    p1 = new GeoPoint(PlanetModel.WGS84, 0.006224927111830945, 0.005597367237251763);
    p2 = new GeoPoint(1.0010836083810235, 0.005603490759433942, 0.006231850560862502);
    assertTrue(PlanetModel.WGS84.pointOnSurface(p1));
    assertTrue(PlanetModel.WGS84.pointOnSurface(p2)); // this fails
{code}

... so the packing accuracy is not high enough to guarantee that an XYZSolid constructed from
bounds on your shape when applied to an unpacked point will be guaranteed to contain it. 
That's problem 1, and it argues for adding some fudge factor to the bounds to account for
the lack of full accuracy in the points.  More about that later.

Problem 2 is that even p1 above is not within the XYZSolid object computed from the bounds;
in fact it's pretty far out (1e-7 or more).  I have to drill further into why that is; it's
likely related to the WGS84 model, but I don't know how yet.  Once again, 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, 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message