[
https://issues.apache.org/jira/browse/LUCENE-6196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14289240#comment-14289240
]
Karl Wright edited comment on LUCENE-6196 at 1/23/15 1:34 PM:
--------------------------------------------------------------
bq. As of last summer the spatial module has had SerializedDVStrategy to
generalize the later check. It would further be awesome to have a derivative of
RPT that is able to detect which cells are within the query geometry and so
don't double-check those documents, and likewise for leaf cells containing the
query geometry need not be double-checked either. It's a wish-list feature
LUCENE-5579. Ideally the leaf cells would be differentiated as
edge-approximated or within but it's not essential.
With geo3d, the cost of determining membership in the shape is *so* low that I
think you do better by just doing it, rather than trying to avoid doing it. In
a way that was the whole point behind the development of geo3d.
For example, have a look at the GeoCircle code. To determine whether a point
is within the circle, the evaluation that is needed is only the following:
{code}
@Override
public boolean isWithin(GeoPoint point)
{
// Fastest way of determining membership
return circlePlane.onCorrectSide(point);
}
{code}
... which involves three multiplications, three additions, and a comparison.
That's cheap by any standard. The most expensive thing here is constructing
the GeoPoint from (x,y,z) coordinates, because it does an allocation. Further
optimization of the library can avoid even that by having an alternate form of
the method: isWithin(double x, double y, double z) .
was (Author: [email protected]):
bq. As of last summer the spatial module has had SerializedDVStrategy to
generalize the later check. It would further be awesome to have a derivative of
RPT that is able to detect which cells are within the query geometry and so
don't double-check those documents, and likewise for leaf cells containing the
query geometry need not be double-checked either. It's a wish-list feature
LUCENE-5579. Ideally the leaf cells would be differentiated as
edge-approximated or within but it's not essential.
With geo3d, the cost of determining membership in the shape is *so* low that I
think you do better by just doing it, rather than trying to avoid doing it. In
a way that was the whole point behind the development of geo3d.
> 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: [email protected]
For additional commands, e-mail: [email protected]
