⇐ ⇒

[CF-metadata] Units micro prefix "u" deprecated in udunits-2

From: Lowry, Roy K <rkl>
Date: Sat, 27 Mar 2010 09:07:22 +0000

Dear All,

A further watch-point is that a some character mappings convert the micro sign to 'm' which has caused us some embarrassing errors in the past when interpreted as 'milli'. As Eizi so comprehensively points out, we either need to either ensure that character encodings are either explicitly stated and rigorously managed by applications or stick to the abbreviation 'u' for micro. Our current policy is the latter.

Cheers, Roy.
________________________________________
From: cf-metadata-bounces at cgd.ucar.edu [cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Eizi TOYODA [toyoda at gfd-dennou.org]
Sent: 27 March 2010 00:49
To: Andrew Clegg
Cc: cf-metadata at cgd.ucar.edu; Julien Demaria
Subject: Re: [CF-metadata] Units micro prefix "u" deprecated in udunits-2

Hi all,

Nobody here is trying to discourage the use of micro sign. What
character encoding are you going to use?

Micro sign (http://www.fileformat.info/info/unicode/char/00b5/index.htm)
is single byte 0xB5 in Latin-1 (aka ISO-8859-1) but becomes
double-byte 0xC2 0xB5 in UTF-8. There is also confusing Greek small
letter mu (http://www.fileformat.info/info/unicode/char/03bc/index.htm)
which is 0xCE 0xBC. In short this letter is bad for computer
processing if we don't have mechanism to specify character encoding.

UDUNITS 2 API has "encoding" argument, and users can choose either
ASCII, Latin-1, or UTF-8. Accordingly "udunits2" command has options
-A -L and -U. It is enough for library that users have control and
responsibility. But CF is a standard of metadata that is exchanged
among people to avoid confusion.

The CF community can choose many ways. I'd like to see views on the community:

(1) Create a global attribute to specify character encoding (like XML)
      I believe this won't work.
(2) Declare that CF uses UTF-8
      Probably many people simply ignore that and put single 0xB5 as micro sign.
(3) Recommends only US-ASCII letters in "units" attribute
      Very conservative, but that is consistent with allowing only
English in standardized attributes.
(4) Do nothing
      I have to warn programmers to anticipate any byte pattern above.
      That would work if only micro sign is an extension to ASCII.

Best Regards,
--
Eiji (aka Eizi) TOYODA
Japan Meteorological Agency / WMO/CBS/IPET-MDI
On Sat, Mar 27, 2010 at 00:52, Andrew Clegg <ancl at pml.ac.uk> wrote:
> Hi Julien,
>
> I'm glad you brought this up. We had a discussion about this recently (look
> for any threads with 'udunits 1 or 2 for CF' in the title):
>   http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2010/thread.html
>
> The best solution (in my opinion) was to use expanded names rather than
> shortened, so instead of using 'u' (which has been replaced by '?' in
> udunits2) you would use 'micro' (which is compatible with both). However it
> would be nice to get a consensus on this or another solution, and some text
> added to the conventions.
>
> Cheers,
> Andrew Clegg
>
>
> Julien Demaria wrote:
>>
>> Hi,
>>
>> I found the "u" micro prefix abbreviation in the current CF-1.4
>> documentation on units:
>>
>> http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.4/cf-conventions.html#units
>>
>> but it seems this prefix is not available in the last udunits-2 (udunits-1
>> is now deprecated)
>>
>> and in udunits-2 they break backward compatibility because the "u" symbol
>> is now used for a new unit "unified_atomic_mass_unit", see in
>>
>> http://www.unidata.ucar.edu/software/udunits/udunits-2/udunits2-accepted.xml
>>
>> http://www.unidata.ucar.edu/software/udunits/udunits-2/udunits2-prefixes.xml
>>
>> So what is the position of the CF community concerning this point, is the
>> "u" micro prefix CF-1.4 compliant or not?
>>
>>
>> Thanks in advance,
>>
>> Julien
>>
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
> --------------------------------------------------------------------------------
> Plymouth Marine Laboratory
>
> Registered Office:
> Prospect Place The Hoe
> Plymouth  PL1 3DH
>
> Website: www.pml.ac.uk
> Registered Charity No. 1091222
> PML is a company limited by guarantee
> registered in England & Wales
> company number 4178503
>
> PML is a member of the Plymouth Marine Sciences Partnership
> Website: www.pmsp.org.uk
> --------------------------------------------------------------------------------
> This e-mail, its content and any file attachments are confidential.
>
> If you have received this e-mail in error please do not copy, disclose it to
> any third party or use the contents or attachments in any way. Please notify
> the sender by replying to this e-mail or e-mail forinfo at pml.ac.uk and then
> delete the email without making any copies or using it in any other way.
>
> The content of this message may contain personal views which are not the
> views of Plymouth Marine Laboratory unless specifically stated.
>
> You are reminded that e-mail communications are not secure and may contain
> viruses. Plymouth Marine Laboratory accepts no liability for any loss or
> damage which may be caused by viruses.
> --------------------------------------------------------------------------------
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
-- 
This message (and any attachments) is for the recipient only. NERC
is subject to the Freedom of Information Act 2000 and the contents
of this email and any reply you make may be disclosed by NERC unless
it is exempt from release under the Act. Any material supplied to
NERC may be stored in an electronic records management system.
Received on Sat Mar 27 2010 - 03:07:22 GMT

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

⇐ ⇒