[ https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14699543#comment-14699543 ]
Michael McCandless commented on LUCENE-6699: -------------------------------------------- Thanks [~daddywri], I'll commit shortly. I ran the same "225 bboxes around London on the 61M OpenStreetMap lat/lon points" perf tests with the current branch, plus the 3 other existing options: * Geo3D + BKD (PointInGeo3DShapeQuery, this issue/branch): index is 936 MB, took 423 + 96 (close, waiting for merges) sec to build. 7.01 sec to run 225 queries, total hits 221,118,860. * 2D BKD (BKDPointInBBoxQuery): index is 704 MB, took 163 + 97 sec to build. 2.32 sec to run 225 queries, total hits 221,118,844. It's OK (I think) that number of hits is a wee bit smaller than geo3d because the geo3d bbox when projected to 2D space is a bit bowed out (I think?) and can therefore include a few more points. * Postings + DV (GeoPointInBBoxQuery): index is 3.4 GB, took 349 + 11 sec to build. 3.60 sec to run 225 queries, total 221,120,393 hits (hmm: I'm not sure why this is not identical to 2D BKD?) * PackedQuadPrefixTree (RecursivePrefixTreeStrategy), with maxLevels=25: 990 + 11 seconds to build, 7.7 GB, 3.82 seconds to run 225 queries, total 221,123,206 hits. All these benchmarks are in luceneutil. > 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 > > > 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