[gdal-dev] Fillvalue set incorrectly on gdal_translate to NetCDF for Byte

[Even Rouault]

On mercredi 27 septembre 2017 10:00:23 CEST Julian Zeidler wrote:
> Hi all,
> 
> I noticed, what I believe is an Error when converting a Byte Image from
> geotiff to Netcdf. In the newest Gdal Version (trunk from Monday),  it
> reports the correkt NoData Value (in older gdal Version  i tested this
> 1.11 this was also incorrekt) but it reports the _FillValue as -1 while
> reporting that the Dataset is _Unsigned. This looks like the FillValue
> is written as a signed byte (For Na=254 it reports fillvalue=-2).
> 
> Is this difference between noData and _FillValue intentional? And is
> there any way to "fix" the FillValue in my Netcdf ?
> 
> I ran  gdal_translate example.tif example.nc -of netCDF
> 
> The tiff reports the (korrekt) NaValue as :
> 
> Band 1 Block=2000x4 Type=Byte, ColorInterp=Gray
>    NoData Value=255
> 
> While in the NetCDF I get :
> 
> Band 1 Block=2000x1 Type=Byte, ColorInterp=Undefined
>    NoData Value=255
>    Metadata:
>      grid_mapping=transverse_mercator
>      long_name=GDAL Band Number 1
>      NETCDF_VARNAME=Band1
>      valid_range={0,255}
>      _FillValue=-1
>      _Unsigned=true

Julian,

this is an artifact of the old netCDF3 format (which is the default when reating a file with 
GDAL), which doesn't support unsigned byte, but signed byte. So GDAL has to use hacks to 
put unsigned byte to signed byte.
It sets a Band1:_Unsigned = "true" metadata, and then on reading, it knows that it must 
interpret signed as unsigned. The _FillValue=-1 just reflects that. That is what you will get if 
you use the "ncdump" utility. I'm ambivalent if GDAL should "fix" it or not.
Recent versions of GDAL do fix the NoData value since that's what users should use. The 
_FillValue is more an internal implementation detail.

As netCDF 4 is quite widespread now, you could also just do

gdal_translate example.tif example.nc -of netCDF -co FORMAT=NC4

and then everything will be unsigned.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170927/fde67da6/attachment.html>