Allow to parse lat/lon as strings and coerce them

[spinscale]

In order to be more failsafe parsing GeoPoints can support
lat/lon as strings and coerce them. Added support and test for this.

[clintongormley]

Also needs to be fixed here:

[test][1], node[-PhRAYloSDezUgMBB--99w], [P], s[STARTED]: Failed to execute [[[]], suggestSource[{"result":{"text":"hote","completion":{"context":{"location":{"lat":"52.22","lon":"4.53"}},"field":"suggest_geo"}}}]]
org.elasticsearch.ElasticsearchException: failed to execute suggest
at org.elasticsearch.action.suggest.TransportSuggestAction.shardOperation(TransportSuggestAction.java:171)
at org.elasticsearch.action.suggest.TransportSuggestAction.shardOperation(TransportSuggestAction.java:61)
at org.elasticsearch.action.support.broadcast.TransportBroadcastOperationAction$AsyncBroadcastAction$2.run(TransportBroadcastOperationAction.java:226)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
Caused by: org.elasticsearch.ElasticsearchParseException: latitude must be a number
at org.elasticsearch.search.suggest.context.GeolocationContextMapping.parseQuery(GeolocationContextMapping.java:331)
at org.elasticsearch.search.suggest.context.GeolocationContextMapping.parseQuery(GeolocationContextMapping.java:65)
at org.elasticsearch.search.suggest.context.ContextMapping$ContextQuery.parseQueries(ContextMapping.java:296)
at org.elasticsearch.search.suggest.completion.CompletionSuggestParser.parse(CompletionSuggestParser.java:112)
at org.elasticsearch.search.suggest.SuggestParseElement.parseInternal(SuggestParseElement.java:90)
at org.elasticsearch.action.suggest.TransportSuggestAction.shardOperation(TransportSuggestAction.java:165)
... 5 more

[spinscale]

updated, can you check again?

[s1monw]

maybe you want to use a swich here?

[clintongormley]

Tests now passing ++

[spinscale]

I think we could also remove the duplicated code here. The reason it exists is to support these two formats in the query

POST services/_suggest
{
    "suggest" : {
        "text" : "m",
        "completion" : {
            "field" : "suggest_field",
            "size": 10,
            "context": {
                "location": {
                    "value": {
                        "lat": 0,
                        "lon": 0
                    },
                    "precision": "1km"
                }
            }
        }
    }
}

POST services/_suggest
{
    "suggest" : {
        "text" : "m",
        "completion" : {
            "field" : "suggest_field",
            "size": 10,
            "context": {
                "location": {
                        "lat": 0,
                        "lon": 0,
                        "precision": "1km"
                }
            }
        }
    }
}

If we only want to support the first format, we could remove the duplicate geo point parsing... the second one is shorter and more handy through

[spinscale]

updated the PR to use a switch statement

[s1monw]

LGTM

[s1monw]

seems like we have to backport this to 1.0 branch as well @spinscale should we?

[spinscale]

+1, will do