[
https://issues.apache.org/jira/browse/LUCENE-6477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14552250#comment-14552250
]
David Smiley commented on LUCENE-6477:
--------------------------------------
bq. Longer term, when/if it graduates, I don't think it should go into
lucene/spatial: I don't like how "heavy" lucene/spatial is, with external libs
bleeding into the public APIs (spatial4j, JTS), too-many-abstractions causing
barriers for new contributions, test case base classes strangely forked from
external libraries and thus failing to print "reproduce with" lines, etc.
bq. I think we need competing/alternative approaches that are much more
lightweight, and focus on the common case (index points, search shapes), like
LUCENE-6450 and this patch... and I think such support really could/should be
in Lucene's core, or "spatial2" or "spatiallight" or something. And then I
think that leaves lucene/spatial supporting the exotic/difficult cases that
require (?) all the abstractions?
In a nutshell, you don't like the code in the spatial module for a variety of
reasons, but nonetheless that doesn't prevent any other code from being there
too that meets your satisfaction.
Separately from the topic of spatial code belonging in the spatial module, I
definitely think it's worth re-looking at the (only) core/base abstraction in
the spatial module -- SpatialStrategy, to come up with a new design that is not
dependent on external libs. p.s. JTS is most definitely not part of the public
API of Lucene spatial -- preventing that was half the reason for Spatial4j's
existence. The other half is about potential re-use for shape/geometry
calculations that otherwise has nothing to do with Lucene.
> Add BKD tree for spatial shape query intersecting indexed points
> ----------------------------------------------------------------
>
> Key: LUCENE-6477
> URL: https://issues.apache.org/jira/browse/LUCENE-6477
> Project: Lucene - Core
> Issue Type: New Feature
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: Trunk, 5.2
>
> Attachments: LUCENE-6477.patch, LUCENE-6477.patch
>
>
> I'd like to explore using dedicated spatial trees for faster shape
> intersection filters than postings-based implementations.
> I implemented the tree data structure from
> https://www.cs.duke.edu/~pankaj/publications/papers/bkd-sstd.pdf
> The idea is simple: it builds a full binary tree, partitioning 2D
> space, alternately on lat and then lon, into smaller and smaller
> rectangles until a leaf has <= N (default 1024) points.
> It cannot index shapes (just points), and can then do fast shape
> intersection queries. Multi-valued fields are supported.
> I only implemented the "point is contained in this bounding box" query
> for now, but I think polygon shape querying should be easy to
> implement using the same approach from LUCENE-6450.
> For indexing, you add BKDPointField (takes lat, lon) to your doc, and
> must set up your Codec use BKDTreeDocValuesFormat for that field.
> This DV format wraps Lucene50DVFormat, but then builds the disk-based
> BKD tree structure on the side. BKDPointInBBoxQuery then requires this
> DVFormat, and casts it to gain access to the tree.
> I quantize each incoming double lat/lon to 32 bits precision (so 64
> bits per point) = ~9 milli-meter lon precision at the equator, I
> think.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
