[
https://issues.apache.org/jira/browse/LUCENE-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15015633#comment-15015633
]
Michael McCandless commented on LUCENE-6905:
--------------------------------------------
For the record, MBR in geo speak means "minimum bounding rectangle" :)
In the {{GeoDistanceUtils.maxRadialDistance}} javadocs can you say that the
returned results is in meters?
Is this comment in {{GeoUtils.unwrapLon}} stale?
{noformat}
+ // if centerLon is within bbox
{noformat}
(I see no {{centerLon}} nor a bbox).
Can you add a javadoc to this method? Can you add an assert before returning
that lon is now in-bounds? (I.e. that the incoming lon did not require more
than one iteration of unwrapping). Can you make the {{ += 360}} also a double
(or make the other one an int)?
OK so the test failures were caused by 1) not having a tolerance for up to 0.5%
error in the distance, and 2) not handling dateline crossovers correctly, and
not pole crossing issues? We should fix this test to "behave" like the query
does: rewrite up front into the two halves of the MBR, instead of unwrapping on
each step of the recursion. But let's do that separately ... can you add a
TODO?
Can we now remove the {{true}} in {{TestGeoUtils.testGeoRelations}}?:
{noformat}
// TODO: GeoUtils APIs are still buggy for large distances:
if (true || useSmallRanges) {
// Approx 3 degrees lon at the equator:
radiusMeters = random().nextDouble() * 333000;
} else {
radiusMeters = random().nextDouble() *
GeoProjectionUtils.SEMIMAJOR_AXIS * Math.PI / 2.0;
}
{noformat}
I.e. we can now test large distances?
> 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
>
>
> GeoPointDistanceQuery handles dateline crossing by splitting the 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 distance from a eastern point to a western MBR provides
> incorrect results.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
