On Fri, Aug 23, 2013 at 4:35 PM, Even Rouault <even.roua...@mines-paris.org> wrote: > Le vendredi 23 août 2013 23:21:06, Kyle Shannon a écrit : >> On Fri, Aug 23, 2013 at 10:04 AM, Hermann Peifer <pei...@gmx.eu> wrote: >> > On 2013-08-23 15:23, Even Rouault wrote: >> >> Selon peifer <pei...@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@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.
That was the situation I was referring to, when an 'invalid pixel' is suddenly allowed. > > Feel free to edit the doc to add some caution wording. > I will probably add a note, no data stuff seems to always get me. > 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. I checked a few drivers, and it appeared that GeoTIFF and HFA both have a flag that signals if the no data value has been set and is valid. It seems that the best way to handle it would be similar. Thanks for the reply. > > Even > > -- > Geospatial professional services > http://even.rouault.free.fr/services.html kss _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev