Hi.
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,
Jim
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
>
> _at_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 _at_NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and
_at_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.html>
Received on Mon Sep 25 2017 - 09:13:56 BST
