2018-11-29T01:38:12Z http://toyoda-eizi.net/2013/cffeed/atom.xml TOYODA Eizi is creating this feed for private purpose. The CF committee has no responsibility. Taylor, Karl E. http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020692.html

Sorry for the misleading title in my recent posting.  The correct title now appears here,  copied from Martin's original posting (spelling error and all). best, Karl

2018-11-29T01:38:12Z Taylor, Karl E. http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020691.html

Dear Alison and all, I support Martin's proposal http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020666.html to add indian_pacific_ocean atlantic_arctic_ocean to the list of standard regions labels. best regards, Karl

2018-11-29T00:47:14Z Lowry, Roy K. http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020690.html

Hi Daniel, These look straightforward to me and would be a useful addition. Cheers, Roy. I have now retired but will continue to be active through an Emeritus Fellowship using this e-mail address. ________________________________ From: CF-metadata <cf-metadata-bounces at cgd.ucar.edu> on behalf of Daniel Neumann <daniel.neumann at io-warnemuende.de> Sent: 22 November 2018 09:08 To: cf-metadata at cgd.ucar.edu Subject: [CF-metadata] New standard names for Dissolved Inorganic Nitrogen and Particulate Organic Nitrogen Dear all, I would like to propose two new standard names: mole_concentration_of_dissolved_inorganic_nitrogen_in_sea_water mole_concentration_of_particulate_organic_nitrogen_in_sea_water A similar standard name for "dissolved inorganic phosphorus" exists already. Moreover, a few tendency/flux standard names exist for "dissolved inorganic nitrogen" and "particulate organic nitrogen". The descriptions and units are given below. Regards, Daniel name: mole_concentr

2018-11-26T05:48:03Z Daniel Neumann http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020689.html

Dear all, I would like to propose two new standard names: mole_concentration_of_dissolved_inorganic_nitrogen_in_sea_water mole_concentration_of_particulate_organic_nitrogen_in_sea_water A similar standard name for "dissolved inorganic phosphorus" exists already. Moreover, a few tendency/flux standard names exist for "dissolved inorganic nitrogen" and "particulate organic nitrogen". The descriptions and units are given below. Regards, Daniel name: mole_concentration_of_dissolved_inorganic_nitrogen_in_sea_water description: Mole concentration means number of moles per unit volume, also called "molarity", and is used in the construction "mole_concentration_of_X_in_Y", where X is a material constituent of Y. A chemical or biological species denoted by X may be described by a single term such as "nitrogen" or a phrase such as "nox_expressed_as_nitrogen". "Dissolved inorganic nitrogen" means the sum of all inorganic nitrogen in solution (including nitrate, ammonia, and nitri

2018-11-22T09:08:02Z Jim Biard http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020688.html

It's all well described in the Conventions doc. -- CICS-NC <http://www.cicsnc.org/> Visit us on Facebook <http://www.facebook.com/cicsnc> *Jim Biard* *Research Scholar* Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/> North Carolina State University <http://ncsu.edu/> NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/> /formerly NOAA’s National Climatic Data Center/ 151 Patton Ave, Asheville, NC 28801 e: jbiard at cicsnc.org <mailto:jbiard at cicsnc.org> o: +1 828 271 4900 /Connect with us on Facebook for climate <https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics <https://www.facebook.com/NOAANCEIoceangeo> information, and follow us on Twitter at @NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and @NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /

2018-11-21T21:52:59Z Martin Juckes - UKRI STFC http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020687.html

Dear Jim, sorry, I stand corrected. Thank you for the detailed explanation. The conformance statements looks to be in error. Is there a clear rule for what makes a valid set of flag_values when used in conjunction with flag_masks? regards, Martin ________________________________ From: Jim Biard <jbiard at cicsnc.org> Sent: 21 November 2018 20:50 To: Juckes, Martin (STFC,RAL,RALSP); cf-metadata at cgd.ucar.edu Subject: Re: [CF-metadata] Multiple zeros in flag_values allowed? Martin, The two subfields are independent. You can have very bad quality data and very bad weather at the same time. And that's how the flag masks and flag values are supposed to work. The mask splits off bit regions that are independent of one another. There is no ambiguity. The possible options and the values masked by the flag masks of 3 (binary 0011) and 12 (binary 1100) are: Weather Quality Binary Value Binary value & 3 Binary value & 12 very bad very bad

2018-11-21T21:40:23Z Jim Biard http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020686.html

Martin, The two subfields are independent. You can have very bad quality data and very bad weather at the same time. And that's how the flag masks and flag values are supposed to work. The mask splits off bit regions that are independent of one another. There is no ambiguity. The possible options and the values masked by the flag masks of 3 (binary 0011) and 12 (binary 1100) are: Weather Quality Binary Value Binary value & 3 Binary value & 12 very bad very bad 0000 0 0 very bad bad 0001 1 0 very bad good 0010 2 0 very bad very good 0011 3 0 bad very bad 0100 0 4 bad bad 0101 1 4 bad good 0110 2 4 bad very good 0111 3 4 good very bad 1000 0 8 good bad 1001 1 8 good good 1010 2 8 good very good 1011 3 8 very good very bad 1100 0 12 very good bad 1101 1 12 very good good 1110 2 12 very good very good 1111 3 12 Grace and peace, Jim -- CICS-NC <http://www.cicsnc.org/> Visit us on Facebook <http://www.facebook.com

2018-11-21T20:50:42Z Martin Juckes - UKRI STFC http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020685.html

Hello Jim, Julien, I'm not sure .. I think the conformance might be right here and your flag_values should be 0,1,2,3, 4, 8,12,16, and flag_masks 3,3,3,3,28,28,28,28 If, for instance, you very_bad_quality and very_bad_weather, then "var" should have value 4 = '00100000` in binary. Masked with 3 (11000000) gives zero, and masked with 28 (00111000) gives 4. Re-using the zero value would make zero ambiguous, so you need to start the 2nd sequence at 4. regards, Martin ________________________________ From: CF-metadata <cf-metadata-bounces at cgd.ucar.edu> on behalf of Jim Biard <jbiard at cicsnc.org> Sent: 20 November 2018 16:51:24 To: cf-metadata at cgd.ucar.edu Subject: Re: [CF-metadata] Multiple zeros in flag_values allowed? Julien, That's fine. The conformance document probably needs a better statement of the requirement when flag masks are used. Grace and peace, Jim Hi, We want to define a flags variable defining like that: var:flag_masks = 3, 3, 3, 3, 12, 12, 12, 12 ;

2018-11-21T17:03:29Z Jim Biard http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020684.html

Julien, That's fine. The conformance document probably needs a better statement of the requirement when flag masks are used. Grace and peace, Jim -- CICS-NC <http://www.cicsnc.org/> Visit us on Facebook <http://www.facebook.com/cicsnc> *Jim Biard* *Research Scholar* Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/> North Carolina State University <http://ncsu.edu/> NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/> /formerly NOAA’s National Climatic Data Center/ 151 Patton Ave, Asheville, NC 28801 e: jbiard at cicsnc.org <mailto:jbiard at cicsnc.org> o: +1 828 271 4900 /Connect with us on Facebook for climate <https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics <https://www.facebook.com/NOAANCEIoceangeo> information, and follow us on Twitter at @NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and @NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /

2018-11-20T16:51:24Z Julien Demaria http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020683.html

Hi, We want to define a flags variable defining like that: var:flag_masks = 3, 3, 3, 3, 12, 12, 12, 12 ; var:flag_values = 0, 1, 2, 3, 0, 4, 8, 12 ; var:flag_meanings = "very_bad_quality bad_quality good_quality very_good_quality very_bad_weather bad_weather good_weather very_good_weather" ; I understand from http://cfconventions.org/Conformance/conformance.html that it is not allowed to use several time the same value (here zero) in flag_values: Requirements: * The flag_values attribute values must be mutually exclusive among the set of flag_values attribute values defined for that variable. So it means that for each new "bits combination" in the flags definition we lost one of the combination because we cannot use zero more than one time? Do you confirm this? What is the reason? Thanks in advance, Julien

2018-11-20T16:40:00Z Martin Juckes - UKRI STFC http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020682.html

Sorry, this should have been a request for new standard region labels, not area types. The new regions needed are: For continuity with CMIP5 the following names would be preferred: * indian_pacific_ocean * atlantic_arctic_ocean regards, Martin ________________________________ From: Juckes, Martin (STFC,RAL,RALSP) Sent: 05 November 2018 12:02 To: CF-metadata (cf-metadata at cgd.ucar.edu) Cc: Karl Taylor Subject: Addictional area types needed for CMIP6 Hello All, the CMIP6 data request requires some data to be provided for areas of combined ocean basins: (1) Indian + Pacific, and (2) Atlantic + Arctic. For continuity with CMIP5 the following names would be preferred: * indian_pacific_ocean * atlantic_arctic_ocean Can we add these area types, and are the above names appropriate? regards, Martin

2018-11-20T16:06:30Z Ranjini Swaminathan http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020681.html

Dear All, I'd like to request an addition to the standard name list for the variable solar-induced chlorophyll fluorescence. This variable is derived from satellite measurements and is available as a product from GOSAT and OCO-2 satellite missions at this time. Here is relevant information regarding this variable : Thanks! -Ranjini

2018-11-14T09:12:51Z Martin Juckes - UKRI STFC http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020680.html

Dear David, John, thanks for those comments. Just to re-iterate, the current UDUNITS library does not include "dB", but it does include "dBZ" and some other variations which are decibels with a fixed specified reference value. The 2014 UDUNITS discussion which John links to is interesting. It appears to have covered the ground we have covered below, and Sean Arms has just re-started the discussion there with a link to this thread (thanks Sean). The latest proposal appears to be that a generic `dB` unit could be introduced with the reference level be specified in an additional attribute (yet to be defined). The 2nd link from John is a discussion about the R package wrapper for UDUNITS, which does appear to have support for "dB" added, but simply defined in terms of the logarithm of a dimensionless number. This looks like a neat programmers solution which avoids having to worry about what the physical parameter is. I've looked into this a bit further, and found that "bel" and

2018-11-13T14:03:40Z Moroni, David F (398G) http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020679.html

John and others interested, I was part of the initial request that dated back to 2014. Here’s the original GitHub ticket (still open) capturing the correspondence with the UDUNITS team: https://github.com/Unidata/UDUNITS-2/issues/33 I was corresponding with “mhidas” and “semmerson”, so I don’t know if these people are still on this project, as no further correspondence has taken place since July 2015. I made another attempt last year to bring some life to this request, but to no avail. There was another user inquiring about representing dB as a unit, but that ticket has since closed and it’s not clear to me from the thread whether there was a positive resolution. Here’s that link: https://github.com/r-quantities/units/issues/176 Others on here are more than welcome to pursue this further. Cheers, David From: CF-metadata <cf-metadata-bounces at cgd.ucar.edu> on behalf of John Graybeal <jbgraybeal at mindspring.com> Date: Sunday, November 11, 2018 at 9:33 PM To: Jonathan Gregory <j

2018-11-12T06:24:26Z John Graybeal http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020678.html

Just as an aside (or maybe not), the udunits support list has been asked before to include dB, and I understood that they had (I think I actually saw it, but can’t find written confirmation). So it wouldn’t surprise me if the library included dB. In case it’s useful I pasted in a bit of the old thread below. john An HTML attachment was scrubbed... URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20181111/aa9fb464/attachment-0001.html>

2018-11-12T05:32:46Z Painter, Jeff http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020677.html

I've temporarily broken the connection from github to cf-metadata at listserv.llnl.gov. When we have something like a consensus on how to organize the system, I'll do whatever is appropriate and possible. On 11/9/18, 2:35 AM, "owner-cf-metadata at listserv.llnl.gov on behalf of Martin Juckes - UKRI STFC" <owner-cf-metadata at listserv.llnl.gov on behalf of martin.juckes at stfc.ac.uk> wrote: Dear Chris, All, yes, advising people to resign from cf-metadata to avoid messages from github is a bit over the top. As an interim, I believe that the cf-metadata administrator could bar github from sending messages to this list (mailman offers this option on the admin page) until we have worked out how it should work. regards, Martin ________________________________ From: CF-metadata <cf-metadata-bounces at cgd.ucar.edu> on behalf of Chris Barker <chris.barker at noaa.gov> Sent: 08 November 2018 23:04 To: CF Conv

2018-11-09T20:27:24Z Martin Juckes - UKRI STFC http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020676.html

Dear Chris, All, yes, advising people to resign from cf-metadata to avoid messages from github is a bit over the top. As an interim, I believe that the cf-metadata administrator could bar github from sending messages to this list (mailman offers this option on the admin page) until we have worked out how it should work. regards, Martin ________________________________ From: CF-metadata <cf-metadata-bounces at cgd.ucar.edu> on behalf of Chris Barker <chris.barker at noaa.gov> Sent: 08 November 2018 23:04 To: CF Conventions mailing list; cf-metadata at cgd.ucar.edu Subject: Re: [CF-metadata] Turning off gitHub!!!! By the way, if we DO use a mailing list for a gitHub/TRAC bridge, could we please gve it a name other than: cf-metadata It's really confusing to figure out which one I should mail to. How about cf-metadata-github-bridge or something? -CHB Apparently the gitHub mirroring is really driving folks crazy -- we really need to turn it off until it's done properly. Act

2018-11-09T10:34:46Z Micah Wengren http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020675.html

CF-aficionados, I subscribed to this list awhile ago and read the occasional emails that relate to the standards.  I can definitely appreciate the passion in this community! However, I don't think forwarding all GitHub issue traffic to a mailing list is a good idea, especially when by accident if someone can respond to such a notification by email, cc the GitHub-subscribed list in their email and thereby trick GitHub into assuming the list itself had responded, rather than the list subscriber (who presumably does not have a GitHub account or was replying with an email address GitHub didn't recognize). This was suggested already, but to reiterate: whoever knows the 'cf-metadata-list' GitHub account password, just log in and check the 'unsubscribe' button on this issue and spare us the spam. Or, if the list GitHub account owner isn't out there - or on vacation perhaps - a second option is just to take mercy on us all and close this particular issue, move on to a new, fres

2018-11-09T02:06:27Z Chris Barker http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020674.html

Could someone update the text on the Mailman list? http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov

2018-11-09T00:23:10Z Painter, Jeff http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020673.html

It didn’t work because llnl.gov mailing lists haven’t been on Majordomo for a few years. Try emailing listserv.llnl.gov with message body UNSUBSCRIBE cf-metadata If that doesn’t work, or you just don’t want to do it that way, email me and I’ll take you off. For you, Jared, do nothing – I’ll get you off it in the next five minutes. - Jeff Painter From: <owner-cf-metadata at listserv.llnl.gov> on behalf of Jared Lee <jaredlee at ucar.edu> Date: Thursday, November 8, 2018 at 3:15 PM To: "000007cd9545f71a-dmarc-request at listserv.llnl.gov" <000007cd9545f71a-dmarc-request at listserv.llnl.gov> Cc: "cf-metadata at cgd.ucar.edu" <cf-metadata at cgd.ucar.edu>, "cf-metadata at listserv.llnl.gov" <cf-metadata at listserv.llnl.gov> Subject: Re: Getting off the gitHub message train! That did not work. I got this bounce message in response: The following message to <majordomo at lists.llnl.gov<mailto:majordomo at lists.llnl.gov>> was undeliverable. The reason for the problem: 5.1.0 - Unkno

2018-11-08T23:20:17Z Chris Barker http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020672.html

By the way, if we DO use a mailing list for a gitHub/TRAC bridge, could we please gve it a name other than: *cf-metadata* It's really confusing to figure out which one I should mail to. How about cf-metadata-github-bridge or something? -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov

2018-11-08T23:04:45Z Chris Barker http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020671.html

To stop getting messages from the CF gitHub site, you can: send a message to "majordomo at lists.llnl.gov" with "unsubscribe cf-metadata" in the body of your message. -Hope this helps. -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov

2018-11-08T22:53:14Z Chris Barker http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020670.html

Apparently the gitHub mirroring is really driving folks crazy -- we really need to turn it off until it's done properly. Action #1: Who knows the password of the cf-metadata-list gitHub user??? https://github.com/cf-metadata-list That person can go log into gitHub as that user, and stop watching the Issue at hand -- I'm not anyone else can easily do that. Action #2 Maybe turn off the list that's hooked up to gitHub? That would stopp all this 'till we figure it out. Action #3 post here, VERY CLEARLY, how folks can opt out of the gitHub mirroring list. NOTE to CASUAL USERS: I *think* the reason you all are having trouble opting out is that there are TWP cf-metadata lists: One is the usual one, hosted by ucar: http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata The other is hosted by llnl, and handles the gitHub (and TRAC??) email. I *think* everyone that subscribed to the regular list gets aauto-subscribed to the other list. here's a bit of info on that: The discussio

2018-11-08T22:51:54Z Chris Barker http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020669.html

Hi all, Despite the recent problem with gitHub issues getting mirrored here, It seems posting a gitHub issue is not enough to get folks involved :-) And by the way, where ARE we with respect to gitHub vs TRAC at this point ??? This page: http://cfconventions.org/discussion.html Talks about TRAC, and makes no mention of gitHub... Back to the issue: I recently posted an issue on gitHub: https://github.com/cf-convention/cf-conventions/issues/150 With regards to being clear about the workflow for making changes to CF. In particular, I am suggesting that CF adopt an "Enhancement Proposal" (CEP) process for changes that require significant discussion. This would be similar to how the Python language handles it: https://www.python.org/dev/peps/pep-0001/ In short, it is both a process and resulting document -- at this point, CF has a process, but not a document. I think the document is very helpful because: 1) it can help clarity and focus the discussion 2) It preserves the result

2018-11-08T17:52:47Z Martin Juckes - UKRI STFC http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020668.html

Dear Jonathan, Interesting that your version of udunits has bel & decibel ... mine (udunits2 which I installed on Oct. 17th) does not have these (*"udunits2: Don't recognize "bel"* it tells me), but does had dBz, dBW, dBV, dBv and a few others. There is a different udunits unit for every reference level. Do you know which version of udunits you are using? cfunits, on the other hand, which uses the udunits2 library, does have bel and decibel added, and has them equivalent to '1'. The list of changes that cfunits makes relative to udunits is copied below (from the cfunits.Units help text), with changes that are not mentioned in the convention highlighted: | ======================= ====== ============ ============== | Unit name Symbol Definition Status | ======================= ====== ============ ============== | practical_salinity_unit psu 1e-3 New unit | level 1 New unit | sigma_level

2018-11-06T09:55:08Z Jonathan Gregory http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020667.html

Dear Martin Yes, I agree, that's a bit different. The rules file would provide the info. It's a convenient place to put it. I admit that I didn't check the definitions of these standard names! But there are standard names which refer to a value with a default that can be overridden by a coordinate variable or scalar coordinate variable (not an attribute). If there is a use-case for different reference values for any of the dB instances you mention, we should provide for it using that mechanism by amending the definitions of the standard names, I suggest. I find that in my version of udunits, bel and decibel are units, and they are not convertible to dimensionless numbers. I think that's consistent with what you say and I agree it makes sense like that. Best wishes Jonathan

2018-11-05T21:00:25Z Martin Juckes - UKRI STFC http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020666.html

Hello All, the CMIP6 data request requires some data to be provided for areas of combined ocean basins: (1) Indian + Pacific, and (2) Atlantic + Arctic. For continuity with CMIP5 the following names would be preferred: * indian_pacific_ocean * atlantic_arctic_ocean Can we add these area types, and are the above names appropriate? regards, Martin

2018-11-05T12:02:08Z Martin Juckes - UKRI STFC http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020665.html

Dear Jonathan, The discussion of a machine-readable document with details of rules related to specific standard names is here: https://cf-trac.llnl.gov/trac/ticket/153 . It has been quiet for some time. The dB issues could be covered there, as you say. There is a difference in that the rules discussed in ticket 153 are about specifying what needs to be in the data file, so that it is possible to check that file meta-data is as complete as intended by the convention. Your suggestion would entail adding information that would not be in the data file. There are, however, some other issues that need tidying up. You also suggest that alternative reference levels could be specified in an attribute, but that does not appear to be allowed by current standard name definitions, e.g. "Sound intensity is the sound energy per unit time per unit area. Sound intensity level in water is expressed on a logarithmic scale with reference to a sound intensity of 6.7e-19 W m-2. LI = 10 log10(I/I0) where

2018-11-05T09:32:59Z Jonathan Gregory http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020664.html

Dear Alison Thanks for your careful analysis, as always. I prefer clarity to elegance. Therefore I agree with your approach. You suggest I have a couple of thoughts. First, surface snow exists also on sea ice, so I think we need to say land_surface_snow. Second, I'm not sure that the meaning of freshwater_ice is obvious. Land ice (ice sheets and glaciers) is freshwater ice as well. The difference is the method of formation, whether from compaction of snow, or by freezing of surface water (lake, river, flood). What about land_surface_frozen_water? "Land water" is a term (not in standard names) used to refer to any liquid water on the land surface or in the ground. "Frozen water" is used in standard names to refer to ice in the ground. "Land surface frozen water" would combine these words, with "surface" to exclude ground and soil water content. "Surface" could be omitted if these area types are intended to include regions with frozen soil but no ice on the surface. Also I have a cou

2018-11-04T17:07:01Z Jonathan Gregory http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2018/020663.html

Dear Martin Your points are good ones and have been raised before. More than once we have talked about maintaining a CF version of the udunits definition to include dB and sverdrup, or ask udunits to add them (if they're not there). dB is a dimen- sionless unit, equivalent to 1. I suggest that dBZ should be changed to dB, as I don't think we ought to have several of them. I believe that the default reference levels are mostly conventional and stated in the definitions of the standard name, as you say. They can be overridden by supplying a size-one or scalar coordinate variable. You have previously suggested an xml table to contain more information about the definition of standard names, haven't you? It seems to me that an arrangement like that would be the right place to store the default reference levels and scale factor in a machine-readable way. Best wishes Jonathan

2018-11-04T17:03:53Z