⇐ ⇒

[CF-metadata] string valued coordinates

From: Eizi TOYODA <toyoda.eizi>
Date: Fri, 31 Oct 2014 09:13:00 +0900

Hi Mark,

> a unit of '' has a definition of '?'

So why don't you propose '?' as the units?

Best
Eizi
 2014/10/31 7:21 "Hedley, Mark" <mark.hedley at metoffice.gov.uk>:

> > 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
>
>
> --
> [image: 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'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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20141031/2da27d95/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iiagagce.png
Type: image/png
Size: 11847 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20141031/2da27d95/attachment-0001.png>
Received on Thu Oct 30 2014 - 18:13:00 GMT

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:42 BST

⇐ ⇒