[
https://issues.apache.org/jira/browse/LUCENE-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15024287#comment-15024287
]
Michael McCandless commented on LUCENE-6905:
--------------------------------------------
Thank you for separating out the patches [~nknize].
I don't like that we are changing the error tolerance from 0.5% to 7% when USGS
says it's supposed to be 0.5%. Is that intentional? I mean, is the error in
these queries really supposed to be so high?
Can we move the lon unwrapping up into {{GeoPointDistanceQuery.rewrite}}
method, and add {{centerLon}} as a parameter to {{GeoPointDistanceQueryImpl}},
since it "knows" when it's making queries that have a boundary on the date
line? In fact, it knows which sub-query is "to the left" and which is "to the
right", so maybe we just inline the logic inside rewrite and remove
{{GeoUtils.unwrapLon}} public method?
> GeoPointDistanceQuery using wrapped lon for dateline crossing query
> -------------------------------------------------------------------
>
> Key: LUCENE-6905
> URL: https://issues.apache.org/jira/browse/LUCENE-6905
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Nicholas Knize
> Fix For: Trunk, 6.0, 5.4
>
> Attachments: LUCENE-6905.patch, LUCENE-6905.patch, LUCENE-6905.patch
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the Minimum
> Bounding Rectangle (MBR) into east/west ranges and rewriting to a Boolean
> SHOULD. PostFiltering is accomplished by calculating the distance from the
> center point to the candidate point field. Unfortunately the center point is
> wrapped such that calculating the closest point on the "circle" from an
> eastern point to a western MBR provides incorrect results thus causing false
> negatives in the range creation. This was caught by a jenkins failure and
> reproduced in 2 places: {{GeoPointDistanceTermsEnum}} and {{TestGeoRelations}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
