[gdal-dev] netCDF signed nodata value

[Simon Lyngby Kokkendorff]

I can also confirm that with -co FORMAT=NC4 everything seems to work as
expected, also with other netCDF readers...
Thanks again,
Simon


On Tue, Oct 27, 2015 at 9:03 PM, Simon Lyngby Kokkendorff <silyko at gmail.com>
wrote:

> Thanks for the tips Kyle and Even and for the quick fix!
> Not a big netCDF user myself, but have noticed that it seems to be the
> standard format for many of my colleagues who work in climatology. So good
> to get this fixed!
>
> Cheers,
> Simon
>
>
> On Tue, Oct 27, 2015 at 6:08 PM, Even Rouault <even.rouault at spatialys.com>
> wrote:
>
>> Le mardi 27 octobre 2015 16:54:56, Kyle Shannon a écrit :
>> > Simon,
>> >
>> > On Mon, Oct 26, 2015 at 5:04 PM, Simon Lyngby Kokkendorff
>> >
>> > <silyko at gmail.com> wrote:
>> > > Hello list,
>> > >
>> > >    Just observed a puzzling behaviour of the netCDF driver. When
>> creating
>> > >    a
>> > >
>> > > netCDF dataset of Byte type, the netCDF driver seems to interpret the
>> > > nodata value as a signed byte.
>> > >
>> > >  For example a nodata value assigned with -a_nodata 200, will become
>> -56.
>> > >  Of
>> > >
>> > > course one can work around this by simply casting the nodata value (as
>> > > e.g. returned by band.GetNoDataValue()) to an unsigned byte.
>> >
>> > It appears the driver has a sort of data type mis-match with no data
>> > and the band type.  A work around, if available, is to set FORMAT=NC4
>> > as a creation option.  I am not sure if it is in gdal or the netcdf
>> > library at this point.
>>
>> My understanding is netCDF 3 only supports signed byte and GDAL uses a
>> special
>> metadata item _Unsigned=True to correct the interpretation. But it failed
>> to
>> use it to interpret correctly the nodata value. Should be fixed by
>> https://trac.osgeo.org/gdal/ticket/6175 (happy to have feedback from
>> anyone
>> more knowleagable)
>>
>> --
>> Spatialys - Geospatial professional services
>> http://www.spatialys.com
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20151028/41f34a3b/attachment-0001.html>