Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Empty geo_point being treated as [-180, -90]? #23579

Closed
magrossi opened this issue Mar 14, 2017 · 1 comment · Fixed by #30376
Closed

Empty geo_point being treated as [-180, -90]? #23579

magrossi opened this issue Mar 14, 2017 · 1 comment · Fixed by #30376
Assignees
Labels
:Analytics/Geo Indexing, search aggregations of geo points and shapes >bug

Comments

@magrossi
Copy link

Hi,

I'm migrating an ES cluster from v1.7.5 to v5.1.2 and noticed that in v5.1.2 empy geo_point fields are being treated as if they were valid points with coordinates [-180, -90] within geo_xxx queries (used to work fine in v1.7.5). I'm trying to simply get the geo_bounds of my geo_point field to determine the area it covers. Previously I used "max" and "min" aggs on each coordinate (lat and lon) to accomplish this (this is just for our own ease of implementation) and now this is not even working (returns "null" for every coordinates max and min).
Has anyone experienced this? How do I get the geo_bounds without the empty points being considered? I've tried "bool" > "must" > "exists" without success.
Please see below some examples of what I just reported.

Mapping

          "Location": {
            "type": "geo_point"
          },

Data Samples

"Location": "-0.533218, 34.5575", << non-empty valid point
"Location": "",                   << empty invalid point

Query

GET _search
{
    "query": {
        "bool" : {
            "must" : {
                "exists": { "field": "Location" }
            }
        }
    },
    "size": 0,
    "aggs": {
      "Location_bounds": {
        "geo_bounds": {
            "field": "Location"
        }
      },
      "Location_lon_min": {
        "min": {
          "field": "Location.lon"
        }
      },
      "Location_lon_max": {
        "max": {
          "field": "Location.lon"
        }
      },
      "Location_lat_min": {
        "min": {
          "field": "Location.lat"
        }
      },
      "Location_lat_max": {
        "max": {
          "field": "Location.lat"
        }
      }
    }
}

Query result

{
  "took": 3,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "failed": 0
  },
  "hits": {
    "total": 66000,
    "max_score": 0,
    "hits": []
  },
  "aggregations": {
    "Location_lat_min": {
      "value": null
    },
    "Location_lat_max": {
      "value": null
    },
    "Location_lon_min": {
      "value": null
    },
    "Location_lon_max": {
      "value": null
    },
    "Location_bounds": {
      "bounds": {
        "top_left": {
          "lat": 0.5858219834044576,
          "lon": 34.09869999624789
        },
        "bottom_right": {
          "lat": -90,
          "lon": -180
        }
      }
    }
  }
}

And I can confirm I have no geo_point in the [-180, -90] coordinate.

Thank you very much.

@nknize nknize added the :Analytics/Geo Indexing, search aggregations of geo points and shapes label Mar 14, 2017
@nknize nknize self-assigned this Mar 14, 2017
@rjernst
Copy link
Member

rjernst commented Mar 15, 2017

I believe this is a bug in GeoPoint.resetFromString. We should be checking for empty value at the beginning, so that we do not fall back to trying to decode a geohash with an empty string (which looks like it will have a morton encoding of 0, which I believe maps to [-180, -90]). @nknize can you confirm?

@nknize nknize assigned imotov and unassigned nknize Mar 26, 2018
@nknize nknize added the >bug label Mar 26, 2018
imotov added a commit to imotov/elasticsearch that referenced this issue May 4, 2018
Adds verification that geohashes are not empty and contain only
valid characters.

Closes elastic#23579
imotov added a commit that referenced this issue May 7, 2018
Adds verification that geohashes are not empty and contain only
valid characters. It fixes the issue when en empty geohash is
treated as [-180, -90] and geohashes with non-geohash character
are getting resolved into invalid coordinates.

Closes #23579
imotov added a commit that referenced this issue May 7, 2018
Adds verification that geohashes are not empty and contain only
valid characters. It fixes the issue when en empty geohash is
treated as [-180, -90] and geohashes with non-geohash character
are getting resolved into invalid coordinates.

Closes #23579
colings86 pushed a commit that referenced this issue May 8, 2018
Adds verification that geohashes are not empty and contain only
valid characters. It fixes the issue when en empty geohash is
treated as [-180, -90] and geohashes with non-geohash character
are getting resolved into invalid coordinates.

Closes #23579
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Analytics/Geo Indexing, search aggregations of geo points and shapes >bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants