lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] [Commented] (LUCENE-6547) Add dateline crossing support to GeoPointInBBox and GeoPointDistance Queries
Date Tue, 16 Jun 2015 10:55:01 GMT


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:
>             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,
> 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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message