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

David Smiley commented on LUCENE-6450:
--------------------------------------

bq. As a side note, I'm finishing up a patch that uses precision_step for 
indexing the longs at variable resolution to take advantage of the postings 
list and not visit every term. The index will be slightly bigger but it should 
provide the foundation for faster search on large polygons and bounding boxes.

If I'm not mistaken, the term auto-prefixing that Mike worked on means we need 
not do that here, especially just for point data; no?

> Add simple encoded GeoPointField type to core
> ---------------------------------------------
>
>                 Key: LUCENE-6450
>                 URL: https://issues.apache.org/jira/browse/LUCENE-6450
>             Project: Lucene - Core
>          Issue Type: New Feature
>    Affects Versions: Trunk, 5.x
>            Reporter: Nicholas Knize
>            Priority: Minor
>         Attachments: LUCENE-6450-5x.patch, LUCENE-6450-TRUNK.patch, 
> LUCENE-6450.patch, LUCENE-6450.patch, LUCENE-6450.patch, LUCENE-6450.patch
>
>
> At the moment all spatial capabilities, including basic point based indexing 
> and querying, require the lucene-spatial module. The spatial module, designed 
> to handle all things geo, requires dependency overhead (s4j, jts) to provide 
> spatial rigor for even the most simplistic spatial search use-cases (e.g., 
> lat/lon bounding box, point in poly, distance search). This feature trims the 
> overhead by adding a new GeoPointField type to core along with 
> GeoBoundingBoxQuery and GeoPolygonQuery classes to the .search package. This 
> field is intended as a straightforward lightweight type for the most basic 
> geo point use-cases without the overhead. 
> The field uses simple bit twiddling operations (currently morton hashing) to 
> encode lat/lon into a single long term.  The queries leverage simple 
> multi-phase filtering that starts by leveraging NumericRangeQuery to reduce 
> candidate terms deferring the more expensive mathematics to the smaller 
> candidate sets.



--
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