`geo_bounding_box` should be smarter about how it parses geo hashes

[jpountz]

Say you ran a geohash_grid aggregation and want to filter documents that fell into a particular bucket. Currently, we do not provide an easy way to do that: the user has to compute the top left and bottom right coordinates that map to this geohash.

The geo_bounding_box already accepts geohashes as input to the corners, but we just parse it into one point that belongs to the geohash cell. If instead we made sure to round correctly and parse the top-left geohash as the top-left point of the geohash and the bottm right geohash as the bottom right point of the geohash then users could just pass the same geohash as a top-left and bottom-right corner and the bounding box would match the right documents?

cc @nknize

[nknize]

Thanks @jpountz. I've got a method in GeoUtils to compute the bounding box from a geohash. I can go ahead and add this to the GeoBoundingBoxBuilder so if the user passes just a geohash (without top_left and bottom_right) the correct bounding box is computed.

[tobias74]

which would basically bring back geohash_cell, wouldn't it? 😊👍

[jpountz]

Not really, geohash_cell worked by indexing geohashes at index-time and querying at search time using (combinations of) term queries. From a user perspective, it probably looks similar, but in that case we actually plan on running a bbox query on the coordinates of indexed geo-points, without requiring geo hashes to be indexed.

[imotov]

While writing the tests for this issue I realized that if we index a geopoint specified as a geohash it is indexed as a bottom left corner of the corresponding geohash cell instead of the center as one would expect. On high precision geohashes it doesn't really matter but with low precision geohashes it produces somewhat strange results. Would it makes sense change this as well? @nknize what do you think?

[imotov]

I have discussed this with @nknize. For me, the main conclusion of this discussion was that we support two very different data structures using the same elasticsearch datatype: geohashes and geo point and that's the source of many issues. Geo points are zero dimensional objects that are represented by longitude and latitude pairs. The geohashes are two dimensional objects that represent cells of geohash grid, which are stored as longitude and latitude of the bottom left point of the cell.

Currently, if we operate only using geopoints or only geohashes with the same precision everything works, but the moment we try to mix together geo points with geohashes or geohashes with different precision, the fact that geohashes are stored as a single point without precision breaks things.

For example, if we index 4 geohashes drt70, drt71, drt40, and drt41 and then search for:

    "geo_bounding_box": {
      "pin":
      {
        "top_right": "drt7",
        "bottom_left": "drt4"
      }
    }

we will get back drt40, drt41, and drt70 but will not get back drt71 because our current implementation only includes My PR #30698 fixes this issue, but it introduces another issue - since the top right corner of drt7 is the same point as the bottom left corner of drts with my PR the query above will also include drts, drts0, drts00 and so on. I could modify my PR to make top right edges exclusive, but then we will get into a variation of missing edge points problem #29196 but this time for top right edge. I am not really sure what's the right way to proceed here.