[jira] [Commented] (LUCENE-9154) Remove encodeCeil() to encode bounding box queries

["Ignacio Vera (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LUCENE-9154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17030626#comment-17030626 ] 

Ignacio Vera commented on LUCENE-9154:
--------------------------------------

In a comment above, it has been said that the value on the index is a lat / lon value and that is not accurate as the value on the index is represented as a two dimensional integer. These integers represents a *range* of lat / lon values (all values that are encoded to that integer) which can be decoded to a single value using GeoEncodingUtils. The value to which is decoded is not the middle of the range (which I would expect to be the logical point to represent that range) but the lower value of the range.

I understand now that probably one of the reasons that value was chosen is to make this logic happy. If I change the decoded value to the middle of the range, all this logic fails as the implementation relies on how we decode the values from the index.

 

 

 

 

 

> Remove encodeCeil()  to encode bounding box queries
> ---------------------------------------------------
>
>                 Key: LUCENE-9154
>                 URL: https://issues.apache.org/jira/browse/LUCENE-9154
>             Project: Lucene - Core
>          Issue Type: Improvement
>            Reporter: Ignacio Vera
>            Priority: Major
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> We currently have the following logic in LatLonPoint#newBoxquery():
> {code:java}
>  // exact double values of lat=90.0D and lon=180.0D must be treated special as they are not represented in the encoding
> // and should not drag in extra bogus junk! TODO: should encodeCeil just throw ArithmeticException to be less trappy here?
> if (minLatitude == 90.0) {
>   // range cannot match as 90.0 can never exist
>   return new MatchNoDocsQuery("LatLonPoint.newBoxQuery with minLatitude=90.0");
> }
> if (minLongitude == 180.0) {
>   if (maxLongitude == 180.0) {
>     // range cannot match as 180.0 can never exist
>     return new MatchNoDocsQuery("LatLonPoint.newBoxQuery with minLongitude=maxLongitude=180.0");
>   } else if (maxLongitude < minLongitude) {
>     // encodeCeil() with dateline wrapping!
>     minLongitude = -180.0;
>   }
> }
> byte[] lower = encodeCeil(minLatitude, minLongitude);
> byte[] upper = encode(maxLatitude, maxLongitude);
> {code}
>  
> IMO opinion this is confusing and can lead to strange results. For example a query with {{minLatitude = minLatitude = 90}} does not match points with {{latitude = 90}}. On the other hand a query with {{minLatitude = minLatitude}} = 89.99999996}} will match points at latitude = 90.
> I don't really understand the statement that says: {{90.0 can never exist}} as this is as well true for values > 89.99999995809048 which is the maximum quantize value. In this argument, this will be true for all values between quantize coordinates as they do not exist in the index, why 90D is so special? I guess because it cannot be ceil up without overflowing the encoding.
> Another argument to remove this function is that it opens the room to have false negatives in the result of the query. if a query has minLon = 89.999999957, it won't match points with longitude = 89.999999957 as it is rounded up to 89.99999995809048.
> The only merit I can see in the current approach is that if you only index points that are already quantize, then all queries would be exact. But does it make sense for someone to only index quantize values and then query by non-quantize bounding boxes?
>  
> I hope I am missing something, but my proposal is to remove encodeCeil all together and remove all the special handling at the positive pole and positive dateline.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org