NOTE: The cf-satellite mailing list is no longer active. The list archives are made available for historical reasons.
Dear Barry and David: For udunits support, send an email to support-udunits@xxxxxxxxxxxxxxxx. very respectfully, randy ---------------------------------------- From: "Weiss, Barry H (398B)" <barry.h.weiss@xxxxxxxxxxxx> Sent: Thursday, August 07, 2014 10:06 AM To: "Moroni, David F (398M)" <David.F.Moroni@xxxxxxxxxxxx>, "Jonathan Gregory" <j.m.gregory@xxxxxxxxxxxxx> Cc: "Niedfeldt, John C (398M-Affiliate)" <John.C.Niedfeldt@xxxxxxxxxxxx>, "CF Metadata List" <cf-metadata@xxxxxxxxxxxx>, "John Graybeal" <john.graybeal@xxxxxxxxxxxxxxxx>, "cf-satellite@xxxxxxxxxxxxxxxx" <cf-satellite@xxxxxxxxxxxxxxxx> Subject: Re: [cf-satellite] [CF-metadata] normalized_radar_backscatter_coefficient Jonathan, As the data product engineer for the SMAP project, I second David's request. We are attempting to employ CF metadata in our products. This is not a challenge at level 2 and above where our products provide geophysical measure, but is a challenge at level 1, where our products provide instrument measurements. Please consider inclusion of dB units. That should include dB based on unit less measure, as well as dB relative to watts and volts. Thanks and Regards, Barry On 8/6/14 7:49 PM, "Moroni, David F (398M)" <David.F.Moroni@xxxxxxxxxxxx> wrote: >Hi Jonathan, > >Just as follow up from my last email, I noticed an online email exchange >where you had responded to a request to use units of dB (decibels) even >though it is not currently in the udunits database: >http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056572.html > >We also agree it would be wise to include dB in the udunits database, and >we will be applying these units for our scatterometer datasets. > >We hope to see this incorporated in the near future. > >Thanks again for your considerations. > >Cheers, >David > >On 8/5/14 7:24 PM, "Moroni, David F (398M)" <David.F.Moroni@xxxxxxxxxxxx> >wrote: > >>Hi John, >> >>We will incorporate these constant coordinate variables as you've >>recommended. >> >>Since during this 2+ month comment period we have not received any >>objections on our proposed inclusion of >>normalized_radar_backscatter_coefficient as a CF standard_name, we will >>now proceed with applying this as a standard_name for our relevant >>scatterometer datasets. >> >>On to our next concern: when will our proposed standard name become >>officially adopted into the CF standard name listing? >> >>Timing is not super critical, but considering what I perceive to be a >>consensus during this exchange of emails, we would at least like to >>obtain >>a statement of confirmation from the CF folks that this standard name >>will >>be adopted. >> >>A simple, brief email response from the chair or co-chair of this >>committee would suffice. >> >>Thank you again for your consideration and generous feedback. >> >>Cheers, >>David >> >> >>On 7/23/14 9:32 PM, "John Graybeal" <john.graybeal@xxxxxxxxxxxxxxxx> >>wrote: >> >>>Hi David, >>> >>>Thanks for the question. Constant coordinate variables are hopefully not >>>a big deal -- they can be easily specified as scalar coordinate >>>variables, as noted in the example here: >>>http://cfconventions.org/Data/cf-convetions/cf-conventions-1.7/build/cf- >>>c >>>o >>>nventions.html#scalar-coordinate-variables. >>> >>>That's an example for analysis time and pressure level, but it's OK to >>>use coordinate variables for any critical reference variable. (Chapter >>>4: >>>"Coordinate types other than latitude, longitude, vertical, and time are >>>allowed." Incidentally, the text in reference [1] was proposed as a >>>replacement for that sentence in http://kitt.llnl.gov/trac/ticket/100, >>>which has been accepted but not implemented.) >>> >>>I had to search the archives to fully understand the motivation, here's >>>what I found (ooh, FAQ question!): >>> (1) To locate the data in an axis other than space or time. [1] >>> (2) To provide a consistent way to specify the value of a certain >>>other >>>parameter, or even multiple parameters; if the parameter is unvarying, >>>it >>>can be specified as a scalar. [2] >>> >>>So your declaration that both the radiation wavelength and scatter angle >>>were essential led to my suggestion. Adopting it standardizes the method >>>for citing the needed information (consistent with other standard names, >>>and across users of this standard name), thereby maximizing >>>interoperability. >>> >>>By all means reply further if this seems problematic, I'm at the edge of >>>my experience but others can jump in. >>> >>>John >>> >>>[1] On Apr 11, 2013, at 12:45, Jonathan Gregory >>><j.m.gregory@xxxxxxxxxxxxx> wrote: >>> >>>> The commonest use of coordinate variables is to locate the data in >>>>space and >>>> time, but coordinates may be provided for any other continuous >>>>geophysical >>>> quantity (e.g. density, temperature, radiation wavelength, zenith >>>>angle of >>>> radiance, sea surface wave frequency) or discrete category (see >>>>Section 4.5, >>>> "Discrete axis", e.g. area type, model level number, ensemble member >>>>number) >>>> on which the data variable depends. >>> >>> >>>[2] On Dec 24, 2010, at 13:26, Jonathan Gregory >>><j.m.gregory@xxxxxxxxxxxxx> wrote: >>> >>>> We quite often recommend, for instance in connection with particular >>>>standard names, >>>> that the value of a certain other parameter could be specified, e.g. a >>>> radiation_wavelength for radiative quantities. Scalar coord vars are a >>>>neat >>>> way to do this. They are something between multivalued coord vars and >>>> attributes in terms of function: easier than coord vars, and more >>>>powerful >>>> than attributes because they can themselves have attributes. >>> >>>[3] >>> >>> >>>On Jul 23, 2014, at 17:39, Moroni, David F (398M) >>><David.F.Moroni@xxxxxxxxxxxx> wrote: >>> >>>> Hi John (G), >>>> >>>> John (N) and myself are working together on this effort. >>>> >>>> Thanks for your inputs here. >>>> >>>> In general, I agree with the first part of your revision of the >>>>description, but I don't suggest including a reference to the >>>>coordinate >>>>values for the other standard names as you've suggested, namely >>>>"radiation_wavelength" and "scattering_angle", simply because this type >>>>of measurement assumes: 1) constant wavelength and 2) constant >>>>scattering angle. I simply don't follow your reasoning for why such >>>>coordinate values would be needed given the nature of these values >>>>being >>>>constant. Can you provide some rationale as to why we would want to >>>>list >>>>these as coordinate values? >>>> >>>> Cheers, >>>> David >>>> >>>> ================================================== >>>> David Moroni >>>> Ocean Wind and Scatterometry Data Engineer >>>> Physical Oceanography Distributed Active Archive Center >>>> Jet Propulsion Laboratory >>>> 4800 Oak Grove Dr >>>> M/S 158-242 >>>> Pasadena, CA 91109 >>>> Phone: 818.354.2038 >>>> Fax: 818.353.2718 >>>> ================================================== >>>> >>>> From: John Graybeal <john.graybeal@xxxxxxxxxxxxxxxx> >>>> Date: Wednesday, July 23, 2014 3:52 PM >>>> To: "Niedfeldt, John C (398M-Affiliate)" >>>><John.C.Niedfeldt@xxxxxxxxxxxx> >>>> Cc: CF Metadata List <cf-metadata@xxxxxxxxxxxx>, David F Moroni >>>><David.F.Moroni@xxxxxxxxxxxx> >>>> Subject: Re: [CF-metadata] normalized_radar_backscatter_coefficient >>>> >>>>> Hi John (N), >>>>> >>>>> Thanks for the detailed explanation. I am convinced the new term is >>>>>distinct. I did not expect to redefine the old term unless one was >>>>>clearly a refinement of the other, which is not the case. >>>>> >>>>> I still am concerned about the description I think you are proposing >>>>>for this term ("normalized_radar_backscatter_coefficient is also >>>>>called >>>>>the normalized radar cross section, which are commonly used in the >>>>>microwave remote sensing community.") Based on your inputs, here is a >>>>>second attempt: >>>>> >>>>>> The fraction of incident power at a given wavelength that reaches a >>>>>>receiver, after reflection by a surface at a given reflection angle. >>>>>>(In microwave remote sensing this is also known as the 'normalized >>>>>>radar cross section' or 'sigma naught'.) Coordinate values for >>>>>>radiation wavelength and reflection angle should be given the >>>>>>standard >>>>>>names radiation_wavelength and scattering_angle. >>>>> >>>>> This description reflects: always 1 wavelength; always 1 backward >>>>>scattering angle; and that all lost power is included in the >>>>>coefficient, not simply the surface reflectance/absorption. >>>>> >>>>> If I correctly got your 3 points, the term "attenuated" applies, as >>>>>it >>>>>is used elsewhere in CF: "'The attenuated backwards scattering >>>>>function >>>>>includes the effects of two-way attenuation by the medium between a >>>>>radar source and receiver." Since I can't imagine needing an >>>>>unattenuated backscatter coefficient, the extra word seems unneeded >>>>>for >>>>>this name. >>>>> >>>>> John (G) >>>>> >>>>> On Jul 23, 2014, at 10:37, Niedfeldt, John C (398M-Affiliate) >>>>><John.C.Niedfeldt@xxxxxxxxxxxx> wrote: >>>>> >>>>>> Dear John et al, >>>>>> Here are three major distinctions between the >>>>>>surface_backwards_scattering_coefficient_of_radar_wave (old) and >>>>>>normalized_radar_backscatter_coefficient (new): >>>>>> ? The (old) definition has the default definition as being an >>>>>>integral over all wavelengths, but the radar backscatter coefficient >>>>>>is always measured using one wavelength (new) and must always be >>>>>>specified. >>>>>> ? The part about scattering radiation having no loss in energy in >>>>>>the (old) definition is not clear, but in practice and theory energy >>>>>>is always lost once the initial wave is transmitted (indeed, it is in >>>>>>part the loss due to the ground that we are measuring)(new). >>>>>> ? The backscatter in the (old) definition refers to summing all >>>>>>backwards scattering angles, where in remote sensing we look at just >>>>>>one backscatter angle (new). >>>>>> And yes, if the old variable pertains to the normalized radar cross >>>>>>section--which I believe it does not--then the transmitted wavelength >>>>>>and backscatter angle (elevation angle) should be required as they >>>>>>are >>>>>>essential to understanding the product and being able to correlate >>>>>>and >>>>>>verify data. >>>>>> >>>>>> So yes, we could change the old definition to meet the new needs, >>>>>>but >>>>>>it would require a change in base assumptions that would render any >>>>>>current data using that standard name as invalid. For these reasons >>>>>>and more, I believe we should make a new standard name. The >>>>>>definition >>>>>>I have provided is accurate and once approved additional attributes >>>>>>and values can be made required to suit all needs for those dealing >>>>>>with the normalized radar backscatter coefficient. >>>>>> >>>>>> Sincerely, >>>>>> John >>>>>> >>>>>> -- >>>>>> John Niedfeldt >>>>>> Data Engineering >>>>>> PO.DAAC, JPL >>>>>> >>>>>> From: John Graybeal <john.graybeal@xxxxxxxxxxxxxxxx> >>>>>> Date: Tuesday, July 22, 2014 at 3:53 PM >>>>>> To: JPL <John.C.Niedfeldt@xxxxxxxxxxxx> >>>>>> Cc: CF Metadata List <cf-metadata@xxxxxxxxxxxx>, "Moroni, David F >>>>>>(398M)" <David.F.Moroni@xxxxxxxxxxxx> >>>>>> Subject: Re: [CF-metadata] normalized_radar_backscatter_coefficient >>>>>> >>>>>> John, I think we (I, anyway) were waiting for a little more >>>>>>clarification as to what was needed. Sorry for that delay. I like >>>>>>the >>>>>>name itself, makes sense to me. >>>>>> >>>>>> Unless I am mistaken, from your email I infer that the meaning of >>>>>>this is a narrow case of >>>>>>surface_backwards_scattering_coefficient_of_radar_wave. That >>>>>>description is: >>>>>>> The scattering/absorption/attenuation coefficient is assumed to be >>>>>>>an integral over all wavelengths, unless a coordinate of >>>>>>>radiation_wavelength is included to specify the wavelength. >>>>>>>Scattering of radiation is its deflection from its incident path >>>>>>>without loss of energy. Backwards scattering refers to the sum of >>>>>>>scattering into all backward angles i.e. scattering_angle exceeding >>>>>>>pi/2 radians. Ascattering_angle should not be specified with this >>>>>>>quantity. >>>>>> >>>>>> I can't tell from the description if this item is different, so the >>>>>>description could use a little bit more meat to tease that out. >>>>>>Looking at your thread, I see this: >>>>>> >>>>>>> we are calculating sigma_naught which is the fraction of incident >>>>>>>power that is reflected by the surface. It is also very important in >>>>>>>scatterometry to record the angle of incidence as the sigma_naught >>>>>>>changes based on the incidence angle in addition to various other >>>>>>>parameters which are essential to being able to correlate data from >>>>>>>various scatterometers. >>>>>> >>>>>> So does it work for the description could say something like the >>>>>>following? This is still similar to the other standard name, so if >>>>>>there are specific things that make the distinction clear that would >>>>>>be important to add. ("This differs from surface_backwards_...") >>>>>> >>>>>>> The fraction of incident power that is reflected by the surface. >>>>>>>(In >>>>>>>microwave remote sensing this is also known as the 'normalized >>>>>>>radar >>>>>>>cross section' or 'sigma naught', when produced from one angle of >>>>>>>incidence and from one wavelength.) Scattering of radiation is its >>>>>>>deflection from its incident path without loss of energy. Backwards >>>>>>>scattering refers to the sum of scattering into all backward angles >>>>>>>i.e. scattering_angle exceeding pi/2 radians. A scattering_angle >>>>>>>should not be specified with this quantity. Coordinates of >>>>>>>radiation_wavelength and angle_of_incidence are used to specify >>>>>>>those >>>>>>>baseline parameters. >>>>>> >>>>>> I'm not sure about the last part -- if they are always needed these >>>>>>variables should be required. >>>>>> >>>>>> John >>>>>> >>>>>> >>>>>> >>>>>> On Jul 22, 2014, at 14:49, Niedfeldt, John C (398M-Affiliate) >>>>>><John.C.Niedfeldt@xxxxxxxxxxxx> wrote: >>>>>> >>>>>>> Dear all, >>>>>>> Hello again! About two months back I sent in a request, which is >>>>>>>referenced below, in which I requested that we add the >>>>>>>Onormalized_radar_backscatter_coefficient¹ in CF. Having heard >>>>>>>nothing to the contrary, and seeing as no other standards name match >>>>>>>our needs, we at PO.DAAC will be moving forward in implementing this >>>>>>>new standard name. >>>>>>> >>>>>>> As our newly reprocessed netCDF datasets shall soon serve as an >>>>>>>online replacement for existing datasets already in use by hundreds >>>>>>>of interdisciplinary scatterometry data users, we hope to likewise >>>>>>>hear back from you soon as to whether there is consensus on our >>>>>>>proposed standard name. If there is anything further we can do to >>>>>>>build community consensus on our proposed standard name, please let >>>>>>>me know. >>>>>>> >>>>>>> Sincerely, >>>>>>> John >>>>>>> >>>>>>> -- >>>>>>> John Niedfeldt >>>>>>> Data Engineering >>>>>>> PO.DAAC, JPL >>>>>>> >>>>>>> From: Lauret Olivier <olauret@xxxxxx> >>>>>>> Date: Friday, May 30, 2014 at 8:11 AM >>>>>>> To: "cf-metadata@xxxxxxxxxxxx" <cf-metadata@xxxxxxxxxxxx> >>>>>>> Cc: JPL <John.C.Niedfeldt@xxxxxxxxxxxx> >>>>>>> Subject: TR: normalized_radar_backscatter_coefficient >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Just forwarding you some discussion we have with J. Niedfeldt about >>>>>>>some standard name for sigma naught variable. I thought the >>>>>>>available >>>>>>>³surface_backwards_scattering_coefficient_of_radar_wave² could be >>>>>>>used considering some changes in the definition [in short I wish we >>>>>>>could mix the description of sigma naught from radar altimetry with >>>>>>>the one from scatterometers]. But it seems that the quantities are >>>>>>>different enough to introduce a new standard name (see the message >>>>>>>below). >>>>>>> >>>>>>> Can we introduce Onormalized_radar_backscatter_coefficient¹ in CF? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Olivier >>>>>>> >>>>>>> De : Niedfeldt, John C (398M-Affiliate) >>>>>>>[mailto:John.C.Niedfeldt@xxxxxxxxxxxx] >>>>>>> Envoyé : jeudi 29 mai 2014 21:26 >>>>>>> À : Lauret Olivier >>>>>>> Objet : normalized_radar_backscatter_coefficient >>>>>>> >>>>>>> Dear Mr. Olivier, >>>>>>> After discussion with Dr. David Long of BYU and reviewing the >>>>>>>current definition with him it was determined that we do in fact >>>>>>>need >>>>>>>a new variable. In microwave remote sensing the normalized radar >>>>>>>cross section, sigma naught, is always produced from one angle of >>>>>>>incidence and from one wavelength. I understand the desire to >>>>>>>consolidate the number of standard names and to not have >>>>>>>duplication, >>>>>>>but adding this standard name would reduce confusion and error for >>>>>>>many I believe. It is also general enough that we can add attributes >>>>>>>to it in the future to allow further specification for various >>>>>>>endeavors. If you have any more questions feel free to contact me >>>>>>>and >>>>>>>thank you again for your assistance. We changed the standard_name to >>>>>>>be more descriptive. >>>>>>> >>>>>>> standard_name: >>>>>>> normalized_radar_backscatter_coefficient >>>>>>> >>>>>>> Definition: >>>>>>> normalized_radar_backscatter_coefficient is also called the >>>>>>>normalized radar cross section, which are commonly used in the >>>>>>>microwave remote sensing community. >>>>>>> >>>>>>> Canonical Units: >>>>>>> 1 >>>>>>> >>>>>>> >>>>>>> Sincerely, >>>>>>> John Niedfeldt >>>>>>> >>>>>>> >>>>>>> Cliquez ici si ce message est indésirable (pourriel). >>>>>>> >>>>>>> _______________________________________________ >>>>>>> CF-metadata mailing list >>>>>>> CF-metadata@xxxxxxxxxxxx >>>>>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >>>>>> >>>>>> _______________________________________________ >>>>>> CF-metadata mailing list >>>>>> CF-metadata@xxxxxxxxxxxx >>>>>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >>>>> >>> >> > >_______________________________________________ >cf-satellite mailing list >cf-satellite@xxxxxxxxxxxxxxxx >For list information or to unsubscribe, visit: >http://www.unidata.ucar.edu/mailing_lists/ _______________________________________________ cf-satellite mailing list cf-satellite@xxxxxxxxxxxxxxxx For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
Attachment:
Attachment 1
Description: Binary data
cf-satellite archives: