[
https://issues.apache.org/jira/browse/LUCENE-6547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicholas Knize updated LUCENE-6547:
-----------------------------------
Attachment: LUCENE-6547.patch
Updated patch continuing from [~mikemccand] last patch. Updates:
* Addresses LUCENE-6562 to share ranges across segments. To guard against OOM
exceptions the ranges needed to be purged once all segments have been visited.
See GeoPointTermQuery line 87 for this check.
* Removed GeoHash string methods from GeoUtils. I'm going to move this into a
separate issue for better tracking and reviewing.
* Updated javadocs
bq. Wait: these queries can't handle large ranges right?
Large ranges were previously discouraged because it takes on the order of
~2secs to correctly compute the ranges for large search areas. Since this
occurred for every segment large search over large data was quite time
consuming. Reusing ranges across segments has brought this down to the amount
of time it takes to compute the ranges.
bq. Can we remove the separate bbox from GeoPointInPolygonQuery's ctor?
Yes! I believe so. The intent was to improve performance for detailed polygons
(those with many vertices) by providing precomputed or cached bounding boxes
rather than having the query recompute. Might be worth benchmarking to be
certain whether we want to take away this utility. Sure it can be used
maliciously, maybe good documentation can raise awareness?
> Add dateline crossing support to GeoPointInBBox and GeoPointDistance Queries
> ----------------------------------------------------------------------------
>
> Key: LUCENE-6547
> URL: https://issues.apache.org/jira/browse/LUCENE-6547
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
> Reporter: Nicholas Knize
> Attachments: LUCENE-6547.patch, LUCENE-6547.patch, LUCENE-6547.patch,
> LUCENE-6547.patch, LUCENE-6547.patch, LUCENE-6547.patch, LUCENE-6547.patch,
> LUCENE-6547.patch
>
>
> The current GeoPointInBBoxQuery only supports bounding boxes that are within
> the standard -180:180 longitudinal bounds. While its perfectly fine to
> require users to split dateline crossing bounding boxes in two,
> GeoPointDistanceQuery should support distance queries that cross the
> dateline. Since morton encoding doesn't support unwinding this issue will
> add dateline crossing to GeoPointInBBoxQuery and GeoPointDistanceQuery
> classes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
