Le vendredi 23 août 2013 23:21:06, Kyle Shannon a écrit : > On Fri, Aug 23, 2013 at 10:04 AM, Hermann Peifer <[email protected]> wrote: > > On 2013-08-23 15:23, Even Rouault wrote: > >> Selon peifer <[email protected]>: > >>> 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 > > [email protected] > > 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 _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
