You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Michael McCandless (JIRA)" <ji...@apache.org> on 2015/06/12 16:57:00 UTC
[jira] [Commented] (LUCENE-6547) Add dateline crossing support to
GeoPointInBBox and GeoPointDistance Queries
[ https://issues.apache.org/jira/browse/LUCENE-6547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14583531#comment-14583531 ]
Michael McCandless commented on LUCENE-6547:
--------------------------------------------
Thanks [~nknize]!
Looks like we no longer get exc if we pass invalid lat or lon to
GeoPointInBBoxQuery? Can we get that back (e.g. if I pass
lat=1000.0).
Can we revert the changes to GeoPointInPolygonQuery now (since
GeoPointDistanceQuery now extends GeoPointInBBoxQuery instead)?
Seems like GeoPointTermsEnum.min/maxLat could still be final?
Hmm in GeoPointTermsEnum, for the dateline split case, I'm worried how
we overwrite minLon/maxLon, because in the accept method we then check
minLon/maxLon but at that point it will be from the 2nd bbox? Isn't
this possibly wrong / buggy (why is test not failing)?
Another way to handle this "crosses dateline" would be to use the
rewrite method? Ie, rewrite to BQ, SHOULD'ing the 2 queries? It
could be simpler that way? Then the query itself, terms enum, etc.,
don't have to deal with this case.
Do we still need circleToPoly? It's unused now right? Hmm the
javadocs for GeoPointDistanceQuery are stale?
Can we fix the random test to more strongly separate out the cases its
testing? E.g. make a separate "tolerateRadiusIgnorance" and
"tolerateBBoxIgnorance" methods, make separate code for verifying the
radius vs bbox/poly cases, etc.? We can e.g. factor out a
"getMatchingDocs" method that returns the FixedBitSet.
> 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
>
>
> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org