[
https://issues.apache.org/jira/browse/LUCENE-6547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14587850#comment-14587850
]
Michael McCandless commented on LUCENE-6547:
--------------------------------------------
Thanks [~nknize]!
bq. Added back validation check for lat/lons passed to GeoPointInBBoxQuery.
Thanks, but is this really right? :)
I can see it being considered "OK" to pass "invalid" lat (goes over a
pole) or lon (when it crosses the date line) with the expectation that
the API normlalizes it? Maybe?
E.g. it makes it easier for client code to e.g. do bbox search for +/-
0.5 lat/lon from a given center w/o having to special case the
dateline itself... or a distance query too.
In any event, whatever we decide is the "right" behavior, can you add
"testInvalidXXX" test cases that show we are in fact throwing excs for
the invalid cases?
bq. Will get this in either the next iteration, or maybe a separate 'improve
GeoPointField Testing' issue?
OK we can do it separately, but I think it's pretty important to keep
testRandom approachable: testRandoms have a tendency to become
disastrous over time (have a look at TestGrouping.testRandom if you
don't believe me!).
It seems like there's some dup code, e.g. computeBBox is in both
GeoPointDistanceQuery and GeoPointDistanceQueryImpl?
Can you extend testRandom to test date-line wrapping? I did this in
TestBKDTree so I think for now we can just copy those changes over and
refactor later?
I'll look more at the patch ...
> 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
>
>
> 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]
