> I'm not sure you can safely interpret the phenomena without taking into account the local tables

That _is_ correct. If the master tables version is 255 we've got a local parameter code as defined by the originating centre. Almost certainly, _all_ the parameters will be different in this case.

Local parameter tables can also define those entries in the master table from 192 to 254 which are _"Reserved for local use"_, when master tables version is not 255 and 192 <= param <= 245.

If we wish to handle local param codes, we need to take into account:
 - master tables version
 - local tables version
 - originating centre (but not subcentre)

Note: The grib spec ___"strongly discourages"___ exchange of such data between centres. One could reasonably argue that by telling Iris about params from different centres we are actively encouraging such exchange, and would be in conflict with the grib spec.

However, in a modern, collaborative environment we can also reasonably expect centres to exchange experimental data that relies on local tables. In this case, and in the case of internal exchange, we certainly need to be able to understand local param codes from at least one centre.

Perhaps we can separate the _capability_ (which must be in the Iris core) from the _details_ (which need not). One such solution might see the user activating local param handling for one or more specific centres:
```
iris.fileformats.grib.allow_local_codes("ecmwf", "ukmo")
```