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

Illegal longitude value for geoLocation on valid geo_point #24616

Closed
jvwilge opened this issue May 11, 2017 · 2 comments
Closed

Illegal longitude value for geoLocation on valid geo_point #24616

jvwilge opened this issue May 11, 2017 · 2 comments
Assignees
Labels
:Analytics/Geo Indexing, search aggregations of geo points and shapes >bug

Comments

@jvwilge
Copy link

jvwilge commented May 11, 2017

Elasticsearch version: tried with 2.3.5, 2.4.4, 5.2.1 and 5.4.0

Plugins installed: nope

JVM version : 1.8.0_121-b13 (on mac os) and 1.8.0_111-8u111-b14-2ubuntu0.16.04.2-b14

OS version : mac os 10.12.4 and Ubuntu 16.04

Description of the problem including expected versus actual behavior:

When using a geo-point the inserts sometimes fail with an 'illegal longitude value' error. The longitude value in the error could be interpreted as valid, when you subtract 360 it will give you the valid value (360 degrees are in a sphere like the earth). It might have something to do with the length in characters of the geohash (h4rr13h4rr13x fails, h4rr13h4rr13 succeeds). Another search direction might be a rounding error.

Steps to reproduce:

Create an index-mapping with a geo_point

curl -XPUT 'http://localhost:9200/my-index' -d '{
  "mappings": {
    "user": { 
      "_all":       { "enabled": false  }, 
      "properties": { 
          "geoLocation": {
            "type": "geo_point"
          }
      }
    }
  }
}'

Insert two documents :

curl -XPUT 'http://localhost:9200/my-index/user/4' -d '{"geoLocation":"h4rr13"}'
curl -XPUT 'http://localhost:9200/my-index/user/5' -d '{"geoLocation":"h4rr13h4rr13x"}'

The first insert succeeds and the second one fails :

{"error":{"root_cause":[{"type":"mapper_parsing_exception","reason":"failed to parse"}],"type":"mapper_parsing_exception","reason":"failed to parse","caused_by":{"type":"illegal_argument_exception","reason":"illegal longitude value [370.25605011731386] for geoLocation"}},"status":400}

The second call should also succeed since it is a valid place : http://geohash.org/h4rr13h4rr13x

@tlrx
Copy link
Member

tlrx commented May 11, 2017

With geohash.org, h4rr13h4rr13x resolves to -76.1073640 10.2560504 while our utility method GeoPoint.fromGeohash("h4rr13h4rr13x") returns -76.10736412927508, 370.25605011731386 causing the GeoPointFieldMapper to fail.

This looks like a bug but I'd call for @nknize 's opinion?

@tlrx tlrx added :Analytics/Geo Indexing, search aggregations of geo points and shapes discuss labels May 11, 2017
@jvwilge
Copy link
Author

jvwilge commented Jun 15, 2017

I digged around in the source and found it has something to do with the precision of the geohash. The culprit is : GeoPointField#unscaleLon(3282405194L) (value should be < 180 and > -180)

I can't however find this class on the master branch (the last version where this class is visible is 6.6.0 of Lucene),

So I'm not sure if this is an ES issue or Lucene.

The issue might be related to https://issues.apache.org/jira/browse/LUCENE-6710 (which was reported by @nknize 😄 )

@imotov imotov added the >bug label Apr 9, 2018
imotov added a commit that referenced this issue Apr 16, 2018
Fixes a possible overflow error that geohashes longer than 12 characters
can cause during parsing.

Fixes #24616
imotov added a commit that referenced this issue Apr 16, 2018
Fixes a possible overflow error that geohashes longer than 12 characters
can cause during parsing.

Fixes #24616
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

No branches or pull requests

5 participants