NOTE: The cf-satellite mailing list is no longer active. The list archives are made available for historical reasons.
Hi Tom, thanks for taking up this discussion.From my POV, theres no problem with a "band" or "wavelength" coordinate variable. Coordinate variables are very general, I think of geospatial coordinate variables as a special case. So I would strongly advocate a "band" coordinate variable, where the coordinate values would specify somethinkg useful, eg the wavelngth or frequency, rather than just a dimension.
Theres no problem with multiple bands in a file, since they would use different dimensions, and the coordinates atttribute can disambiguate if needed.
We would need to modify the CDM library to deal with this, but we would definitely do this once we had a clear CF spec.
A vector scale/offset for each band is a more difficult problem, and i think there have been previous suggestions on this. Its really a concept that could be used in many situations, so it might be good to think of the general case. OTOH, with compression in netcdf-4, there is some opinion that these kinds of tricks are less useful than when we had only netcdf-3.
A variable probably shouldnt have different units, however. That would be a good argument for a seperate variable. Would this cause a variable explosion?
John On 5/20/2010 11:37 AM, Tom Whittaker wrote:
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.
cf-satellite archives: