NOTE: The cf-satellite mailing list is no longer active. The list archives are made available for historical reasons.
Related to Edward's comment: There is a guy here who for decades has created McIDAS AREA files (GOES-type imagery) that contain both cloud-top-temperature and lifted index values -- the latter can only be computed in cloud-free regions -- "encoded" in one variable. I've told him for years that this should really be two separate data variables, but I would not be surprised if others have not done the same thing. I'm hoping he will stop doing this once we have some conventions in place.... And I agree 100% that we should stick within our domain. The original CF was really for "gridded data", but that didn't stop others who had things like "images" from using the conventions for storing their data in NetCDF files. tom On Tue, Jul 26, 2011 at 11:35 AM, Jim Biard <Jim.Biard@xxxxxxxx> wrote: > Edward, > > Could you clarify what you are thinking of when talking about having data > counts and some form of per-pixel QC in the same variable? In my mind, this > would be an example of a situation where you would have two variables - > one for the data counts, and one for the per-pixel QC. All elements of a > variable must be measurements with the same units. We shouldn't do anything > to violate that convention. > > You are right that this can be more generic than satellite image data. I'd > say it's not gridded data, since that already implies map grids to too many > people. The term that seems to be accepted is swath data, and like you > said, airborne scanners, digital imagery, etc can all fit with no real > problem. I believe that the general thought is, "don't try to cover too > much ground", and so we aren't worrying too much about whether or not our > solution is applicable in someone else's domain. I've got some background > in photogrammetry though, so I keep those same thoughts in the back of my > mind. If things are clear without inserting the word satellite, we should > probably leave it out. > > Grace and peace, > > Jim > > On 7/26/2011 11:57 AM, Edward.King@xxxxxxxx wrote: >> >> Jim, Tom, >> >> Great discussion. I have been particularly struck by the need, pointed >> out by Tom, for a handle (name) for application developers to grasp hold of, >> like 'band', or 'index' in Jim's example, that triggers an exploration of a >> series of other variables that describe parameters of each band. >> >> It is fairly clear that there are examples where what appears to be the >> natural 'band' coordinate does not easily record distinct physical values >> (e.g. a multiband instrument with bands of different widths but the same >> centre, or just multiple polarisations). But even worse you may find sensor >> data counts and some form of per-pixel qc in adjacent bands in the same >> variable, so the band axis doesn't even have a homogeneous physical meaning. >> In that case heading for something very generic, without physical units or >> interpretation, seems like an idea that will be hard to break. >> >> Also on the subject of standard names, and I know this is the CF-satellite >> list, but aren't we really talking about something like "gridded sensor >> channels" rather than "satellite image data"? Practically everything that >> has been discussed is equally applicable and relevant to airborne >> hyperspectral scanners, pre-launch sensor simulators, or just plain old >> digital cameras. If we're going to adopt a very generic stone, we might as >> well use it to kill as many birds as we can. >> >> Edward. >> >> >> -----Original Message----- >> From: cf-satellite-bounces@xxxxxxxxxxxxxxxx >> [mailto:cf-satellite-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Jim Biard >> Sent: Wednesday, 27 July 2011 12:57 AM >> To: Tom Whittaker >> Cc: cf-satellite@xxxxxxxxxxxxxxxx >> Subject: Re: [cf-satellite] very rough draft of way to represent band >> >> 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 mailing list > cf-satellite@xxxxxxxxxxxxxxxx > For list information or to unsubscribe, visit: > http://www.unidata.ucar.edu/mailing_lists/ > -- 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: