⇐ ⇒

[CF-metadata] string valued coordinates

From: Eizi TOYODA <toyoda>
Date: Fri, 31 Oct 2014 17:44:58 +0900

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
>
>
-------------- 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

⇐ ⇒