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
