NOTE: The cf-satellite mailing list is no longer active. The list archives are made available for historical reasons.
Tom,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.
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.)
There are no end of questions that aren't answered by this bit of CDL, but at least it gives us something to point fingers at. I'll try to provide updates based on the results of discussion.
Jim On 7/26/2011 10:28 AM, Tom Whittaker wrote:
Jim -- I like your summary. Based on that, here is what I see are the specific points we need to propose (after we all agree on them, of course): 1. several "standard_names" to accommodate our domain. From your CDL example: a. the_image (I am not in favor of this, but to answer Tom Rink's question about when you have single-banded data, I think it is essential to define a standard_name for "satellite image data") b. band c. radiation_polarization d. radiation_bandwidth e. radiation_central_wavelength 2. a new axis type that uniquely identifies this "dimension variable" as such. I am concerned with John's declaration that coordinate variables need to be monotonically increasing, because as has been pointed out by you and Tom Rink, that is not always the case. However, in your example, you use a sort of generic "index" as the "axis type" -- I like that since it then allows for other variables to be used as appropriate for the data. I will look forward to hearing from other data providers, and John Caron about the appropriateness of this idea. Thanks again for putting this together, as it will be important to have several examples on hand for people to refer to.... tom On Tue, Jul 26, 2011 at 8:19 AM, Jim Biard<Jim.Biard@xxxxxxxx> wrote:Hi. I thought it might be useful to throw out a very rough draft of the sort of thing I think we are talking about for representing bands. So here is a bit of CDL. netcdf file:/san3/npp/jbiard/NcmlSamples/band_ideas.ncml { dimensions: bandit = 4; lines = 5000; samples = 5000; variables: float image(bandit=4, lines=5000, samples=5000); :coordinates = "bandit polarization wavelength bandwidth"; :units = "W m-2"; :long_name = "the image"; :standard_name = "the_image"; short bandit(bandit=4); :axis = "index"; :long_name = "band"; :standard_name = "band"; float wavelength(bandit=4); :coordinates = "bandit"; :units = "um"; :long_name = "center wavelength"; :standard_name = "radiation_center_wavelength"; float bandwidth(bandit=4); :coordinates = "bandit"; :units = "um"; :long_name = "bandwidth"; :standard_name = "radiation_bandwidth"; short polarization(bandit=4); :coordinates = "bandit"; :units = "radians"; :long_name = "polarization"; :standard_name = "radiation_polarization"; } -- 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 _______________________________________________ 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
cf-satellite archives: