NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.

Re: [cf-satellite] Proposal for band dimension and coordinate variable

Given all the various complications described, perhaps it would make sense to make the "band" coordinate variable an array of label strings. The label strings can differentiate the bands without imposing any sequential numeric sequence constraint. Other variables would be used to specify wavelength, wavenumber, bandwidth, polarization, etc, and we could define an attribute to attach to the band coordinate variable that would identify the group of variables that are being used to describe the bands. (This would be analogous to the coordinates attribute, but would be applied to the coordinate variable instead of the data variable.) 

Is this just too far out?

On 7/25/2011 12:51 PM, Tom Rink wrote:

On 7/25/11 9:51 AM, John Caron wrote:

On 7/21/2011 1:31 PM, Tom Whittaker wrote:

The more I think about this, the more I tend
toward the idea that we probably shouldn't try to merge the different kinds of binning into a single all-encompassing coordinate. There is a point at 
which we have to go ahead and split the data into different variables.

I agree.  We have the issue, for example, of bands that have different
units.  Since "units" is an attribute of a variable, that would mean
that only bands with the same units could be included in the 'array'.
This also means that a given file might have more than one "band
coordinate variable", since there might be, say, 3 emissive channels
and 2 reflective ones with different units.
There is nothing preventing you from defining dimensions and coordinate 
variables for the different binnings of your image data and storing
everything into a single variable (with dimensions for wavelength,
bandwidth, polarization, applied filter, etc). It is just the question of whether or not some portion of it will be defined via a CF convention, and 
what that portion is.

Well stated -- getting at the heart of the matter.  I look at this
from an application developer's standpoint:  when I look at a "data
variable" and see that it has dimensions of, say, "abc x y" I would
like to know whether "abc" is "time" or "altitude" or...."band"
because I'll treat the data differently.  And, I may then seek other
variables with specific "standard_names" to define things like
wavelength, etc.

tom
I agree that if different bands have different units, these must be in a different variable. That reasoning applies to all of the variable's attributes.
Another way to say the same thing: A coordinate variable must have values that are a "sampling" along a continuous domain. One sees this violated in the poorly designed AWIPS netcdf files, eg where all "temperature" values are crammed into one variable, and the coordinate values have both pressure and height and potential temperature, etc.
There are instances where the spectral domain sampling will not be monotonic increasing. For example, AIRS L1B, where 3 broad band regions overlap, but are written into a single array, and MHS, ATMS, where two adjacent bands have the same central frequency, but differ in their respective frequency sampling range. Different applications may have different ideas how they want to interpret this. For example, in the former case we 
sort the individual wavenumbers and keep track of the sort indexes.




_______________________________________________
cf-satellite mailing list
cf-satellite@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/ 

_______________________________________________
cf-satellite mailing list
cf-satellite@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/ 

--
Jim Biard

Government Contractor, STG Inc.
Remote Sensing and Applications Division (RSAD)
National Climatic Data Center
151 Patton Ave.
Asheville, NC 28801-5001

jim.biard@xxxxxxxx
828-271-4900