Geo point on the edges of the bounding box not considered?

[mloho]

Elasticsearch server version: {"number": "5.6.6","lucene_version": "6.6.1"}
Elasticsearch client version: 6.2.1

Plugins installed: [{ "name": "x-pack", "version": "5.6.6", "description": "Elasticsearch Expanded Pack Plugin", "classname": "org.elasticsearch.xpack.XPackPlugin", "has_native_controller": true }]

JVM version: 1.8.0_151

OS version: Linux ubuntu 4.4.0-116-generic

Steps to reproduce

1. Document has a geo point field like so: "Location":[-83.106,28]
2. Java-API-generated query contains a geo bounding box filter like so:

{
  "geo_bounding_box": {
    "Location": {
      "top_left": [
        -83.106,
        28
      ],
      "bottom_right": [
        -80.106,
        27
      ]
    },
    "validation_method": "STRICT",
    "type": "MEMORY",
    "ignore_unmapped": false,
    "boost": 1
  }
}

Expected
The query returns my document.

Actual
The query returns nothing. The query contains other filters but they do not interfere with the results because once I change the top value of the top_level field of the geo bounding box filter to -83.107, the document gets returned.

Observations & Questions

• The same quirk can also be seen with the longitude value. If I change 28 and 27 to 29 and 28, I get nothing.
• I can find no documentation to back up our initial assumption that the bounding box filter would be inclusive all around. Is the query supposed to return the document if its geo point exists on any of the edges of the bounding box?

[elasticmachine]

Pinging @elastic/es-search-aggs

[colings86]

@nknize could you take a look at this one?

[imotov]

The current implementation in lucene excludes edges most of the time due to the way rounding is implemented. Basically, the query in the example is converted into:

GET /test/_validate/query?explain
{
  "query": {
    "geo_bounding_box": {
      "Location": {
        "top_left": [
          -83.106,
          28
        ],
        "bottom_right": [
          -80.106,
          27
        ]
      },
      "validation_method": "STRICT",
      "type": "MEMORY",
      "ignore_unmapped": false,
      "boost": 1
    }
  }
}

{
  "valid": true,
  "_shards": {
    "total": 1,
    "successful": 1,
    "failed": 0
  },
  "explanations": [
    {
      "index": "test",
      "valid": true,
      "explanation": "Location:[27.00000002514571 TO 27.999999965541065],[-83.10599997639656 TO -80.10600007139146]"
    }
  ]
}

As far as I can see this is intentional (although undocumented) behaviour. Should we convert this into a documentation issue? @nknize, @jpountz what do you think?

[imotov]

Discussed this with @jpountz. This is indeed an intended behavior introduced in LUCENE-7166. Geopoints have limited precision and as a result they are rounded. Geopoints are always rounded down during index time. During the query time upper boundaries of the bounding boxes are rounded down, while lower boundaries are rounded up. As a result the points along on the lower bounds (bottom and left edges of the bounding box) might not make it into the bounding box due to the rounding error.

I am going to change this issue to documentation issue and add some clarification to docs.