[ 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: kwri...@metacarta.com): 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org