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

Uwe Schindler commented on LUCENE-6450:
---------------------------------------

bq. mm: another question about overriding the accept() method for 
NumericRangeTermsEnum: it looks like you extract the full precision lat/lon 
from the incoming term, yet this term could be a shifted term right (lost some 
of its lower bits)? 

I think I figured out: the Geo queries always use precStep=64, so shifted terms 
will never appear. I just have the question (why do this?). The whole sense of 
NumericRangeQuery is to use the lower-precision terms to not visit too many 
terms... Could you, Nicholas, please explain, why we dont want to use the 
prefix terms? I agree it makes it more complicated, but I think the current 
encoding could use it. And the terms are not "wasteful"! :-)

> 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: 5.x
>            Reporter: Nicholas Knize
>            Priority: Minor
>         Attachments: 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, GeoPolygonQuery, and GeoDistanceQuery 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