Neighboring ("touching") geo-shapes not found

[AlexHofbauer (Alexander Hofbauer)]

I'm scratching my head regarding touching geo-shapes not being found.

My queries look like this:

{
  "query": {
    "bool": {
      "must_not": [
        { "term" : { "_id": "_id_" } }
      ],
      "filter": {
        "geo_shape": {
          "geometry": {
            "indexed_shape": {
              "index": "census_austria",
              "type": "FeatureCollection",
              "id": "_id_",
              "path": "geometry"
            },
            "relation": "intersects"
          }
        }
      }
    }
  }
}

To demonstrate my set of data here are a few screenshots.

"id" refers to a document in the center, marked by the red lines and dots (= polygon coordinates). The coordinates seem to be shared on touching "lines", which is also correlated by the fact that if the center polygon changes, the correct neighbors are found (and others missing).
Am I doing something wrong or is this a limitation / bug?

ES version is 6.7.1.

The first image is the larger center shape missing three neighbors at the bottom. Starting from a different document the first shape is always found as a neighbor (at the top), but the shapes themselves (except for image 4) are missing at least one neighbor at the bottom.

[Ignacio_Vera]

Hi, this is a known issue. Not sure if it can be labelled as a bug or a limitation.

In a nutshell, this effect is introduced by the encoding we are using when indexing the shapes. It currently over estimate shapes located north and east of the query shape and under estimate south and west. This over and under estimation is around 1e-7 degrees.

if you want you can open an issue in the Elasticsearch repository so it can be discussed by the team. There is a similar issue already open on Elasticsearch repository:

Issue: geo_shape 'within' query regression in 6.6

[AlexHofbauer (Alexander Hofbauer)]

My luck of running into bugs on the first attempt of implementing something .

Added an issue at: https://github.com/elastic/elasticsearch/issues/40891