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

NOTE: The cf-satellite mailing list is no longer active. The list archives are made available for historical reasons.

  • To: Neal K Baker <Neal.K.Baker@xxxxxxxx>
  • Subject: Re: [cf-satellite] Proposal for band dimension and coordinate variable
  • From: Tom Whittaker <whittaker@xxxxxxxx>
  • Date: Thu, 21 Jul 2011 10:36:08 -0500
Neal --

I don't see any problem in defining separate variables to contain the
values for wavenumber, if the "band dimension" is defined as
"wavelength" (or vice versa).

One of the early ideas was to have a simple dimension called "band",
which had a unique attribute that identified this as defining the
number of bands of satellite image data in the variables that had a
shape, say, of "band x y".  And let it go at that.  We would then
encourage data providers to have variables like "wavelength" and
"wavenumber" that had a shape of "band" and were defined by a
"standard_name" to be those things.

John Caron had encourage us to consider "band" to be a dimension and a
coordinate variable, so in my summary note, I went in that direction,
thinking that this would also allow us to define an array of
wavelengths, say, in one entity.  For example, if I use the name
"bands" as a dimension, it might look like this:

dimensions:
    bands = 6;
variables:
  double bands(bands) ;
    bands:long_name = "center wavelength" ;
    bands:standard_name = "wavelength";
    bands:units = "micrometer";
    bands:_CoordinateAxisType = "wavelength";

data:
  bands = 2.5, 3.9, 7.8, 10.4.....;


I believe the goal here is to establish a pattern that applications
can easily recognize as being "satellite image data", which is why
we've stayed away from things like navigation and engineering data.  I
think it would be literally impossible to define a convention that
encompasses all those things...but if we can get data providers to
structure the contents of the "image" data in their files according to
a CF Convention, then application developers have a good opportunity
when opening a file to know what they are dealing with (as opposed to
things like gridded data from, say, models).

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



  • 2011 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the cf-satellite archives: