[gdal-dev] gdal_edit.py -a_nodata none

[Kyle Shannon]

On Fri, Aug 23, 2013 at 4:35 PM, Even Rouault
<even.rouault at 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 <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.

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