Inconsistent handling of string numerics in geo aggregation "precision" parameter

[eskibars]

The setup:

curl -XPUT http://127.0.0.1:9200/my_index -d '{
  "mappings": {
    "my_type": {
      "properties": {
        "my_loc": { "type": "geo_point" },
        "my_num": { "type": "integer" }
      }
    }
  }
}'

curl -XPUT http://127.0.0.1:9200/my_index/my_type/1 -d '{ "my_loc": [0,0] }'
curl -XPUT http://127.0.0.1:9200/my_index/my_type/2 -d '{ "my_loc": [1.25,1.25] }'
curl -XPUT http://127.0.0.1:9200/my_index/my_type/3 -d '{ "my_loc": [1.5,1.5] }'
curl -XPUT http://127.0.0.1:9200/my_index/my_type/4 -d '{ "my_loc": [1.75,1.75] }'
curl -XPUT http://127.0.0.1:9200/my_index/my_type/5 -d '{ "my_loc": [2,2] }'
curl -XPUT http://127.0.0.1:9200/my_index/my_type/6 -d '{ "my_num": 10 }'

ES is perfectly happy to convert over pure-numeric query data contained in quotes (e.g. "7"):

curl -XGET http://127.0.0.1:9200/my_index/my_type/_search?pretty -d '{
  "filter": {
    "range": {
      "my_num": {
        "gte": "7"
      }
    }
  }
}'

Returning the expected doc (my_index/my_type/6). This also "just works" with numeric aggs that I've tested (e.g. range aggs).

However, this behavior is inconsistent when specifying the "precision" variable in a geohash_grid agg:

curl -XGET http://127.0.0.1:9200/my_index/my_type/_search?pretty -d '{
  "aggs": {
    "my_agg": {
      "geohash_grid": {
        "field": "my_loc",
        "precision": "3"
      }
    }
  },
  "size":0
}'

This ignores the precision of 3 and reverts to the default of 5 (unless "3" is removed from quotes)