subject:"Re\: \[CF\-metadata\] string valued coordinates"

Re: [CF-metadata] string valued coordinates

2014-11-11 Thread Jim Biard

/Dimensional_analysis>, a dimensionless quantity or 
quantity of dimension one is a quantity<http://en.wikipedia.org/wiki/Quantity> without an associated 
physical dimension<http://en.wikipedia.org/wiki/Dimensional_analysis>. It is thus a "pure" 
number, and as such always has a dimension of 
1.[1]<http://en.wikipedia.org/wiki/Dimensionless_quantity#cite_note-1>'
which it has sourced from
"1.8 (1.6) quantity of dimension one dimensionless 
quantity"<http://www.iso.org/sites/JCGM/VIM/JCGM_200e_FILES/MAIN_JCGM_200e/01_e.html#L_1_8>.
 International vocabulary of metrology ? Basic and general concepts and associated terms (VIM). 
ISO<http://en.wikipedia.org/wiki/International_Organization_for_Standardization>. 2008. 
Retrieved 2011-03-22.

This is a good enough source for me.

I will wait to give space for more comments, then,  if people are content, I 
will raise a change request with udunits.
Assuming this is accepted and processed I will raise a change request for CF to 
add some text to 3.1.
Finally I will request a change for any standard_names which appear not to 
follow this approach (I have only 'area_type' so far).

I hope this seems like a reasonable response.


From: Eizi TOYODA [toy...@gfd-dennou.org]
Sent: 31 October 2014 08:44
To: John Graybeal
Cc: Hedley, Mark; CF Metadata List
Subject: Re: [CF-metadata] string valued coordinates

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 
mailto:john.grayb...@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 
mailto:mark.hed...@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 ''

Re: [CF-metadata] string valued coordinates

2014-11-07 Thread Jonathan Gregory

gt; >>>as a representation of
> >>>'?'
> >>>such that the behaviour is consistent; 'no_unit' should always raise an 
> >>>exception when used in the udunits processing rules, exactly as '?' does.
> >>>
> >>>With regard to meaning, I have found the wikipedia entry useful:
> >>>http://en.wikipedia.org/wiki/Dimensionless_quantity
> >>>`In dimensional 
> >>>analysis<http://en.wikipedia.org/wiki/Dimensional_analysis>, a 
> >>>dimensionless quantity or quantity of dimension one is a 
> >>>quantity<http://en.wikipedia.org/wiki/Quantity> without an associated 
> >>>physical dimension<http://en.wikipedia.org/wiki/Dimensional_analysis>. It 
> >>>is thus a "pure" number, and as such always has a dimension of 
> >>>1.[1]<http://en.wikipedia.org/wiki/Dimensionless_quantity#cite_note-1>'
> >>>which it has sourced from
> >>>"1.8 (1.6) quantity of dimension one dimensionless 
> >>>quantity"<http://www.iso.org/sites/JCGM/VIM/JCGM_200e_FILES/MAIN_JCGM_200e/01_e.html#L_1_8>.
> >>> International vocabulary of metrology ? Basic and general concepts and 
> >>>associated terms (VIM). 
> >>>ISO<http://en.wikipedia.org/wiki/International_Organization_for_Standardization>.
> >>> 2008. Retrieved 2011-03-22.
> >>>
> >>>This is a good enough source for me.
> >>>
> >>>I will wait to give space for more comments, then,  if people are content, 
> >>>I will raise a change request with udunits.
> >>>Assuming this is accepted and processed I will raise a change request for 
> >>>CF to add some text to 3.1.
> >>>Finally I will request a change for any standard_names which appear not to 
> >>>follow this approach (I have only 'area_type' so far).
> >>>
> >>>I hope this seems like a reasonable response.
> >>>
> >>>
> >>>From: Eizi TOYODA [toy...@gfd-dennou.org]
> >>>Sent: 31 October 2014 08:44
> >>>To: John Graybeal
> >>>Cc: Hedley, Mark; CF Metadata List
> >>>Subject: Re: [CF-metadata] string valued coordinates
> >>>
> >>>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 
> >>>mailto:john.grayb...@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

Re: [CF-metadata] string valued coordinates

2014-11-07 Thread Schultz, Martin

Dear Jonathan,

 Deprecating the units attribute for string and char variables (perhaps 
int, too?) sounds like a good idea. Yet, I would still second Marc to at least 
allow for a "None" value in the units attribute - as far as I understand this 
wouldn't break the compatibility.

But, in my view even more important, is the  issue of making the units 
attribute mandatory in CF-2. We had this discussion earlier, and I sensed some 
support for the general idea of "cleaning" CF in the sense that our 
applications can rely on certain things to be there, because this clearly 
enhances the resilience of interoperable systems. If people submit their test 
files to a CF check and get a message back that they are supposed to add a 
units attribute, they may do so. If the CF checker doesn't tell them this 
(because it is valid CF to have variables without a units attribute), then they 
will most certainly not do so. Of course, in light of the new discussion, we 
would have to carefully draft the rules for when the units attribute is indeed 
mandatory.

Best regards,

Martin

--

Message: 2
Date: Thu, 6 Nov 2014 17:38:38 +
From: Jonathan Gregory 
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata]  string valued coordinates
Message-ID: <20141106173838.ga9...@met.reading.ac.uk>
Content-Type: text/plain; charset=us-ascii

One further thought: we could deprecate the units attribute for variables of 
string and char type, or having a flag_values att. These conditions can be 
detected automatically, so the CF_checker would give a warning, for instance.
Jonathan

[...]





Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] string valued coordinates

2014-11-07 Thread Hedley, Mark

Hello Jim et al

I have followed your path and I agree with your analysis

It looks like my assumption, and a whole part of my discussion thread, is based 
on a piece of code in a third party udunits wrapper which is not part of 
udunits.  Hence I have been muddying the issue with an interpretation which is 
not valid.

Apologies for the confusion this has caused.

I now retract all my statements linked to 
units = ''
as udunits unequivocally interprets this as equivalent to 
units = '1'

I will consider this some more and try to come up with a coherent thought 
process which is supported by the software.

all the best
mark


From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] on behalf of Jim Biard 
[jbi...@cicsnc.org]
Sent: 06 November 2014 20:15
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] string valued coordinates

Hi.

Just out of curiosity, I used udunits-2 to do a test to compare units of
'', '1', and 'kg/kg'. They all evaluated as equal to one another.

Grace and peace,

Jim
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] string valued coordinates

2014-11-06 Thread Jim Biard


Hi.

Just out of curiosity, I used udunits-2 to do a test to compare units of 
'', '1', and 'kg/kg'. They all evaluated as equal to one another.


Grace and peace,

Jim
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] string valued coordinates

2014-11-06 Thread Hedley, Mark

> As I read the CF Conventions document, my conclusion is that CF currently 
> conflates the two concepts 'doesn't have units because the concept is 
> inapplicable' and 'doesn't have units because the quantity is a pure number'.

I read the conventions slightly differently, which is part of the reason I 
think we need a little clarification in the text.

My reading is that CF does not explicitly recognise 'doesn't have units because 
the concept is inapplicable' in the conventions.  However it does recognise 
udunits' role in the definition of applicable units.

udunits has this concept, which can be utilised by
 units = ''
meaning that we can already achieve my aims with the capabilities we have.

So, I would like to adapt your rules to read:

  *   If the variable contains pure numerical values, such as a fractions, for 
which no other applicable unit exists, put units = '1'.
  *   If the variable contains strings, flags, or non-numerical binary 
quantities, put units = ''
  *   Never leave off the units attribute, as this is always interpreted as 
units = '1'.

and state this explicitly in the CF conventions.

My further comments about the lack of clarity in the syntax
  units = ''
is an additional conversation, which may be useful, but is not central to the 
discussion, in my mind.  We can decide to request and adopt
  units = 'no_units'
  units = 'None'
if we feel this would add clarity, but it does not change the behaviour.

all the best
mark
____________
From: Jim Biard [jbi...@cicsnc.org]
Sent: 04 November 2014 17:45
To: Hedley, Mark; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] string valued coordinates

Mark,

As I read the CF Conventions document, my conclusion is that CF currently 
conflates the two concepts 'doesn't have units because the concept is 
inapplicable' and 'doesn't have units because the quantity is a pure number'. 
Current practice, as evidenced by the standard_names table, has been to 
sometimes specify units = '1' for cases where units are inapplicable, so 
neither lack of a units attribute, nor the presence of a units attribute with a 
value of 1 can be assumed to unambiguously mean only one thing.

In data products that I have authored or guided others in authoring, the 
(personal) rule I have followed is:

  *   If the variable contains pure numerical values, such as a fractions, for 
which no other applicable unit exists, put units = '1'.
  *   If the variable contains strings, flags, or non-numerical binary 
quantities, don't give it a units attribute.

I find this to be unambiguous and compatible with the standard. I think we can 
reword the standard to reflect something like this, and there won't be any 
backward-compatibility issues. I don't find any need to add an explicit unit 
that means there isn't a unit.

Grace and peace,

Jim

On 11/4/14, 11:53 AM, Hedley, Mark wrote:
Hello Jim

I want to be really clear on this, as this is crucial.  If I am interpreting 
this wrong I would really like to know.

> as backward compatibility will pretty much require that having no units 
> attribute be interpretable as having a units attribute saying 'no_unit'.

I think this is incorrect.  Backwards compatibility requires that an absence of 
a units attribute is exactly the same as units='1'.

This is what CF mandates, as I read it.  This is very different from your 
comments.

Please may you consider
http://cfconventions.org/Data/cf-conventions/cf-conventions-1.6/build/cf-conventions.html#units
and let us know if your position remains the same?
I am afraid I do not think it is born out by the specification.

all the best
mark

____________
From: Jim Biard [jbi...@cicsnc.org<mailto:jbi...@cicsnc.org>]
Sent: 04 November 2014 16:45
To: Hedley, Mark; cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] string valued coordinates

Mark,

I agree that CF is currently ambiguous on this front, and I'm fine with 
improving definitions going forward, but 'no_unit' smacks of the classic 'this 
page intentionally left blank' found in government documents. I think it's 
overkill, as backward compatibility will pretty much require that having no 
units attribute be interpretable as having a units attribute saying 'no_unit'.

Grace and peace,

Jim

On 11/4/14, 11:38 AM, Hedley, Mark wrote:
Hello Jim

> A variable with no units attribute at all is also pretty unambiguously a 
> marker for something that isn't intended to be a even a pure number.

If only this were the case.  CF conventions state that:
Units are not required for dimensionless quantities. A variable with no units 
attribute is assumed to be dimensionless. However, a

Re: [CF-metadata] string valued coordinates (unitless quantities)

2014-11-06 Thread Hedley, Mark

Interesting points Martin

1) I like this, I would support an explicit
   units = "None"
   to address this issue

2) I agree with this, I woudl like to see units mandatory, with an option for 
None, as above

3) I think '' is a functional alternative to None, but it reads poorly

4) I believe this is accepted, and used.  You can define a unit of 'kg kg-1' 
and udunits works with it, representing it's definition as '1' to support 
operations.  So., I think "kg/kg" and "mole/mole" are already accepted

all the best
mark


From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] on behalf of Schultz, 
Martin [m.schu...@fz-juelich.de]
Sent: 05 November 2014 07:57
To: 'cf-metadata@cgd.ucar.edu'
Subject: Re: [CF-metadata] string valued coordinates (unitless quantities)

Dear Mark and all,

 thanks for this discussion and the motion to approach udunits to advance 
this issue. Reading through the posts on this, I have two comments, one 
question, and one afterthought:

1. Why "no_unit" and not simply "none"? "no_unit" could also be "no_units" (in 
fact the attribute name is unit*s*, so the missing "s" in "no_unit" may be 
confusing). Being a Python fan, I like Python's concept of None as a value that 
indicates that there is no value; just what we want here.

2. When you revise the respective section of the CF convention: in light of the 
"CF 2" discussions we should think about making the units attribute mandatory. 
Alternatively, I would suggest that a missing units attribute should mean 
"none" rather than "1" and/or the units attribute should become mandatory for 
numerical fields (a string array, for example of station names, may indeed not 
require a units attribute).

3. Would you regard "" (empty string) as a valid alternative to "none"?   [I 
may have overlooked this in the previous discussions but wasn't sure if there 
was a consensus view]

4. Coming back to the old "kg/kg" or "mole/mole" discussion: I guess it would 
help if udunits would accept "terms that evaluate as '1' " with the 
understanding that they ae equivalent to "1" as unit. Many (most) atmospheric 
chemistry modelers are still operating in the grey zone with units attributes 
of "nmole mole-1" which are a lot more readable than "1.e-9" and make a lot of 
sense to them. Only if you enforce a CF checker on them they will abide, but 
keep grunting. If one doesn't want to be too generic here, at least "kg/kg" and 
"mole/mole" should be added to the udunits collection.

Best regards,

Martin





-Original Message-
From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of 
cf-metadata-requ...@cgd.ucar.edu
Sent: Tuesday, November 04, 2014 5:38 PM
To: cf-metadata@cgd.ucar.edu
Subject: CF-metadata Digest, Vol 139, Issue 4

Send CF-metadata mailing list submissions to
cf-metadata@cgd.ucar.edu



Message: 2
Date: Tue, 4 Nov 2014 16:38:12 +
From: "Hedley, Mark" 
To: Jim Biard , "cf-metadata@cgd.ucar.edu"

Subject: Re: [CF-metadata] string valued coordinates
Message-ID:

<7819c496f4e10e47bcefbe74551aac9606f40...@exxcmpd1dag3.cmpd1.metoffice.gov.uk>

Content-Type: text/plain; charset="windows-1252"

Hello Jim

> A variable with no units attribute at all is also pretty unambiguously a 
> marker for something that isn't intended to be a even a pure number.

If only this were the case.  CF conventions state that:
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.
http://cfconventions.org/Data/cf-conventions/cf-conventions-1.6/build/cf-conventions.html#units

Thus, the absence of a unit is to be interpreted identically to a statement 
that units = '1'

This is the current situation and it is likely that there is lots of data like 
this around.

> Do we really need something more than a disambiguation of units = '1' vs no 
> units attribute present?

Yes, I think we do: this situation is not ambiguous in CF, they are the same 
thing.

What I believe we require is a udunits entity which is clearly 'there is no 
unit of measure here, this is not dimensioned and not dimensionless'

The udunits value
''
delivers this functionality (I think), but it does not read very well, hence my 
suggestion that we ask for a new entry in udunits, 'no_unit'
which is hopefully clear in its meaning and interpretation and which behaves 
the same as '' : failing all udunits processing attempts and operating as 'not 
a unit

Re: [CF-metadata] string valued coordinates

2014-11-05 Thread Jim Biard


Jonathan,

In one case I am storing raw binary values from a satellite downlink. 
Another example of this sort of case would be a variable where you are 
storing flag values, particularly ones where you are using flag_masks. 
The values are 'non-numerical' in that they are not directly 
interpretable as a scientific measurement or the result of a 
mathematical formula. It's probably not the best way to describe them, 
but I was trying to find a short way to express the concept.


Grace and peace,

Jim

On 11/5/14, 11:06 AM, Jonathan Gregory wrote:

...

There are quantities for which units are inapplicable i.e. string-valued ones
and flags encoding those. Jim, I wonder what "non-numerical binary quantities"
you put in CF datasets?

...


--
CICS-NC  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: jbi...@cicsnc.org
o: +1 828 271 4900




___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] string valued coordinates (unitless quantities)

2014-11-04 Thread Schultz, Martin

Dear Mark and all,

 thanks for this discussion and the motion to approach udunits to advance 
this issue. Reading through the posts on this, I have two comments, one 
question, and one afterthought:

1. Why "no_unit" and not simply "none"? "no_unit" could also be "no_units" (in 
fact the attribute name is unit*s*, so the missing "s" in "no_unit" may be 
confusing). Being a Python fan, I like Python's concept of None as a value that 
indicates that there is no value; just what we want here.

2. When you revise the respective section of the CF convention: in light of the 
"CF 2" discussions we should think about making the units attribute mandatory. 
Alternatively, I would suggest that a missing units attribute should mean 
"none" rather than "1" and/or the units attribute should become mandatory for 
numerical fields (a string array, for example of station names, may indeed not 
require a units attribute).

3. Would you regard "" (empty string) as a valid alternative to "none"?   [I 
may have overlooked this in the previous discussions but wasn't sure if there 
was a consensus view]

4. Coming back to the old "kg/kg" or "mole/mole" discussion: I guess it would 
help if udunits would accept "terms that evaluate as '1' " with the 
understanding that they ae equivalent to "1" as unit. Many (most) atmospheric 
chemistry modelers are still operating in the grey zone with units attributes 
of "nmole mole-1" which are a lot more readable than "1.e-9" and make a lot of 
sense to them. Only if you enforce a CF checker on them they will abide, but 
keep grunting. If one doesn't want to be too generic here, at least "kg/kg" and 
"mole/mole" should be added to the udunits collection.

Best regards,

Martin





-Original Message-
From: CF-metadata [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of 
cf-metadata-requ...@cgd.ucar.edu
Sent: Tuesday, November 04, 2014 5:38 PM
To: cf-metadata@cgd.ucar.edu
Subject: CF-metadata Digest, Vol 139, Issue 4

Send CF-metadata mailing list submissions to
cf-metadata@cgd.ucar.edu



Message: 2
Date: Tue, 4 Nov 2014 16:38:12 +
From: "Hedley, Mark" 
To: Jim Biard , "cf-metadata@cgd.ucar.edu"

Subject: Re: [CF-metadata] string valued coordinates
Message-ID:

<7819c496f4e10e47bcefbe74551aac9606f40...@exxcmpd1dag3.cmpd1.metoffice.gov.uk>

Content-Type: text/plain; charset="windows-1252"

Hello Jim

> A variable with no units attribute at all is also pretty unambiguously a 
> marker for something that isn't intended to be a even a pure number.

If only this were the case.  CF conventions state that:
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.
http://cfconventions.org/Data/cf-conventions/cf-conventions-1.6/build/cf-conventions.html#units

Thus, the absence of a unit is to be interpreted identically to a statement 
that units = '1'

This is the current situation and it is likely that there is lots of data like 
this around.

> Do we really need something more than a disambiguation of units = '1' vs no 
> units attribute present?

Yes, I think we do: this situation is not ambiguous in CF, they are the same 
thing.

What I believe we require is a udunits entity which is clearly 'there is no 
unit of measure here, this is not dimensioned and not dimensionless'

The udunits value
''
delivers this functionality (I think), but it does not read very well, hence my 
suggestion that we ask for a new entry in udunits, 'no_unit'
which is hopefully clear in its meaning and interpretation and which behaves 
the same as '' : failing all udunits processing attempts and operating as 'not 
a unit'

all the best
mark


From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] on behalf of Jim Biard 
[jbi...@cicsnc.org]
Sent: 31 October 2014 15:18
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] string valued coordinates

Mark,

I'm not clear on what you are suggesting that udunits do with 'no_unit' or '?'.

I had thought that the desire was to be able to differentiate between a pure 
number (as you mention below) and a value (whether a string or a bit pattern) 
that should not be interpreted as any number at all.

As the situation stands, a units value of '1' is pretty unambiguously a marker 
for a pure number. We may need to modify docs to make this clearer, but I don't 
think that poses a problem. A variable with no units attribute at all is also 
pretty unambiguously a marker for something th

Re: [CF-metadata] string valued coordinates

2014-11-04 Thread Hedley, Mark

Hello Jim

I want to be really clear on this, as this is crucial.  If I am interpreting 
this wrong I would really like to know.

> as backward compatibility will pretty much require that having no units 
> attribute be interpretable as having a units attribute saying 'no_unit'.

I think this is incorrect.  Backwards compatibility requires that an absence of 
a units attribute is exactly the same as units='1'.

This is what CF mandates, as I read it.  This is very different from your 
comments.

Please may you consider
http://cfconventions.org/Data/cf-conventions/cf-conventions-1.6/build/cf-conventions.html#units
and let us know if your position remains the same?
I am afraid I do not think it is born out by the specification.

all the best
mark

From: Jim Biard [jbi...@cicsnc.org]
Sent: 04 November 2014 16:45
To: Hedley, Mark; cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] string valued coordinates

Mark,

I agree that CF is currently ambiguous on this front, and I'm fine with 
improving definitions going forward, but 'no_unit' smacks of the classic 'this 
page intentionally left blank' found in government documents. I think it's 
overkill, as backward compatibility will pretty much require that having no 
units attribute be interpretable as having a units attribute saying 'no_unit'.

Grace and peace,

Jim

On 11/4/14, 11:38 AM, Hedley, Mark wrote:
Hello Jim

> A variable with no units attribute at all is also pretty unambiguously a 
> marker for something that isn't intended to be a even a pure number.

If only this were the case.  CF conventions state that:
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.
http://cfconventions.org/Data/cf-conventions/cf-conventions-1.6/build/cf-conventions.html#units

Thus, the absence of a unit is to be interpreted identically to a statement that
units = '1'

This is the current situation and it is likely that there is lots of data like 
this around.

> Do we really need something more than a disambiguation of units = '1' vs no 
> units attribute present?

Yes, I think we do: this situation is not ambiguous in CF, they are the same 
thing.

What I believe we require is a udunits entity which is clearly 'there is no 
unit of measure here, this is not dimensioned and not dimensionless'

The udunits value
''
delivers this functionality (I think), but it does not read very well, hence my 
suggestion that we ask for a new entry in udunits,
'no_unit'
which is hopefully clear in its meaning and interpretation
and which behaves the same as '' : failing all udunits processing attempts and 
operating as 'not a unit'

all the best
mark

From: CF-metadata 
[cf-metadata-boun...@cgd.ucar.edu<mailto:cf-metadata-boun...@cgd.ucar.edu>] on 
behalf of Jim Biard [jbi...@cicsnc.org<mailto:jbi...@cicsnc.org>]
Sent: 31 October 2014 15:18
To: cf-metadata@cgd.ucar.edu<mailto:cf-metadata@cgd.ucar.edu>
Subject: Re: [CF-metadata] string valued coordinates

Mark,

I'm not clear on what you are suggesting that udunits do with 'no_unit' or '?'.

I had thought that the desire was to be able to differentiate between a pure 
number (as you mention below) and a value (whether a string or a bit pattern) 
that should not be interpreted as any number at all.

As the situation stands, a units value of '1' is pretty unambiguously a marker 
for a pure number. We may need to modify docs to make this clearer, but I don't 
think that poses a problem. A variable with no units attribute at all is also 
pretty unambiguously a marker for something that isn't intended to be a even a 
pure number. Again, we may need to modify docs to make this clearer. Because 
these two concepts are somewhat conflated in the current documentation and 
usage (area_type being an example), there is the issue of other places where 
cleanup would be good going forward, but even if you have a units value of '1' 
on a non-number, it doesn't hurt anything in practice.

Do we really need something more than a disambiguation of units = '1' vs no 
units attribute present?

Grace and peace,

Jim

On 10/31/14, 11:04 AM, Hedley, Mark wrote:
Thank you for all the responses, it sounds like 'all of the above' is the 
preferred response to my suggestions of plausible next steps.  I will pursue 
all of these.

Eizi's point about having no_unit in udunits is sound; I suggest we request 
udunits use
  'no_unit'
as a representation of
'?'
such that the behaviour is consistent; 'no_unit' should always raise an 
exception when used in the udunits pr

Re: [CF-metadata] string valued coordinates

2014-11-04 Thread Jim Biard

Mark,

I agree that CF is currently ambiguous on this front, and I'm fine with
improving definitions going forward, but 'no_unit' smacks of the classic
'this page intentionally left blank' found in government documents. I
think it's overkill, as backward compatibility will pretty much require
that having no units attribute be interpretable as having a units
attribute saying 'no_unit'.

Grace and peace,

Jim

On 11/4/14, 11:38 AM, Hedley, Mark wrote:

Hello Jim

> A variable with no units attribute at all is also pretty
unambiguously a marker for something that isn't intended to be a even
a pure number.

If only this were the case. CF conventions state that:
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.

http://cfconventions.org/Data/cf-conventions/cf-conventions-1.6/build/cf-conventions.html#units

Thus, the absence of a unit is to be interpreted identically to a
statement that

units = '1'

This is the current situation and it is likely that there is lots of
data like this around.

> Do we really need something more than a disambiguation of units =
'1' vs no units attribute present?

Yes, I think we do: this situation is not ambiguous in CF, they are
the same thing.

What I believe we require is a udunits entity which is clearly 'there
is no unit of measure here, this is not dimensioned and not dimensionless'

The udunits value
''
delivers this functionality (I think), but it does not read very well,
hence my suggestion that we ask for a new entry in udunits,

'no_unit'
which is hopefully clear in its meaning and interpretation
and which behaves the same as '' : failing all udunits processing
attempts and operating as 'not a unit'

all the best
mark

*From:* CF-metadata [cf-metadata-boun...@cgd.ucar.edu] on behalf of
Jim Biard [jbi...@cicsnc.org]

*Sent:* 31 October 2014 15:18
*To:* cf-metadata@cgd.ucar.edu
*Subject:* Re: [CF-metadata] string valued coordinates

Mark,

I'm not clear on what you are suggesting that udunits do with
'no_unit' or '?'.

I had thought that the desire was to be able to differentiate between
a pure number (as you mention below) and a value (whether a string or
a bit pattern) that should not be interpreted as any number at all.

As the situation stands, a units value of '1' is pretty unambiguously
a marker for a pure number. We may need to modify docs to make this
clearer, but I don't think that poses a problem. A variable with no
units attribute at all is also pretty unambiguously a marker for
something that isn't intended to be a even a pure number. Again, we
may need to modify docs to make this clearer. Because these two
concepts are somewhat conflated in the current documentation and usage
(area_type being an example), there is the issue of other places where
cleanup would be good going forward, but even if you have a units
value of '1' on a non-number, it doesn't hurt anything in practice.

Do we really need something more than a disambiguation of units = '1'
vs no units attribute present?

Grace and peace,

Jim

On 10/31/14, 11:04 AM, Hedley, Mark wrote:
Thank you for all the responses, it sounds like 'all of the above' is
the preferred response to my suggestions of plausible next steps. I
will pursue all of these.

Eizi's point about having no_unit in udunits is sound; I suggest we
request udunits use

'no_unit'
as a representation of
'?'
such that the behaviour is consistent; 'no_unit' should always raise
an exception when used in the udunits processing rules, exactly as
'?' does.

With regard to meaning, I have found the wikipedia entry useful:
http://en.wikipedia.org/wiki/Dimensionless_quantity
`In dimensional analysis
<http://en.wikipedia.org/wiki/Dimensional_analysis>, a *dimensionless
quantity* or *quantity of dimension one* is a quantity
<http://en.wikipedia.org/wiki/Quantity> without an associated
physical dimension
<http://en.wikipedia.org/wiki/Dimensional_analysis>. It is thus a
"pure" number, and as such always has a dimension of 1.^[1]
<http://en.wikipedia.org/wiki/Dimensionless_quantity#cite_note-1> '

which it has sourced from
"*1.8* (1.6) *quantity of dimension one* dimensionless quantity"
<http://www.iso.org/sites/JCGM/VIM/JCGM_200e_FILES/MAIN_JCGM_200e/01_e.html#L_1_8>.
/International vocabulary of metrology --- Basic and general concepts
and associated terms (VIM)/. ISO
<http://en.wikipedia.org/wiki/International_Organization_for_Standardization>.
2008. Re

Re: [CF-metadata] string valued coordinates

2014-11-04 Thread Hedley, Mark

Hello Jim

> A variable with no units attribute at all is also pretty unambiguously a 
> marker for something that isn't intended to be a even a pure number.

If only this were the case.  CF conventions state that:
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.
http://cfconventions.org/Data/cf-conventions/cf-conventions-1.6/build/cf-conventions.html#units

Thus, the absence of a unit is to be interpreted identically to a statement that
units = '1'

This is the current situation and it is likely that there is lots of data like 
this around.

> Do we really need something more than a disambiguation of units = '1' vs no 
> units attribute present?

Yes, I think we do: this situation is not ambiguous in CF, they are the same 
thing.

What I believe we require is a udunits entity which is clearly 'there is no 
unit of measure here, this is not dimensioned and not dimensionless'

The udunits value
''
delivers this functionality (I think), but it does not read very well, hence my 
suggestion that we ask for a new entry in udunits,
'no_unit'
which is hopefully clear in its meaning and interpretation
and which behaves the same as '' : failing all udunits processing attempts and 
operating as 'not a unit'

all the best
mark

From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] on behalf of Jim Biard 
[jbi...@cicsnc.org]
Sent: 31 October 2014 15:18
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] string valued coordinates

Mark,

I'm not clear on what you are suggesting that udunits do with 'no_unit' or '?'.

I had thought that the desire was to be able to differentiate between a pure 
number (as you mention below) and a value (whether a string or a bit pattern) 
that should not be interpreted as any number at all.

As the situation stands, a units value of '1' is pretty unambiguously a marker 
for a pure number. We may need to modify docs to make this clearer, but I don't 
think that poses a problem. A variable with no units attribute at all is also 
pretty unambiguously a marker for something that isn't intended to be a even a 
pure number. Again, we may need to modify docs to make this clearer. Because 
these two concepts are somewhat conflated in the current documentation and 
usage (area_type being an example), there is the issue of other places where 
cleanup would be good going forward, but even if you have a units value of '1' 
on a non-number, it doesn't hurt anything in practice.

Do we really need something more than a disambiguation of units = '1' vs no 
units attribute present?

Grace and peace,

Jim

On 10/31/14, 11:04 AM, Hedley, Mark wrote:
Thank you for all the responses, it sounds like 'all of the above' is the 
preferred response to my suggestions of plausible next steps.  I will pursue 
all of these.

Eizi's point about having no_unit in udunits is sound; I suggest we request 
udunits use
  'no_unit'
as a representation of
'?'
such that the behaviour is consistent; 'no_unit' should always raise an 
exception when used in the udunits processing rules, exactly as '?' does.

With regard to meaning, I have found the wikipedia entry useful:
http://en.wikipedia.org/wiki/Dimensionless_quantity
`In dimensional analysis<http://en.wikipedia.org/wiki/Dimensional_analysis>, a 
dimensionless quantity or quantity of dimension one is a 
quantity<http://en.wikipedia.org/wiki/Quantity> without an associated physical 
dimension<http://en.wikipedia.org/wiki/Dimensional_analysis>. It is thus a 
"pure" number, and as such always has a dimension of 
1.[1]<http://en.wikipedia.org/wiki/Dimensionless_quantity#cite_note-1>'
which it has sourced from
"1.8 (1.6) quantity of dimension one dimensionless 
quantity"<http://www.iso.org/sites/JCGM/VIM/JCGM_200e_FILES/MAIN_JCGM_200e/01_e.html#L_1_8>.
 International vocabulary of metrology — Basic and general concepts and 
associated terms (VIM). 
ISO<http://en.wikipedia.org/wiki/International_Organization_for_Standardization>.
 2008. Retrieved 2011-03-22.

This is a good enough source for me.

I will wait to give space for more comments, then,  if people are content, I 
will raise a change request with udunits.
Assuming this is accepted and processed I will raise a change request for CF to 
add some text to 3.1.
Finally I will request a change for any standard_names which appear not to 
follow this approach (I have only 'area_type' so far).

I hope this seems like a reasonable response.

From: Eizi TOYODA [toy...@gfd-dennou.org<mailto:toy...@gfd-dennou.org>]
Sent: 3

Re: [CF-metadata] string valued coordinates

2014-11-04 Thread Jim Biard


Mark,

I'm not clear on what you are suggesting that udunits do with 'no_unit' 
or '?'.


I had thought that the desire was to be able to differentiate between a 
pure number (as you mention below) and a value (whether a string or a 
bit pattern) that should not be interpreted as any number at all.


As the situation stands, a units value of '1' is pretty unambiguously a 
marker for a pure number. We may need to modify docs to make this 
clearer, but I don't think that poses a problem. A variable with no 
units attribute at all is also pretty unambiguously a marker for 
something that isn't intended to be a even a pure number. Again, we may 
need to modify docs to make this clearer. Because these two concepts are 
somewhat conflated in the current documentation and usage (area_type 
being an example), there is the issue of other places where cleanup 
would be good going forward, but even if you have a units value of '1' 
on a non-number, it doesn't hurt anything in practice.


Do we really need something more than a disambiguation of units = '1' vs 
no units attribute present?


Grace and peace,

Jim

On 10/31/14, 11:04 AM, Hedley, Mark wrote:
Thank you for all the responses, it sounds like 'all of the above' is 
the preferred response to my suggestions of plausible next steps.  I 
will pursue all of these.


Eizi's point about having no_unit in udunits is sound; I suggest we 
request udunits use

  'no_unit'
as a representation of
'?'
such that the behaviour is consistent; 'no_unit' should always raise 
an exception when used in the udunits processing rules, exactly as '?' 
does.


With regard to meaning, I have found the wikipedia entry useful:
http://en.wikipedia.org/wiki/Dimensionless_quantity
`In dimensional analysis 
<http://en.wikipedia.org/wiki/Dimensional_analysis>, a *dimensionless 
quantity* or *quantity of dimension one* is a quantity 
<http://en.wikipedia.org/wiki/Quantity> without an associated physical 
dimension <http://en.wikipedia.org/wiki/Dimensional_analysis>. It is 
thus a "pure" number, and as such always has a dimension of 1.^[1] 
<http://en.wikipedia.org/wiki/Dimensionless_quantity#cite_note-1> '

which it has sourced from
"*1.8* (1.6) *quantity of dimension one* dimensionless quantity" 
<http://www.iso.org/sites/JCGM/VIM/JCGM_200e_FILES/MAIN_JCGM_200e/01_e.html#L_1_8>. 
/International vocabulary of metrology --- Basic and general concepts 
and associated terms (VIM)/. ISO 
<http://en.wikipedia.org/wiki/International_Organization_for_Standardization>. 
2008. Retrieved 2011-03-22.


This is a good enough source for me.

I will wait to give space for more comments, then,  if people are 
content, I will raise a change request with udunits.
Assuming this is accepted and processed I will raise a change request 
for CF to add some text to 3.1.
Finally I will request a change for any standard_names which appear 
not to follow this approach (I have only 'area_type' so far).


I hope this seems like a reasonable response.

------------------------
*From:* Eizi TOYODA [toy...@gfd-dennou.org]
*Sent:* 31 October 2014 08:44
*To:* John Graybeal
*Cc:* Hedley, Mark; CF Metadata List
*Subject:* Re: [CF-metadata] string valued coordinates

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 
<mailto:john.grayb...@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 in

Re: [CF-metadata] string valued coordinates

2014-10-31 Thread Hedley, Mark

Thank you for all the responses, it sounds like 'all of the above' is the 
preferred response to my suggestions of plausible next steps.  I will pursue 
all of these.

Eizi's point about having no_unit in udunits is sound; I suggest we request 
udunits use
  'no_unit'
as a representation of
'?'
such that the behaviour is consistent; 'no_unit' should always raise an 
exception when used in the udunits processing rules, exactly as '?' does.

With regard to meaning, I have found the wikipedia entry useful:
http://en.wikipedia.org/wiki/Dimensionless_quantity
`In dimensional analysis<http://en.wikipedia.org/wiki/Dimensional_analysis>, a 
dimensionless quantity or quantity of dimension one is a 
quantity<http://en.wikipedia.org/wiki/Quantity> without an associated physical 
dimension<http://en.wikipedia.org/wiki/Dimensional_analysis>. It is thus a 
"pure" number, and as such always has a dimension of 
1.[1]<http://en.wikipedia.org/wiki/Dimensionless_quantity#cite_note-1>'
which it has sourced from
"1.8 (1.6) quantity of dimension one dimensionless 
quantity"<http://www.iso.org/sites/JCGM/VIM/JCGM_200e_FILES/MAIN_JCGM_200e/01_e.html#L_1_8>.
 International vocabulary of metrology — Basic and general concepts and 
associated terms (VIM). 
ISO<http://en.wikipedia.org/wiki/International_Organization_for_Standardization>.
 2008. Retrieved 2011-03-22.

This is a good enough source for me.

I will wait to give space for more comments, then,  if people are content, I 
will raise a change request with udunits.
Assuming this is accepted and processed I will raise a change request for CF to 
add some text to 3.1.
Finally I will request a change for any standard_names which appear not to 
follow this approach (I have only 'area_type' so far).

I hope this seems like a reasonable response.

From: Eizi TOYODA [toy...@gfd-dennou.org]
Sent: 31 October 2014 08:44
To: John Graybeal
Cc: Hedley, Mark; CF Metadata List
Subject: Re: [CF-metadata] string valued coordinates

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 
mailto:john.grayb...@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 
mailto:mark.hed...@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 deci

Re: [CF-metadata] string valued coordinates

2014-10-31 Thread Christopher Duncombe Rae - NOAA Affiliate

) 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-boun...@cgd.ucar.edu] on behalf of Jim
>> Biard [jbi...@cicsnc.org]
>> *Sent:* 30 October 2014 16:12
>> *To:* cf-metadata@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.hed...@metoffice.gov.uk> wrote:
>>
>>> Hello CF
>>>
>

Re: [CF-metadata] string valued coordinates

2014-10-31 Thread Eizi TOYODA

mensioned 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-boun...@cgd.ucar.edu] on behalf of Jim
> Biard [jbi...@cicsnc.org]
> *Sent:* 30 October 2014 16:12
> *To:* cf-metadata@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.hed...@metoffice.gov.uk> wrote:
>
>> Hello CF
>>
>> > From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] on behalf of
>> Jonathan Gregory [j.m.greg...@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-metad

Re: [CF-metadata] string valued coordinates

2014-10-30 Thread John Graybeal

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  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-boun...@cgd.ucar.edu] on behalf of Jim Biard 
> [jbi...@cicsnc.org]
> Sent: 30 October 2014 16:12
> To: cf-metadata@cgd.ucar.edu
> Subject: Re: [CF-metadata] string valued coordinates
> 
> CF says that if the units

Re: [CF-metadata] string valued coordinates

2014-10-30 Thread Eizi TOYODA

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

>  > 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-boun...@cgd.ucar.edu] on behalf of Jim
> Biard [jbi...@cicsnc.org]
> *Sent:* 30 October 2014 16:12
> *To:* cf-metadata@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

Re: [CF-metadata] string valued coordinates

2014-10-30 Thread Hedley, Mark

> 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-boun...@cgd.ucar.edu] on behalf of Jim Biard 
[jbi...@cicsnc.org]
Sent: 30 October 2014 16:12
To: cf-metadata@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

Re: [CF-metadata] string valued coordinates

2014-10-30 Thread Jim Biard

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 
inSection 7.1, "Cell 
Boundaries"and 
climatology variables defined inSection 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 
mailto:mark.hed...@metoffice.gov.uk>> 
wrote:

Hello CF

> From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu
] on behalf of Jonathan
Gregory [j.m.greg...@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@cgd.ucar.edu 
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

--
CICS-NC  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: jbi...@cicsnc.org
o: +1 828 271 4900

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] string valued coordinates

2014-10-30 Thread John Caron

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

>  Hello CF
>
> > From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] on behalf of
> Jonathan Gregory [j.m.greg...@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@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] string valued coordinates

2014-10-30 Thread Hedley, Mark

Hello CF

> From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] on behalf of Jonathan 
> Gregory [j.m.greg...@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@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] string valued coordinates

2014-10-06 Thread Jonathan Gregory

Dear Mark et al.

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.

Coordinate variables (as distinct from aux coord vars) have to be monotonic,
and that implies unique. Aux coord values do not have to be either monotonic
or unique.  String-valued coord vars can only be auxiliary.

Best wishes

Jonathan


- Forwarded message from John Caron  -

> Date: Sun, 5 Oct 2014 04:37:48 -0600
> From: John Caron 
> To: "Hedley, Mark" 
> CC: "cf-metadata@cgd.ucar.edu" 
> Subject: Re: [CF-metadata] string valued coordinates
> 
> >I understand that netCDF coordinate variables have to be strictly
> monotonic, and no-one wants to define what this means for the general case
> of strings; that is fine.
> 
> in CDM, monontonicity is required to make the 1D coordinate maps
> invertible. For string valued coordinates, the equivilent requirement is
> uniqueness. Im not sure if CF data model states this or not.

> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


- End forwarded message -
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] string valued coordinates

2014-10-05 Thread John Caron

>I understand that netCDF coordinate variables have to be strictly
monotonic, and no-one wants to define what this means for the general case
of strings; that is fine.

in CDM, monontonicity is required to make the 1D coordinate maps
invertible. For string valued coordinates, the equivilent requirement is
uniqueness. Im not sure if CF data model states this or not.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] string valued coordinates

2014-10-03 Thread Karl Taylor


Hi Mark,

One example I know of:

area_type is a string type variable with standard values taken from:
http://cfconventions.org/Data/cf-standard-names/27/src/area-type-table.xml

This was used in CMIP5.  The units in the standard name table are given 
as "1".


best regards,
Karl

On 10/3/14, 3:59 AM, Hedley, Mark wrote:

Hello CF

I understand that netCDF coordinate variables have to be strictly 
monotonic, and no-one wants to define what this means for the general 
case of strings; that is fine.


But I believe that I can create a CF auxiliary coordinate with string 
values without any concern.


I am interested in whether there are cases in the standard names table 
which explicitly state that a certain standard name should have string 
values?


How might this be stated?

Do we have a canonical unit of 'no_unit' available?

thank you
mark


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] string valued coordinates

2014-10-03 Thread Jim Biard


Ben,

Section 3.1 of the CF Standard says, " The|units|attribute is required 
for all variables that represent dimensional quantities". Also, "Units 
are not required for dimensionless quantities. A variable with no units 
attribute is assumed to be dimensionless."


A string coordinate is not "dimensional", and thus a units attribute is 
not required. Chapter 6 describes label coordinates (the name given to 
string valued coordinates).


Grace and peace,

Jim

On 10/3/14, 10:16 AM, Ben Hetland wrote:

On 2014-10-03, Jim Biard  wrote:

The 'no units' case is covered by leaving off the units attribute.

Wouldn't that be in violation of the CF convention?
I was under the impression that _all_ dimensional quantities need that attribute, and a 
"coordinate" would by its very nature always imply a dimensional aspect, or is 
there something I've missed?

If it were a 'dimensionless' value, using just "1" as a udunits string would work fine, but here I suppose 
the request is more along the lines of an _undefined_ unit (as in "missing", "unknown" or "not 
applicable").



On 10/3/14, 6:59 AM, Hedley, Mark wrote:
But I believe that I can create a CF auxiliary coordinate with string values 
without any concern.

Perhaps you could provide some concrete examples where you think a string as 
such (*) may be used as a coordinate or dimension?


-+-Ben-+-

[*] i.e., the string is not just an alternative representation of some numeric 
value or scale, which it could have been converted into by means of a defined 
process.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


--
CICS-NC  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: jbi...@cicsnc.org
o: +1 828 271 4900




___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] string valued coordinates

2014-10-03 Thread Ben Hetland

On 2014-10-03, Jim Biard  wrote:
> The 'no units' case is covered by leaving off the units attribute.

Wouldn't that be in violation of the CF convention?
I was under the impression that _all_ dimensional quantities need that 
attribute, and a "coordinate" would by its very nature always imply a 
dimensional aspect, or is there something I've missed?

If it were a 'dimensionless' value, using just "1" as a udunits string would 
work fine, but here I suppose the request is more along the lines of an 
_undefined_ unit (as in "missing", "unknown" or "not applicable").

> On 10/3/14, 6:59 AM, Hedley, Mark wrote:
> But I believe that I can create a CF auxiliary coordinate with string values 
> without any concern.

Perhaps you could provide some concrete examples where you think a string as 
such (*) may be used as a coordinate or dimension?

-+-Ben-+-

[*] i.e., the string is not just an alternative representation of some numeric 
value or scale, which it could have been converted into by means of a defined 
process.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] string valued coordinates

2014-10-03 Thread Jim Biard


Mark,

The 'no units' case is covered by leaving off the units attribute.

Jim

On 10/3/14, 6:59 AM, Hedley, Mark wrote:

Hello CF

I understand that netCDF coordinate variables have to be strictly 
monotonic, and no-one wants to define what this means for the general 
case of strings; that is fine.


But I believe that I can create a CF auxiliary coordinate with string 
values without any concern.


I am interested in whether there are cases in the standard names table 
which explicitly state that a certain standard name should have string 
values?


How might this be stated?

Do we have a canonical unit of 'no_unit' available?

thank you
mark


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


--
CICS-NC  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: jbi...@cicsnc.org
o: +1 828 271 4900




___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] string valued coordinates

Re: [CF-metadata] string valued coordinates

Re: [CF-metadata] string valued coordinates

Re: [CF-metadata] string valued coordinates

Re: [CF-metadata] string valued coordinates

Re: [CF-metadata] string valued coordinates

Re: [CF-metadata] string valued coordinates (unitless quantities)

Re: [CF-metadata] string valued coordinates

Re: [CF-metadata] string valued coordinates (unitless quantities)

Re: [CF-metadata] string valued coordinates

Re: [CF-metadata] string valued coordinates

Re: [CF-metadata] string valued coordinates

Re: [CF-metadata] string valued coordinates

Re: [CF-metadata] string valued coordinates

Re: [CF-metadata] string valued coordinates

Re: [CF-metadata] string valued coordinates

Re: [CF-metadata] string valued coordinates

Re: [CF-metadata] string valued coordinates

Re: [CF-metadata] string valued coordinates

Re: [CF-metadata] string valued coordinates

Re: [CF-metadata] string valued coordinates

Re: [CF-metadata] string valued coordinates

Re: [CF-metadata] string valued coordinates

Re: [CF-metadata] string valued coordinates

Re: [CF-metadata] string valued coordinates

Re: [CF-metadata] string valued coordinates

Re: [CF-metadata] string valued coordinates

Re: [CF-metadata] string valued coordinates

28 matches

Site Navigation

Mail list logo

Footer information