Hi Alison, Looks good to me.
Perhaps Martin can weigh in on whether or not the phrase "or any other dimensionless representation of a fraction" is needed. Are there any such entities? best regards, Karl On 2/11/19 11:14 AM, Alison Pamment - UKRI STFC wrote: > Dear Karl, > > I like that definition - it gives a clear explanation of the purpose of the > name as well as the acceptable ways of expressing the fraction. > > We should also retain the existing text about the use of area_type or more > specific X_area_fraction names to specify *which* area is being quantified. > So then we'd have: > ' "Area fraction" is the fraction of a grid cell's horizontal area that has > some characteristic of interest. It is evaluated as the area of interest > divided by the grid cell area. It may be expressed as a fraction, a > percentage, or any other dimensionless representation of a fraction. To > specify which area is quantified by a variable with standard name > area_fraction, provide a coordinate variable or scalar coordinate variable > with standard name area_type. Alternatively, if one is defined, use a more > specific standard name of X_area_fraction for the fraction of horizontal area > occupied by X. ' > > (Out of curiosity I tried entering k% into UDunits. Not too surprisingly it > responded with "Don't recognize " k%" "). > > Best wishes, > Alison > > ------ > Alison Pamment Tel: +44 1235 778065 > NCAS/Centre for Environmental Data Archival Email: > [email protected] > STFC Rutherford Appleton Laboratory > R25, 2.22 > Harwell Oxford, Didcot, OX11 0QX, U.K. > > > -----Original Message----- > From: CF-metadata <[email protected]> On Behalf Of Taylor, > Karl E. > Sent: 07 February 2019 17:24 > To: [email protected] > Subject: Re: [CF-metadata] Putting the units in a CF standard name: > area_fraction > > HI Martin and all, > > I agree that the best option is to modify the text. In that regard, I > stumbled over the word "proportional" ... proportional to what? Also, only > udunits experts will recognize that "1" has a specific meaning when appearing > as a unit, so "conforms to 1" might be unclear. Would something like the > following be better? > > "Area Fraction" is the fraction of a grid cell's horizontal area that has > some characteristic of interest. It is evaluated as the area of interest > divided by the grid cell area. It may be expressed as a fraction, a > percentage, or any other dimensionless representation of a fraction." > > By the way, off hand I can't think of "other dimensionless representations of > a fraction" Is kilo-percent (k%) legal? > > regards, > Karl > > On 2/7/19 8:57 AM, Martin Juckes - UKRI STFC wrote: >> Dear Jonathan, >> >> Thanks, that justification will be helpful in replying to people. >> >> To summarise, the proposal (now backed by Jonathan and John -- after >> dropping the idea of changing the standard name) is that the current text >> '"Area fraction" means the fraction of horizontal area.' in the description >> of the standard name "area_fraction" should be replaced with the following: >> "Area Fraction" is a dimensionless number representing a relative or >> proportional area. It may be expressed as a fraction, percentage or any >> other unit that conforms to "1". It is evaluated as the area of interest >> divided by the grid cell area, scaled for the units chosen. >> >> regards, >> Martin >> >> ________________________________ >> From: CF-metadata <[email protected]> on behalf of >> Jonathan Gregory <[email protected]> >> Sent: 06 February 2019 21:23 >> To: [email protected] >> Subject: [CF-metadata] Putting the units in a CF standard name: >> area_fraction >> >> Dear Martin >> >> I would say yes, that the use of "fraction" in area_fraction is for >> consistency with all the other uses of "fraction" in standard names >> (mass, mole, time and volume). In addition I would say that "cover" >> would be a confusing word to use, because "land cover" often means >> "land surface type". Finally, I would say to experts who are offended >> that in this case, as in plenty of others where CF has not quite >> followed familiar terminology in the domain, there is no implication >> that anyone thinks they are "wrong" in their terminology. It's just >> that CF is used across a wide range of disciplines and as far as possible >> all of it has to be consistent and intelligible to everyone. >> >> Best wishes >> >> Jonathan >> >> >> ----- Forwarded message from Martin Juckes - UKRI STFC >> <[email protected]> ----- >> >>> Date: Wed, 6 Feb 2019 12:16:06 +0000 >>> From: Martin Juckes - UKRI STFC <[email protected]> >>> To: John Graybeal <[email protected]>, Jim Biard >>> <[email protected]> >>> Cc: "[email protected]" <[email protected]> >>> Subject: Re: [CF-metadata] Putting the units in a CF standard name: >>> area_fraction >>> >>> Hello John, others, >>> >>> >>> Thanks for those comments. I can see the value of maintaining consistency >>> and being careful about changing things which have worked well for a long >>> time, but I would rather not go back to the people who find the existing >>> terminology confusing (these are people who have specifically commented on >>> the standard name area_fraction) and tell them that we are not changing it >>> because it has always been like that. I'd rather have a more positive >>> message that might encourage them to appreciate the value of CF. >>> >>> >>> I'm not sure if this is true, but it looks to me as though the formulation >>> "area_fraction" owes something to "volume_fraction", "mass_fraction" and >>> "mole_fraction", all of which follow wide spread usage in the atmospheric >>> and oceanographic science communities. People who use mass and volume >>> fractions appear to be accustomed to having these expressed as percentages >>> outside CF, so it is no surprise to find this done in CF. For >>> "area_fraction" we have a slightly different situation: the term doesn't >>> arise from expressions used in the land surface science communities, rather >>> it is a semantic structure being imposed on them. Does anyone now if this >>> interpretation is correct (i.e. that we use "area_fraction" rather than >>> something which might be more familiar for land surface scientists such as >>> "area_cover" in order to maintain consistency with mass, volume and mole >>> fractions)? >>> >>> >>> regards, >>> >>> Martin >>> >>> >>> >>> ________________________________ >>> From: CF-metadata <[email protected]> on behalf of >>> John Graybeal <[email protected]> >>> Sent: 01 February 2019 07:12 >>> To: Jim Biard >>> Cc: [email protected] >>> Subject: Re: [CF-metadata] Putting the units in a CF standard name: >>> area_fraction >>> >>> Martin, >>> >>> I like your definition. >>> >>> While there is a case for renaming the standard name, it's long-time use, >>> validity, and the fact only sophisticated data managers use standard names >>> (and most data users just look primarily at variable names) says to me we >>> should keep the existing standard names with fraction. >>> >>> John >>> >>> On Jan 31, 2019, at 08:07, Jim Biard >>> <[email protected]<mailto:[email protected]>> wrote: >>> >>> >>> Hi. >>> >>> I understand that concern, but it has always been true that the units for a >>> quantity identified by a standard name only has to be convertible using >>> UDUNITS from the canonical units specified in the definition for that >>> standard name. So percent is, by definition, valid for a quantity with >>> units of '1'. As you can see below: >>> >>>> udunits2 >>> You have: 1 >>> You want: percent >>> 1 = 100 percent >>> x/percent = 100*(x/) >>> >>> I guess I don't see the need for guidance here. >>> >>> Grace and peace, >>> >>> Jim >>> >>> On 1/31/19 10:51 AM, Martin Juckes - UKRI STFC wrote: >>> >>> Dear Jonathan, >>> >>> >>> we could certainly take that approach, though the definitions are not >>> always accessible to people looking at the standard name, so they do not >>> compensate for ambiguity in the name itself. >>> >>> >>> The current text '"Area fraction" means the fraction of horizontal >>> area.' could be replaced with >>> >>> >>> "Area Fraction" is a dimensionless number representing a relative or >>> proportional area. It may be expressed as a fraction, percentage or any >>> other unit that conforms to "1". It is evaluated as the area of interest >>> divided by the grid cell area, scaled for the units chosen. >>> >>> >>> I still feel that there is a case for changing the name to, for >>> example, "relative_area" in order to reduce confusion caused by >>> people who assume that a fraction is a quantity that does not have >>> units, >>> >>> >>> regards, >>> >>> Martin >>> >>> >>> >>> >>> ________________________________ >>> From: CF-metadata >>> <[email protected]><mailto:[email protected] >>> r.edu> on behalf of Jonathan Gregory >>> <[email protected]><mailto:[email protected]> >>> Sent: 31 January 2019 13:20:24 >>> To: [email protected]<mailto:[email protected]> >>> Subject: [CF-metadata] Putting the units in a CF standard name: >>> area_fraction >>> >>> Dear Martin >>> >>> I'd rather we retained "fraction" in the standard name, because it's >>> always been there, it's used in other contexts in a consistent way, >>> and there isn't anything actually incorrect with it, as you say. >>> Could we instead add a note to the definitions pointing out that percent is >>> acceptable as a unit for them? >>> >>> Best wishes >>> >>> Jonathan >>> >>> ----- Forwarded message from Martin Juckes - UKRI STFC >>> <[email protected]><mailto:[email protected]> ----- >>> >>> >>> >>> Date: Wed, 30 Jan 2019 22:40:12 +0000 >>> From: Martin Juckes - UKRI STFC >>> <[email protected]><mailto:[email protected]> >>> To: Steven Emmerson <[email protected]><mailto:[email protected]> >>> Cc: "CF-metadata >>> ([email protected]<mailto:[email protected]>)" >>> <[email protected]><mailto:[email protected]> >>> Subject: Re: [CF-metadata] Putting the units in a CF standard name: >>> area_fraction >>> >>> Hi Steve, >>> >>> >>> The issue is more that CF allows more freedom in the choice of units than >>> many people expect from a "fraction". >>> >>> >>> A second problem, I think the problem is that I didn't explain the issue >>> clearly. In the CMIP data request we are specifying that variables with >>> standard name "area_fraction" should be given as percentages. This is >>> allowed by the CF convention: an "area_fraction" can be 0.5 or 50%. The >>> reason that percentages are being used is because "area_fraction" is being >>> used like the proportion of land covered in grass, and people are used to >>> having these as percentages rather than fractions. It is all perfectly >>> correct as far as the convention goes, but people often interpret the use >>> of "area_fraction" for a percentage as an error. >>> >>> >>> Given that we have the framework of allowing flexibility in the choice of >>> units, I feel it would be better to avoid having the term "fraction" in the >>> standard name, given that it is often interpreted as implying a specific >>> choice for the units. >>> >>> >>> regards, >>> >>> Martin >>> >>> >>> ________________________________ >>> From: Steven Emmerson <[email protected]><mailto:[email protected]> >>> Sent: 30 January 2019 21:37 >>> To: Juckes, Martin (STFC,RAL,RALSP) >>> Cc: CF-metadata >>> ([email protected]<mailto:[email protected]>) >>> Subject: Re: [CF-metadata] Putting the units in a CF standard name: >>> area_fraction >>> >>> On Wed, Jan 30, 2019 at 12:54 PM Martin Juckes - UKRI STFC >>> <[email protected]<mailto:[email protected]><mailto:[email protected]><mailto:[email protected]>> >>> wrote: >>> >>> I'm afraid I don't understand your comment. When I search for "fraction" in >>> the NIST document I find it defined as being a ratio, which is inconsistent >>> with the current CF usage. The CF standard name concept "area_fraction" is >>> not what NIST or others understand as a "fraction". I'm suggesting a change >>> to remove this inconsistency. >>> >>> Unless we're talking past one another, I'll have to disagree. The NIST >>> unit for "mass fraction" is "1" -- even though it's a ratio. A fraction can >>> be represented many ways. "1:2", "1/2", and "0.5" all represent the same >>> fraction, for example. >>> >>> Does the CF convention require a particular representation for a fraction? >>> >>> Regards, >>> Steve Emmerson >>> _______________________________________________ >>> CF-metadata mailing list >>> [email protected]<mailto:[email protected]> >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >>> >>> >>> ----- End forwarded message ----- >>> _______________________________________________ >>> CF-metadata mailing list >>> [email protected]<mailto:[email protected]> >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >>> _______________________________________________ >>> CF-metadata mailing list >>> [email protected]<mailto:[email protected]> >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >>> >>> >>> -- >>> [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: [email protected]<mailto:[email protected]> >>> 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>. >>> >>> _______________________________________________ >>> CF-metadata mailing list >>> [email protected]<mailto:[email protected]> >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >>> _______________________________________________ >>> CF-metadata mailing list >>> [email protected] >>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> ----- End forwarded message ----- >> _______________________________________________ >> CF-metadata mailing list >> [email protected] >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> _______________________________________________ >> CF-metadata mailing list >> [email protected] >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > _______________________________________________ > CF-metadata mailing list > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > _______________________________________________ > CF-metadata mailing list > [email protected] > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
