[ 
https://issues.apache.org/jira/browse/LUCENE-6196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14300944#comment-14300944
 ] 

Karl Wright commented on LUCENE-6196:
-------------------------------------

bq: There's one thing I want to confirm with you Karl: so these shares are 
"accurate" to the spherical model (the unit sphere)? That is, if I have say a 
line string, then is each line segment a great-circle path between its start & 
end? If not then can you please explain?

In part this depends on the shape.  For GeoConvexPolygons, the surface paths 
are all great circles.  For GeoCircles, it's a circle not a great circle.  For 
GeoPaths, the boundary of the shape consists of a zone of a specific width on 
either side of a great circle, so the boundary is not (if you think about it) 
actually a great circle.  For GeoBBox shapes (e.g. GeoRectangles), they are 
great circles in longitude, but horizontal slices in latitude.  This matches 
the standard "rectangle" metaphor that quad trees are built on.

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

Reply via email to