[jira] [Comment Edited] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query
[
https://issues.apache.org/jira/browse/LUCENE-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15022849#comment-15022849
]
Nicholas Knize edited comment on LUCENE-6905 at 11/23/15 9:08 PM:
--
bq. For the record, MBR in geo speak means "minimum bounding rectangle"
yesyes! Updated the comment to spell out the acronym.
bq. We should fix this test to "behave" like the query does: rewrite up front
into the two halves of the MBR
Are you referring to {{TestGeoUtils.testGeoRelations}}? {{unwrapLon}} is only
called iff the bbox crosses the dateline. Which behaves like the
{{GeoPointDistanceQueryImpl}} does.
Also, after digging a little bit more I've decided to move the
TestGeoUtils.testGeoRelations fixes to new issue, LUCENE-6908 (patch coming
next). The {{.testGeoRelations}} method doesn't exactly test the behavior of
GeoPoint*Query as its using the BKD split technique (instead of quad cell
division) to divide the space on each pass. For "large" distance queries this
can create a lot of irregular rectangles producing large radial distortion
error when using the cartesian approximation methods provided by {{GeoUtils}}.
I have a "rewrite" fix that I'll attach to LUCENE-6908 that further divides the
space allowing us to use the fast cartesian approximation methods instead of
converting to an expensive oblate geometry approach.
bq. Can we now remove the true in {{TestGeoUtils.testGeoRelations}}
Also doing this in LUCENE-6908.
was (Author: nknize):
bq. For the record, MBR in geo speak means "minimum bounding rectangle"
yesyes! Updated the comment to spell out the acronym.
bq. We should fix this test to "behave" like the query does: rewrite up front
into the two halves of the MBR
Are you referring to {{TestGeoUtils.testGeoRelations}}? {{unwrapLon}} is only
called iff the bbox crosses the dateline. Which behaves like the
{{GeoPointDistanceQueryImpl}} does.
Also, after digging a little bit more I've decided to move the
TestGeoUtils.testGeoRelations fixes to LUCENE-6846 (patch coming next). The
{{.testGeoRelations}} method doesn't exactly test the behavior of
GeoPoint*Query as its using the BKD split technique (instead of quad cell
division) to divide the space on each pass. For "large" distance queries this
can create a lot of irregular rectangles producing large radial distortion
error when using the cartesian approximation methods provided by {{GeoUtils}}.
I have a "rewrite" fix that I'll attach to LUCENE-6846 that further divides the
space allowing us to use the fast cartesian approximation methods instead of
converting to an expensive oblate geometry approach.
bq. Can we now remove the true in {{TestGeoUtils.testGeoRelations}}
Also doing this in LUCENE-6846.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query
[
https://issues.apache.org/jira/browse/LUCENE-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15022854#comment-15022854
]
Nicholas Knize edited comment on LUCENE-6905 at 11/23/15 9:08 PM:
--
Jenkins did catch this, eventually. Looking at the randomization it looks like
the probability of producing this case is quite low. The LUCENE-6908 patch will
re-enable large distances and {{testGeoRelations}} which will produce more of
these edge cases.
was (Author: nknize):
Jenkins did catch this, eventually. Looking at the randomization it looks like
the probability of producing this case is quite low. The LUCENE-6846 patch will
re-enable large distances and {{testGeoRelations}} which will produce more of
these edge cases.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query
[
https://issues.apache.org/jira/browse/LUCENE-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15022960#comment-15022960
]
Nicholas Knize edited comment on LUCENE-6905 at 11/23/15 9:45 PM:
--
Updated patch to correct path and addresses review comments.
was (Author: nknize):
Updated patch to correct path
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-6905) GeoPointDistanceQuery using wrapped lon for dateline crossing query
[ https://issues.apache.org/jira/browse/LUCENE-6905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15014762#comment-15014762 ] Nicholas Knize edited comment on LUCENE-6905 at 11/20/15 5:04 AM: -- Simple patch that unwraps the center longitude such that distance is correctly computed. Also corrects maxRadialDistance for center location at the poles. This fixes build failure #14669 and passes a 200 iteration beast test.. was (Author: nknize): Simple patch that unwraps the center longitude such that distance is correctly computed. Also corrects maxRadialDistance for center location at the poles. This is fixes build failure #14669 and passes a 200 iteration beast test.. > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
