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:[email protected]] On Behalf Of
[email protected]
Sent: Tuesday, November 04, 2014 5:38 PM
To: [email protected]
Subject: CF-metadata Digest, Vol 139, Issue 4
Send CF-metadata mailing list submissions to
[email protected]
Message: 2
Date: Tue, 4 Nov 2014 16:38:12 +0000
From: "Hedley, Mark" <[email protected]>
To: Jim Biard <[email protected]>, "[email protected]"
<[email protected]>
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 [[email protected]] on behalf of Jim Biard
[[email protected]]
Sent: 31 October 2014 15:18
To: [email protected]
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.
[...]
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
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
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
