NOTE: The cf-satellite
mailing list is no longer active. The list archives are made available for historical reasons.
Pete: >> - - On the cf-satellite list, we have long been discussing "band"s. Did you >> consider using those ? >> >> Sorry, I don't know what bands are. I just wanted to reinforce Martin's comments. The motivation behind having a 3rd "dimension" which is the band (or channel) is to provide applications that deal with spectra displays an easier time of getting at the band (channel) data for a single pixel. The HYDRA application is one such example. There are also potential for more efficiently representing common metadata as well. The reason to push on this is because there is no widely-accepted convention for this, and datasets are being created with a variety of ways of handling bands (from separate files, to separate variables, to the use of a 3rd dimension), and applications need to be able to easily recognize that a dimension is a "band" and not, for example, an "altitude" or "pressure level". The main issue is deciding whether this "dimension" should also be a "coordinate variable" as some have recommended. I believe the consensus right now is that it does not have to be, but it must have at least a "standard_name" to identify it uniquely as a "band" ("channel"). One other comment on units: I applaud the use of units for all variables where that is meaningful, using the SI naming conventions as described by the UDUnits package. We do not much care about whether, for example, temperature is in degC or degK, since our applications accommodate either; we do care, however, that the names are "correct" (for example, not using "C" for "degC"). tom -- Tom Whittaker University of Wisconsin-Madison Space Science & Engineering Center (SSEC) Cooperative Institute for Meteorological Satellite Studies (CIMSS) 1225 W. Dayton Street Madison, WI 53706 USA ph: +1 608 262 2759
cf-satellite
archives: