Hi all,
> * If the standard_name attr contains the "count" modifier, the quantity is
> dimensionless. The checker should take standard_name modifiers into account
> (Appendix C) as well as the canonical units from the standard name table
> (and the cell_methods) when deciding what units a quantity can have. This is
> not explicitly stated in the conformance document, but it should be. I will
> create a trac defect ticket for that.
I failed to find the count modifier (or even the word "count") anywhere
in the CF documents. So far I have not considered it a valid modifier at
all - I can see its usefulness, though. If I did not overlook something,
then maybe it should be added?
>
> *> I think it is wrong to add a "bounds" attribute to a formula term
>> attached to a vertical coordinate. Only the coordinate itself
>> should have a bounds attribute.
>
> The CF standard doesn't clarify that. It doesn't say whether formula terms
> can have bounds, or whether bounds can have formula terms, or both. If both,
> then they have to be consistent somehow. We should clarify this, I think.
> You think bounds should have formula terms (if applicable) but not vice-versa,
> is that right? What does anyone else think?
This is a very interesting question indeed. Supporting both would
probably make things more complicated than they have to be. I find it
more logical for bounds to have formula terms than the other way around.
When processing data you would first find the bounds and then collect
their formula terms. To me that way feels more natural.
>
> *> The reason this seemed to fix the problem is presumably that the CF
>> checker does not require (or look for?) units to be attached to
>> bounds variables; the units are by convention the same as the
>> coordinate variable itself.
>
> In fact the conformance document says
>
> "If a boundary variable has units or standard_name attributes, they must agree
> with those of its associated variable."
I think this needs more clarification. My interpretation of this
statement was that bounds variables inherit the units from their
coordinate variables.
Other things don't make much sense to me. Using different units in those
places just leads to more confusion and has no practical value that I
can see right now. If different units should be allowed for some reason,
then I recommend changing the statement above to
"If a boundary variable has units or standard_name attributes, they must
be compatible with those of its associated variable."
At least to me that would make it clear that the units do not have to be
exactly the same but they have to be compatible/convertible. An
additional convention could be that missing units on bounds variables
imply that they are identical to their coordinate variable's units.
Regards,
Michael
--
Michael Decker
Forschungszentrum J?lich
Institut f?r Energie- und Klimaforschung - Troposph?re (IEK-8)
Tel.: +49 2461 61-3867
E-Mail: m.decker at fz-juelich.de
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5957 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20110224/daf0c4a4/attachment.bin>
Received on Thu Feb 24 2011 - 06:21:38 GMT
