-- Eiji (aka Eizi) TOYODA http://www.google.com/profiles/toyoda.eizi On Fri, Oct 31, 2014 at 9:45 AM, John Graybeal < john.graybeal at marinexplore.com> wrote: > 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 <mark.hedley at metoffice.gov.uk> > 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 [cf-metadata-bounces at cgd.ucar.edu] on behalf of Jim > Biard [jbiard at cicsnc.org] > *Sent:* 30 October 2014 16:12 > *To:* cf-metadata at cgd.ucar.edu > *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? > <http://cfconventions.org/Data/cf-conventions/cf-conventions-1.6/build/cf-conventions.html#cell-boundaries>and > climatology variables defined in Section 7.4, ?Climatological Statistics? > <http://cfconventions.org/Data/cf-conventions/cf-conventions-1.6/build/cf-conventions.html#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 < > mark.hedley at metoffice.gov.uk> wrote: > >> Hello CF >> >> > From: CF-metadata [cf-metadata-bounces at cgd.ucar.edu] on behalf of >> Jonathan Gregory [j.m.gregory at reading.ac.uk] >> >> > 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 >> CF-metadata at cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata >> >> > > > _______________________________________________ > CF-metadata mailing listCF-metadata at cgd.ucar.eduhttp://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > -- > <iiagagce.png> <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's National Climatic Data Center <http://ncdc.noaa.gov/> > 151 Patton Ave, Asheville, NC 28801 > e: jbiard at cicsnc.org > o: +1 828 271 4900 > > > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > > > _______________________________________________ > CF-metadata mailing list > CF-metadata at cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20141031/11e6f654/attachment-0001.html>Received on Fri Oct 31 2014 - 02:44:58 GMT
This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:42 BST