Re: [CF-metadata] GOES-R generated binary mask products under proposal

Hi.That sounds like a great approach. That way it allows the freedom to specify a threshold or not.Grace and peace,Jim Jim BiardResearch ScholarCooperative Institute for Climate and SatellitesRemote Sensing and Applications DivisionNational Climatic Data Center151 Patton Ave, Asheville, NC

Re: [CF-metadata] new standard name: lifted_index

Hello Jonathan, I still think the standard names for the stability indices are a bit of a conundrum, but I do understand the desire to attempt to devise a general sounding name for each product. I believe that most physical quantities are general enough to easily fit into the CF standard

Re: [CF-metadata] new standard name: lifted_index

Dear Jonathan Thanks for your thoughts. Actually I agree with you. I would not try to insist on a geophysical name in every case. It might be too contrived and it would not be helpful if there was very little chance that the generality would ever be useful. I prefer geophysically orientated

[CF-metadata] a cell measures questions

Folks: we have a fire product represented as a set of variables storing gridded data at a particular horizontal spatial resolution. The product is composed of several data variables: (1) a fire code value, (2) temperature of the fire within the cells where fires exist, (3) radiative power

Re: [CF-metadata] new standard name: lifted_index

Hi Jonathan, Thanks a lot for the background on the CF conventions. This helps me quite a bit to understand the ideas behind the process. Yes, you are right about the surface question. The GOES-R product is not referenced to a standard 'surface temperature' quantity, but just the surface,

Re: [CF-metadata] new standard name: total_totals_index

Dear Jonathan, Thanks for your feedback. I agree with your suggested modifications the definition and have included them below. Also, there is an e-mail from John Graybeal who is suggesting a more generalized version of the standard name. I have thought about attempting to come up with a

[CF-metadata] use of _FillValue vs valid_range, and minimum and maximum variable attributes

Folks- I have a two-parter for your consideration today. Is there a recommended best practice for use of _FillValue and/or valid_range variable attributes? At one point, I think there was a performance cost if valid_range was supplied, and I would like to avoid that, if it's still an issue.

Re: [CF-metadata] use of _FillValue vs valid_range, and minimum and maximum variable attributes

Hi Ellyn, According to CF Trac Ticket #31 (slated for inclusion in the update to CF 1.7), the way to cache minimum maximum values in metadata is to use an attribute named actual_range and store them as a pair. (I kind of think this is a bad idea, and wish that ticket was still open. I missed