>From the point of view of a physicist/physical oceanographer, I understand
a measured quantity or index is dimensionless if it is obtained from
quantities whose units cancel out, e.g., concentration with units of kg/kg
might be argued to be dimensionless, or reynolds number Re = vL/{\nu} has
units (m.s^(-1).m)/(m^(2).s^(-1)) is dimensionless. A quantity with no
units would be, like, counting things: number of xbts, number of gliders,
although these might be argued to have the units of "xbts", and "gliders",
or 1. Both kinds different from the situation where data which might or
should have units has been provided but for some reason, through neglect or
error, the units have been omitted/unspecified.
On Fri, Oct 31, 2014 at 4:44 AM, Eizi TOYODA <toyoda at gfd-dennou.org> wrote:
> Hi John
>
> > 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.
>
> I share the same impression. I was thinking it would be nicer for
> maintener of udunits. We should ask modifying udunits so that it would
> refuse processing "no_units" otherwise ut_multiply("no_units", "no_units")
> returns "no_units 2". If I remember right the unit string "?" causes
> immediate error, so we don't have to change udunits.
>
> But I'm okay if the majority here agrees that sort of thing is not a
> responsibility of udunits.
>
> Best,
> Eizi
>
>
>
> Best Regards,
> --
> 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
>>
>>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
--
--
--
=======================================================================
Dr. Christopher M. Duncombe Rae c <deirdre.byrne at noaa.gov>
hristopher.duncombe.rae at noaa.gov
Oceanographer / Data Scientist
IOOS/NOAA, Suite 1225, 1100 Wayne Avenue, Silver Spring, MD 20910, USA
Tel: +1-301-427-2450 Fax: +1-301-427-2073
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20141031/111397e9/attachment-0001.html>
Received on Fri Oct 31 2014 - 06:19:27 GMT
