On 01/10/15 18:24, Jonathan Gregory wrote:
> Dear Maarten
>
>> There is one issue left: the two wavelengths used in the derivation
>> of the 'residue' (older, even more vague name than
>> ultraviolet_aerosol_index) must somehow be attached to the variable.
>> We can stipulate that the anciliary_variables link to a variable
>> with standard_name radiation_wavelength to indicate these two
>> wavelengths. I think something similar have been done before.
>
> This too would normally be done by using a coordinate or scalar coordinate
> variable; many quantities described by standard names use this mechanism for
> attaching defining parameters. I suppose we should put an entry in the FAQ
> for this. The difficulty is that you have got two of them. Excuse me for not
> having read the reference you supplied: do these two wavelengths describe a
> range in any sense, so that it would make sense to store than as bounds for
> a size-one coordinate variable? If not, you could do as you suggest (a size-
> two coordinate variable) or (perhaps more user-friendly), could the two
> defining parameters be given two new standard names containing the phrase
> radiation_wavelength, to distinguish the two coordinates?
The calculation is done on two reflectances, typically on two 1 nm wide bands.
Several pairs have been used to avoid instrumental artefacts, but 340/380 nm and
354/388 nm are typical value pairs. A size two coordinate variable seems most
appropriate.
> Reasons for not using attributes include that it avoids proliferation of
> attributes to be defined, which make the convention more complicated; that
> these parameters often need attributes themselves (particularly units);
> that sometimes the parameter might take several possible values, and then
> it is obviously like a coordinate variable i.e. an independent variable
> on which the data variable depends.
We currently attach an attribute 'radiation_wavelength' to the variable in which the
two values are stored. Yes, netCDF4 allows for arrays in attributes. Because we have
two pairs (the above mentioned pairs will both be in out output product), using
separate coordinate variables adds a significant overhead in terms of number of
variables. I'm not sure I want that.
>> "assuming_complete_cloud_cover" has my slight preference.
> I slightly prefer assuming_completely_cloudy_sky, not on grounds of
> English (either sounds fine to me), but because of the correspondence with
> assuming_clear_sky. But others may disagree.
If there are no replies in a week or so, we'll go with assuming_completely_cloudy_sky
Best,
Maarten Sneep
--
KNMI
T: 030 2206747
E: maarten.sneep at knmi.nl
R: A2.14
Received on Thu Oct 01 2015 - 11:04:52 BST
