[CF-metadata] Add new integer types to CF?

Jim Biard jbiard at cicsnc.org
Mon Sep 25 09:13:56 MDT 2017


The valid_* way of showing that data contained in a signed integer type 
should be treated as unsigned, and the netCDF User Guide (NUG) _Unsigned 
way of doing so, are both intended to indicate that the user should take 
the binary values stored in the variable and interpret them as unsigned 
values rather than signed. So, a value of 0xff stored in a "byte" 
variable should be interpreted as 255 rather than -1. In order for the 
valid_* method to work, the attributes must be of a type with more bytes 
than the variable itself (short for byte, integer for short, out of luck 
for integer) so that they  can store the unsigned range values (such as 
0 - 255).

The _Unsigned method is much less ambiguous. I have this sense that 
there was a discussion of the _Unsigned attribute in the past, and that 
some were opposed to it's use, but I can't find the thread.

Regardless, the point (as made in another email in this thread) is to 
provide a clear way for netCDF-3 files written with older versions of 
the netCDF library (which didn't support unsigned types) to indicate 
that values should be treated as unsigned.

People here at NCEI have used the _Unsigned attribute in netCDF-3 files 
to indicate that a variable should be interpreted as unsigned, so there 
definitely are files "in the wild" that use this attribute.

Grace and peace,


On 9/22/17 1:36 PM, Manning, Evan M (398B) wrote:
> I think the _Unsigned attribute would have been a grand idea before.
> But if we’re now allowing explicit unsigned types, what purpose does it serve?
> Do I use the _Unsigned = “true” attribute on every ubyte, ushort, and uint variable?  They’re already clearly unsigned according to the type definition.
> it would only be useful if I wanted to keep declaring the variables as byte but wanted folks to treat them as ubyte.  This seems perverse.
> And would we start putting _Unsigned = “false” on all of our integer variables?  All numeric variables?
> Also note that fully supporting the new types means we can have unsigned integer global attributes.  Since attributes can’t have attributes, _Unsigned and valid_ don’t help here.
>    -- Evan
> On 9/22/17, 9:55 AM, "Signell, Richard" <rsignell at usgs.gov> wrote:
>      Folks,
>      I suggested
>      _Unsigned = "true"
>      because that is  already supported by Unidata:
>      http://www.unidata.ucar.edu/software/netcdf/docs/BestPractices.html#bp_Unsigned-Data
>      http://www.unidata.ucar.edu/mailing_lists/archives/netcdf-java/2013/msg00087.html
>      @Unidata: are you guys are you going to chime in on this?
>      On Fri, Sep 22, 2017 at 12:40 PM, Charlie Zender <zender at uci.edu> wrote:
>      > _Unsigned = "true" is cleaner and clearer to me
>      > than the valid_* attributes.
>      > To me, Rich's suggestion requires a consensus
>      > to _drop_ valid_* in CF 1.8, and instead make
>      > _Unsigned the preferred workaround for file formats
>      > that do not support unsigned types.
>      > Unless people want to require _both_
>      > _Unsigned and valid_* (seems burdensome to me),
>      > or allow either _Unsigned or valid_* (seems
>      > crufty to me). What do others think?
>      >
>      > On 9/22/17 04:49, Signell, Richard wrote:
>      >>
>      >> lookin at the NUG, how about saying:
>      >>
>      >> In file types that don't offer native support for unsigned types,
>      >> integer or byte variables that are to be interpreted as unsigned must
>      >> have the attribute _Unsigned = "true".
>      >
>      > --
>      > Charlie Zender, Earth System Sci. & Computer Sci.
>      > University of California, Irvine 949-891-2429 )'(
>      >
>      --
>      Dr. Richard P. Signell   (508) 457-2229
>      USGS, 384 Woods Hole Rd.
>      Woods Hole, MA 02543-1598
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> 	*Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/>
/formerly NOAA’s National Climatic Data Center/
151 Patton Ave, Asheville, NC 28801
e: jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>
o: +1 828 271 4900

/Connect with us on Facebook for climate 
<https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics 
<https://www.facebook.com/NOAANCEIoceangeo> information, and follow us 
on Twitter at @NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and 
@NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20170925/b228b3e1/attachment-0001.html>

More information about the CF-metadata mailing list