lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-6699) Integrate lat/lon BKD and spatial3d
Date Fri, 21 Aug 2015 23:48:45 GMT

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

Michael McCandless commented on LUCENE-6699:
--------------------------------------------

OK I extracted some info from the failure (see the attached patch, but it makes tons of output!):

This is the query it's running:

{noformat}
Thread[T2,5,TGRP-TestGeo3DPointField]: TEST: iter=342 shape=GeoCircle: {planetmodel=PlanetModel.WGS84,
center=[lat=-0.006450320645814321, lon=0.004660694205115142], radius=0.00489710732634323(0.28058358162206176)}
  using query: PointInGeo3DShapeQuery: field=point:PlanetModel: PlanetModel.WGS84 Shape: GeoCircle:
{planetmodel=PlanetModel.WGS84, center=[lat=-0.006450320645814321, lon=0.004660694205115142],
radius=0.00489710732634323(0.28058358162206176)}
{noformat}

Then, while BKD is recursing, it hits a point where this cell is
supposedly (incorrectly) fully contained in the query shape:

{noformat}
Thread[T2,5,TGRP-TestGeo3DPointField]: switch to addAll at cell x=1.0010822580620098 to 1.0010945779732867
y=0.007079167343247293 to 0.007541006774427837 z=-0.0021855011220022575 to -0.001896122718181518
{noformat}

But then this docID fails the new assert (is not within the query shape):

{noformat}
T2: FAILED: docID=1123
  accept docID=1123 point: x=1.0010893045436076 y=0.007380935180644008 z=-0.002140671370616495
{noformat}


> 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, 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