[
https://issues.apache.org/jira/browse/LUCENE-6196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14291776#comment-14291776
]
Karl Wright commented on LUCENE-6196:
-------------------------------------
bq. As a side, David's using the bounding box to determine detailLevel for
speeding up traversal of the RPT. As an FYI, distance might be a little
misleading in that logic as its in units of decimal degrees.
The problem with most arbitrary shapes and "bounding boxes" is twofold:
(1) Bounding boxes, if you actually look at the earth, represent bounds on the
top and bottom that are *not* great circles. So it is very possible to have a
shape that is within a bounding box, according to that box's four corners, but
which curves outside of the box on the top or bottom. Therefore, computing the
actual bounds of a shape is fairly expensive, compared with everything else we
do in geo3d. I'll try to work out the planar math to find out exactly *how*
expensive.
(2) The stated reason to use the bounding boxes is to determine resolution.
This is fine for regular shapes like circles and rectangles, but it is very
wasteful for shapes that are long and thin or irregular.
For this reason, I'd much prefer that a different QuadTree getCells() variant
be introduced, which (as I stated) has a cell count bound, and does a
breadth-first descent. If that's not possible, then one alternative is to
create a new interface in the geo3d package, which computes the lat/lon bounds
for a shape -- but then maybe not all shapes would implement it. That would
imply two distinct spatial4j implementations as well -- one for the kind of
shape that does bounding boxes, one for the kind that doesn't. Stay tuned.
> Include geo3d package, along with Lucene integration to make it useful
> ----------------------------------------------------------------------
>
> Key: LUCENE-6196
> URL: https://issues.apache.org/jira/browse/LUCENE-6196
> Project: Lucene - Core
> Issue Type: New Feature
> Components: modules/spatial
> Reporter: Karl Wright
> Assignee: David Smiley
> Attachments: ShapeImpl.java, geo3d.zip
>
>
> I would like to explore contributing a geo3d package to Lucene. This can be
> used in conjunction with Lucene search, both for generating geohashes (via
> spatial4j) for complex geographic shapes, as well as limiting results
> resulting from those queries to those results within the exact shape in
> highly performant ways.
> The package uses 3d planar geometry to do its magic, which basically limits
> computation necessary to determine membership (once a shape has been
> initialized, of course) to only multiplications and additions, which makes it
> feasible to construct a performant BoostSource-based filter for geographic
> shapes. The math is somewhat more involved when generating geohashes, but is
> still more than fast enough to do a good job.
--
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
