[gdal-dev] gdal_edit.py -a_nodata none

[Even Rouault]

Le vendredi 23 août 2013 23:21:06, Kyle Shannon a écrit :
> On Fri, Aug 23, 2013 at 10:04 AM, Hermann Peifer <peifer at gmx.eu> wrote:
> > On 2013-08-23 15:23, Even Rouault wrote:
> >> Selon peifer <peifer at gmx.eu>:
> >>> Hi,
> >>> 
> >>> http://www.gdal.org/gdal_edit.html states about -a_nodata
> >>> 
> >>>> Assign a specified nodata value to output bands.
> >>>> Can be set to none to remove a nodata value if one exists for the
> >>>> dataset.
> >>> 
> >>> I assume that none means the literal string `none', but what happens is
> >>> given below.
> >>> 
> >>> Is this just a plain bug or am I doing something terribly wrong?
> >> 
> >> Hi Hermann,
> >> 
> >> This is a documentation bug. This is not supported by the code. And
> >> there's no
> >> (standard) way in the GDAL API to remove a nodata value once it is set.
> >> 
> >> Could you file a ticket about that ?
> > 
> > Done, see http://trac.osgeo.org/gdal/ticket/5213
> > 
> > Hermann
> > 
> > 
> > _______________________________________________
> > gdal-dev mailing list
> > gdal-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
> 
> Even,
> According to the docs at
> http://gdal.org/classGDALRasterBand.html#ac6f081d253dee55c372e54cfdd8f05a6
> 
> """To clear the nodata value, just set it with an "out of range"
> value. Complex band no data values must have an imagery component of
> zero."""
> 
> This seems a little unreliable though, especially if changing the data
> type in gdal_translate or some other app.  If the no data value is
> copied and is within the new range for the new data type, the behavior
> is unexpected(I think).  Should the docs state that once a no data
> value is set, in cannot be unset as well?  I'm a bit confused.

Yes, there's no definitive and clean way of unsetting a nodata value once it is 
set. Practically, you can workaround that by setting it to out of range. I'm 
not sure that conversion to a wider type will cause problems however, if the 
pixel values remain unchanged. For example if you have a byte pixel type, and 
pick -1 as nodata value, then translating it to signed int 16 will not really 
cause problems (immediately) since the pixel values will remain in the [0-255] 
range. Of course if the data is edited afterwards, then -1 coud be assigned to 
a pixel.

Feel free to edit the doc to add some caution wording.

Ideally the API should have a ClearNoDataValue() method. I'm not sure that 
many file formats could really implement it. PAM storage of course could 
support that. GeoTIFF probably too be erasing the GDAL_NODATA tag.

Even

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html