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: [email protected]
R: A2.14
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
