[
https://issues.apache.org/jira/browse/LUCENE-6196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14301274#comment-14301274
]
Nicholas Knize commented on LUCENE-6196:
----------------------------------------
bq. Spatial4j is totally wired into a latitude/longitude bounding box
geometry, and most of the methods required by Shape objects have no
implementation in a geo3d world.
David can elaborate, but at the moment that's only a temporary delimitation of
spatial4j, not a limitation. Spatial4J is intended to expand on JTS (but w/ an
ASF license) for geospatial applications, not intended to remain restricted to
a 2D (lat/lon) set of capabilities. That's why integrating this within S4J is
an attractive approach.
bq. The geo3d world has exactly what is needed for lucene searching, and no
more.
It looks to me that any index/search approach based on a space filling curve
would benefit from geo3d. In fact, what you have here can just as easily be
applied to an R/R*-Tree algorithm. Where in the design is it restricted to
lucene?
> 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-tests.zip, 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]
