NOTE: The cf-satellite mailing list is no longer active. The list archives are made available for historical reasons.
Hi everyone....
During the ESIP telecon last week, I was charged with sending out a
"where are we with 'band' as a dimension/coordinate" to summarize the
discussions of this issue we have had on this list. Below is my
draft, summarized from previous emails....
I had sent this to John Caron @ Unidata for a sanity check, but just
realized they are doing Training Workshops, so he is perhaps tied up
with those. To avoid loosing some of the momentum from last week, I'm
sending this around for other comments now.
And....please....if I misinterpreted or misrepresented anything from
previous postings, send a note back!!
Thanks!
tom
========================
There were two directions discussed. One simpley used a name like
"band" solely as a dimension and defined a standard_name for this so
that code could recognize it as such. Several other variables were
then used to define wavelength, etc., again using standard_names to
alert applications as to what they were.
The second one defined coordinate axis types to handle this. The
details of this one follow.
The proposal is this:
1. create standard_names that can be recognized by applications as
being the special "band dimension" variable (much like "time" is).
The name of this dimension variable would not, however, be specified,
but inferred from its attributes.
2. create two coordinate axis types ("wavelength" and "wavenumber")
that can be recognized by the NetCDF library as defining a "spectral
coordinate".
Thus, the band dimension might be declared:
<variable name="band" shape="band" type="float" >
<attribute name="standard_name" value="wavelength" />
<attribute name="units" value = "cm" />
<attribute name="_CoordinateAxisType" value = "wavelength" />
</variable>
The dimension variable can then be used to dimension arrays associated
with the spectral channels, e.g., wavelength boundaries for each band
(channel), units, scaling, etc. The use of these (dimensioned)
variables, however, would be up to the application developers rather
than made part of the conventions, per se.
This would necessitate creating perhaps two new standard_names:
1. "wavelength" (I note there is already a "radiation_wavelength" with
"electromagnetic_wavelength" as an alias, but I naively don't see an
issue for making just "wavelength" a standard name, either. I also
recognize that in most cases this refers to the center wavelength of
the band/channel, and perhaps should be so designated...?).
2. "wavenumber" (There is no equivalent standard_name that I could
find. Again, I imagine this would actually refer to a center
wavenumber.
We would also then need to define two new coordinate axis types:
wavelength and wavenumber.
For the case where people don't or can't use the dimension variable as
a coordinate variable, we recommend that they use the convention name
"band" as the dimension variable so that applications can at least
recognize this for what it is.
In all cases, new (dimensioned) variables could then be used to
specify band-specific attributes. For example:
<variable name="minimum_wavelength" shape="band" type="double">
<attribute name="units" value="cm" />
</variable>
or something like that.
=============================================
--
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: