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: