Hi Jim...
> I used "the_image" because I was too lazy to hunt up a proper name. I think
> the standard name for the image data will vary widely depending on the
> contents. It could be brightness temperature, radiance, or something else
> altogether. I don't think there will be a single standard name.
As long as an application can uniquely identify such a variable as "an
image" (where appropriate), I don't think a standard_name would even
been needed. That, to me, is the central issue: an application gets
the attributes for a variable and needs to figure out what it is. If
there were a generic standard_name, that would help; however, in the
absence of that, then the app would have to look at the shape and/or
coordinates and explore those variables to see if any of them stands
out as meaning "this is an image".
> In this example, there is no problem with sequential-valued coordinate
> variables. The only true coordinate variable is the one named bandit. The
> others are data variables that are identified as auxiliary coordinates in
> the coordinates attribute of the image variable. These variables can have
> values that repeat, alternate, etc. Everything is driven by the parametric
> coordinate variable bandit. (Which, as I suggested previously, could be an
> array of strings that uniquely named the different bands instead of an array
> of integers. It functions as a key.)
My head is thick, obviously. But I've got it now: we have a
"dimension" which is also a "coordinate variable" with a unique
"_CoordinateAxisType". The contents (values) of the variable,
however, could be most anything -- the key is that it is easily
recognized as such and is used to dimension other variables with
metadata (like central wavelengths or something).
Thanks...
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
