Thanks for summing this up so neatly Mark! > We could take the view that the conventions would benefit from the addition > of some text into 3.1 to explicitly make the point about quantities which are > not dimensioned or dimensionless. > We could alternatively defer to udunits as most unit questions do, which > already exhibits this behaviour, and just patch the 'area_type' and any > similar names with erroneous canonical units. > We could also request that udunits be updated with a clearer string for this > case, given the need for it, such as including the term 'no_units' as a valid > udunits term to mean there are no units here: this is not dimensionless, this > is not dimensioned.
Why is the first option exclusive to the others? Seems useful to improve the documentation regardless. So I agree that '1' makes no sense for area_type. I'm wondering if someone can crisply describe what is meant when we (or UDUNITS) say a unit is dimensionless? I'm not entirely sure I get it. In any case, I think '?' is not a definition that is helpful to most users -- it is more like an indication that the string -- the empty string in this case for example -- has not provided a meaningful indication of what the units are. So my ideal solution has CF well aligned with UDUNITS, and a clear concept and definition. Which I think suggests asking UDUNITS for a term 'no_units', defined as "the values do not have units; values are neither dimensioned nor dimensionless." John On Oct 30, 2014, at 11:06, Hedley, Mark <[email protected]> wrote: > > The unit of '1' is generally used to indicate fractions and the like. In > > cases where I am storing a raw binary value, I leave off the units > > attribute, as the 'number' isn't something that should be treated as a > > decimal quantity. > > This is the same behaviour as I was looking to adopt, but CF 3.1 makes this > incorrect, I believe, as a lack of a units attribute is to be interpreted as > a units of '1'. > > I think a clear way to define that a quantity is not dimensioned and is not > dimensionless is required. I would have liked to use the lack of a unit for > this purpose, but this has already been taken, so something else is needed. > > > My preference is that one explicitly puts in the units. For dimensionless, > > "1" or "" is ok for udunits. > > udunits2 treats '1' and '' differently. > > a unit of '1' has a definition of '1' > a unit of '' has a definition of '?' > > The CF conventions description of units (3.1) states that an absence of a > units attribute is deemed to be equivalent to dimensionless, a unit of '1'. > This is the convention, and it has been in force a long time. > > However CF makes no statement that I can find regarding a unit of ''. Thus I > believe we defer back to udunits, which CF states is how units are defined. > Udunits states that a unit of '' is undefined, the quantity is not > dimensioned and is not dimensionless. We could adopt this to use for the > cases in question. > > > area_type is given in the standard_name table as having a unit of 1. It is > > a categorical string-valued quantity. > > On the basis of the discussion, I would suggest that this is an error. If > area_type is a categorical string-valued quantity, it is not dimensionless, > it is not continuous and numerical, it is not a pure number and should not be > treated as such. I think we should fix this. > > We could take the view that the conventions would benefit from the addition > of some text into 3.1 to explicitly make the point about quantities which are > not dimensioned or dimensionless. > We could alternatively defer to udunits as most unit questions do, which > already exhibits this behaviour, and just patch the 'area_type' and any > similar names with erroneous canonical units. > We could also request that udunits be updated with a clearer string for this > case, given the need for it, such as including the term 'no_units' as a valid > udunits term to mean there are no units here: this is not dimensionless, this > is not dimensioned. > I don't mind which route is preferred, I'm happy to put a change together and > pursue it; whichever way seems better to people. > > cheers > mark > > From: CF-metadata [[email protected]] on behalf of Jim Biard > [[email protected]] > Sent: 30 October 2014 16:12 > To: [email protected] > Subject: Re: [CF-metadata] string valued coordinates > > CF says that if the units attribute is missing, then the quantity has no > units. > > The Conventions document, section 3.1 says: > > The units attribute is required for all variables that represent dimensional > quantities (except for boundary variables defined in Section 7.1, “Cell > Boundaries” and climatology variables defined in Section 7.4, “Climatological > Statistics” ). > > and > > Units are not required for dimensionless quantities. A variable with no units > attribute is assumed to be dimensionless. However, a units attribute > specifying a dimensionless unit may optionally be included. The Udunits > package defines a few dimensionless units, such as percent , but is lacking > commonly used units such as ppm (parts per million). This convention does not > support the addition of new dimensionless units that are not udunits > compatible. The conforming unit for quantities that represent fractions, or > parts of a whole, is "1". The conforming unit for parts per million is > "1e-6". Descriptive information about dimensionless quantities, such as > sea-ice concentration, cloud fraction, probability, etc., should be given in > the long_name or standard_name attributes (see below) rather than the units. > > The unit of '1' is generally used to indicate fractions and the like. In > cases where I am storing a raw binary value, I leave off the units attribute, > as the 'number' isn't something that should be treated as a decimal quantity. > > Grace and peace, > > Jim > > On 10/30/14, 11:35 AM, John Caron wrote: >> My preference is that one explicitly puts in the units. For dimensionless, >> "1" or "" is ok for udunits. If the units attribute isnt there, I assume >> that the user forgot to specify it, so the units are unknown. >> >> Im not sure what CF actually says, but it would be good to clarify. >> >> John >> >> On Thu, Oct 30, 2014 at 2:37 AM, Hedley, Mark <[email protected]> >> wrote: >> Hello CF >> >> > From: CF-metadata [[email protected]] on behalf of Jonathan >> > Gregory [[email protected]] >> >> > Yes, there are some standard names which imply string values, as Karl >> > says. If the standard_name table says 1, that means the quantity is >> > dimensionless, so it's also fine to omit the units, as Jim says. >> >> I would like to raise question about this statement. Omitting the units and >> stating that the units are '1' are two very different things; >> dimensionless != no_unit >> is an important statement which should be clear to data consumers and >> producers. >> >> If the standard name table defines a canonical unit for a standard_name of >> '1' then I expect this quantity to be dimensionless, with a unit of '1' or >> some multiple there of. >> If the standard name states that the canonical unit for a standard_name is >> '' then I expect that quantity to have no unit stated. >> Any deviation from this behaviour is a break with the conventions. I have >> code which explicitly checks this for data sets. >> >> Are people aware of examples of the pattern of use described by Jonathan, >> such as a categorical quantities identified by a standard_name with a >> canonical unit of '1'? >> >> thank you >> mark >> >> _______________________________________________ >> 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 > > -- > <iiagagce.png>Visit us on > Facebook Jim Biard > Research Scholar > Cooperative Institute for Climate and Satellites NC > North Carolina State University > NOAA's National Climatic Data Center > 151 Patton Ave, Asheville, NC 28801 > e: [email protected] > o: +1 828 271 4900 > > > > _______________________________________________ > 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
