Dear Michael,
Thank you for your reply - I will update the definition of the existing name as discussed. I am just about to start the standard name table update and this change will be included.
Hopefully we can finalise the remaining six GOES-R names in time for the next update which will take place in September.
Best wishes,
Alison
------
Alison Pamment Tel: +44 1235 778065
Centre for Environmental Data Analysis Email: alison.pamment at stfc.ac.uk<mailto:J.A.Pamment at rl.ac.uk>
STFC Rutherford Appleton Laboratory
R25, 2.22
Harwell Oxford, Didcot, OX11 0QX, U.K.
From: CF-metadata [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Carlomusto, Michael
Sent: 07 July 2015 16:45
To: cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] new standard_name needed for cloud_phase (an enumeration type) - GOES-R
On 7 July 2015 - Reply by Mike Carlomusto:
Alison,
I agree with your assessment - the proposed standard name "cloud_phase_category" and the existing standard name thermodynamic_phase_of_cloud_water_particles_at_cloud_top are redundant.
Your proposed addition of three values - clear_sky, super_cooled_liquid_water and unknown - to thermodynamic_phase_of_cloud_water_particles_at_cloud_top is an excellent solution and acceptable for the GOES-R Cloud Top Phase product.
Mike
On 3 July 2015 Alison Pamment wrote:
> Thread "new standard_name needed for cloud_phase (an enumeration
> type)"
> (http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/056424.html)
>
> Current status: Under discussion.
> cloud_phase_category (canonical units: 1) 'Cloud phase category is a
> string, taking one of the following standardised values: clear_sky,
> liquid_water, super_cooled_liquid_water, mixed_phase, ice, unknown.
> For a data variable it is encoded as an integer using flag_values and flag_meanings.'
>
> This name received some brief discussion on the mailing list and was
> agreed at the time. However, I was looking through existing names
> whose definitions also refer to flag_values and flag_meanings because
> I wanted to check that the wording of the proposed definition is
> broadly consistent. In doing so I came across the name
> thermodynamic_phase_of_cloud_water_particles_at_cloud_top, introduced
> into the standard name table at Version 24 (June 2013), for use with
> Meteosat Second Generation (MSG) data. The existing name is defined as
> follows:
> ' "cloud_top" refers to the top of the highest cloud. "Water" means
> water in all phases. A variable with the standard name of
> thermodynamic_phase_of_cloud_water_particles_at_cloud_top contains
> integers which can be translated to strings using flag_values and
> flag_meanings attributes. Alternatively, the data variable may contain
> strings which indicate the thermodynamic phase. These strings are
> standardised. Values must be chosen from the following list: liquid;
> ice; mixed.'
>
> Although the list of standardised values is not the same as proposed
> for GOES-R, I think the existing name is basically the same quantity
> as the one requested. My suggestion is that, instead of adding the new
> name, we expand the definition of the existing name to allow for all
> the strings needed for both MSG and GOES-R data, as follows:
> ' "cloud_top" refers to the top of the highest cloud. "Water" means
> water in all phases. A variable with the standard name of
> thermodynamic_phase_of_cloud_water_particles_at_cloud_top contains
> integers which can be translated to strings using flag_values and
> flag_meanings attributes. Alternatively, the data variable may contain
> strings which indicate the thermodynamic phase. These strings are
> standardised. Values must be chosen from the following list: liquid;
> ice; mixed; clear_sky; super_cooled_liquid_water; unknown.'
>
> The standardised strings for liquid_water and mixed_phase would be
> slightly different from those agreed in the discussion of the current
> proposal, but if the names are to be combined I think we would need to
> stick with the earlier strings so as not to invalidate existing MSG data.
> Expanding the list of standardised strings would not affect existing
> data as I don't think there is any requirement to use all possible
> values of flag_values and flag_meanings within a particular data
> variable. One of the reasons for using standard names in CF is to
> avoid accidental duplication of quantities with the same meaning but
> different names, so I think that expanding the existing definition is the right way to go. Do you agree?
Michael Carlomusto
mcarlomu at harris.com<mailto:mcarlomu at harris.com>
Harris Corp.
Government Communications Systems Division (GCSD), GOES-R Ground System
Melbourne, FL, USA
(321) 309-7905
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150708/d051ea35/attachment-0001.html>
Received on Wed Jul 08 2015 - 04:21:37 BST
