NOTE: The cf-satellite mailing list is no longer active. The list archives are made available for historical reasons.
Hi Jim... Let me try to answer your questions and otherwise comment: > It might be good to use the term "coordinate variable" instead of "dimension > variable". I believe this is the proper CF terminology. Yes "dimension variable" is a misnomer. > Thinking about the polarization issue helped me realize that the names of > the dimensions (and thus coordinate variables) are not fixed by the CF > Conventions. Perhaps there is software out there that assumes that the time > dimension will be named "time", but CF intends that the standard_name and/or > the axis attribute (and, lacking that, the units attribute) is what uniquely > identifies a coordinate variable as having a specific interpretation. Am I > Am I right that most of what we are really talking about here is defining > strings > to use in the standard_name and axis attributes? Yes. The actual name of the coordinate variable should not matter. > Assuming that the answer to my question is "yes", is there a single > description for a string to use in the axis attribute that would be > sufficient to cover most of the different types of radiant energy binning? Good question...but I like this direction. It would then allow for other variables to be defined, with standard_names I hope, that would be used to represent things like polarization and frequency (thanks, Mary Jo), etc. If we go this direction, we should propose these (at least the beginning of them) as well. > Would it work to have "band" as the value to put in the axis attribute, and > then allow the standard_name and units attributes to specialize the type of > band, such as wavelength vs polarization? (I assume that trying to put > wavelength and polarization into the same dimension is probably not going to > be a good idea.) Since the coordinate axis type would only specify " this coordinate variable is a 'band ", it is conceivable that the other attributes could then be used to define the type (e.g., wavelength) and units. I'm wondering, though, if it would not be better to try to define this, but rather to use other variables (with a shape of 'band' or whatever the coordinate variable name is), as discussed above. > Other than a set of flag values, how would you indicate polarization in a > coordinate variable? Consider that you might possibly need to include left- > and right-circular polarization. The same goes with Ken Knapp's point about > applied filters and such. 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 -- 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: