NOTE: The cf-satellite mailing list is no longer active. The list archives are made available for historical reasons.
Thanks to Ken Roberts for posting the document of issues they put
together. It was a great, succinct collection of topics related to
"satellite data conventions". While it has been a while, I'm feeling
a renewed sense of urgency to get this moving again. So I would like
to re-invigorate our discussion....here goes:
I would like to focus on the issue of the "band dimension". Aside
from other metadata, the concept that is not already in the CF
conventions is for a dimension that is not geospatial or temporal. [I
also want to avoid the notion of "CF for images" since this is way too
broad...]
EUMETSAT has "solved" this problem for themselves by having one
variable per "band" (or "channel", since they use names like "ch01",
"ch02", etc.). However, for hyper-spectral data (think: thousands of
bands), it is essential that software be able to treat this a yet
another "dimension".
I would, therefore, propose that we explore adopting "band" as a new
type of "coordinate variable" that can be used across the board to
signal this situation. Perhaps "coordinate variable" is the wrong
approach, and a simple "dimension variable" would suffice?
We likely will need to somehow accommodate more than one of these per
file: for example, we may have emissive and reflective bands in the
same file, which have different spatial dimensions. Perhaps a
"standard_name" could be used to signal the nature of this variable.
The variable could be used as a simple index (monotonically
increasing), or it could contain values (such as wavelength)...is this
desirable?
This opens the door for other metadata variables to be dimensioned by
"band". Examples:
1. wavelength (or wavenumber)
2. a description of the band ("Water vapor channel")
3. calibration coefficients
4. spectral response function
4. spatial resolution or other band dependent orbital information
4. etc.
Applications would have to be able to easily recognize this,
obviously...but there are some things the NetCDF library might need to
accommodate as well...for example:
Each "band" may have its own "unit" or even scale and offset.
Presently, there are no provisions for a "dimensioned attribute"; I
supposed these attributes could be specified as variables, but I worry
about applications trying to connect them (or the library, in the case
of scaling and NetCDF-Java).
I'm hoping the NetCDF developers have thought about this...and can
steer us a bit into what makes sense.....
Presently, as I mentioned EUMETSAT (and others) have elected to use
one variable per band, and thus can be currently CF-1.4 compliant by
treating these like "grids". However, I think it is essential that we
push now to include the concept of "band as a dimension", and make a
"convention" so that applications can easily recognize this when it
happens.
I'd like to restrict this thread to "band" only; I realize that there
are lots of other metadata related issues that need to be addressed --
however, many of them are sensor or satellite-specific and might fall
outside of the purview of our discussions.
--
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: