[gdal-dev] gdalwarp's default nodata value

[Joaquim Luis]

On 12-05-2010 15:58, Chaitanya kumar CH wrote:
> Joaquim,
>
> GDALSetRasterNoDataValue() sets only the metadata. It doesn't actually 
> change the nodata pixels. We need to process each pixel to do this. Or 
> you could just create a VRT mentioning the source and vrt nodata values.
>

Chaitanya,

Thanks, but sorry I don't get it. I thought that it was up to the 
warping machinery to use the nodata value that it was instructed to and 
put them in the array positions of nodatavalue. If, at a certain point, 
it decides to put zeros at some memory addresses than at that point it 
should simply put the nodata value. It seams quite logic this reasoning no?

Please no VRTs since this is a pure memory operation.

> http://www.gdal.org/gdal_vrttut.html
> http://www.gdal.org/gdalbuildvrt.html
>
> On Wed, May 12, 2010 at 6:33 PM, Joaquim Luis <jluis at ualg.pt 
> <mailto:jluis at ualg.pt>> wrote:
>
>     On 12-05-2010 05:55, Chaitanya kumar CH wrote:
>>     Joaquim,
>>
>>     On Wed, May 12, 2010 at 5:07 AM, Joaquim Luis <jluis at ualg.pt
>>     <mailto:jluis at ualg.pt>> wrote:
>>
>>         Hi,
>>
>>         Before filling a ticket I would like to ask here if this
>>         gdalwarp behavior is the intended one.
>>         When I convert a grid from geogs to UTM the nodatavalues are
>>         filled with zeros.
>>         I get the expected behaviour if I use the -dstnodata with a
>>         numeric value, but I found no way tom tell it use NaN.
>>
>>         Summary
>>
>>         This puts zeros on the nodata zone, but I don't find it
>>         correct as "0" is not exactly a natural nodata value. For my
>>         habits NaN is the natural no data value.
>>
>>     NaN should always be treated as a special case in coding. Imagine
>>     performing a type conversion.
>>     Since we usually deal with real world data, we know the data
>>     value range. We should be able to choose a nodata value not in
>>     the data range.
>
>     Hi Chaitanya,
>
>     Taking your argument of the real world data, it is why the default
>     choice of zero for nodata is one of worst possible choices. At
>     least for the case of floating point data. Imagine that the input
>     grid has zeros as perfectly valid values, how will any application
>     be able to distinguish between the "good" and the "bad" zeros on
>     the warped result?
>
>
>
>>         gdalwarp -s_srs "+proj=latlong" -t_srs "+proj=utm +zone=29
>>         +datum=WGS84" swath_grid.grd lixo_utm.tiff
>>
>>         Furthermore when I load the " lixo_utm.tiff" in Mirone is
>>         does not recognize a nodata value, whilst if I do this instead
>>
>>         gdalwarp -s_srs "+proj=latlong" -t_srs "+proj=utm +zone=29
>>         +datum=WGS84" -dstnodata 1 swath_grid.grd lixo_utm.tiff
>>
>>         than "1" is recognized as the nodata. I have not investigated
>>         the metadata to see why the "0" is not set to represent the
>>         nodata.
>>
>>     Perhaps swath_grid.grd doesn't have a nodata value set.
>
>     The grid was created by GMT (it always sets a nodata value
>     defaulting no NaN) but that is not the problem. I dug a bit more
>     on this and actually there is no problem at all in what respects
>     recognizing the nodata value even when I let gdalwarp use the
>     default value of zero.
>     But my real problem is with my gdalwarp_mex MEX file used in
>     Mirone.  Even if I add this
>
>
>     for (i = 0; i < nBands; i++)
>                 GDALSetRasterNoDataValue( GDALGetRasterBand(hDstDS,
>     i+1),9999999.0);
>
>     the warped dataset has the correct nodata value in its metadata
>     but the array still has zeros where it should have 9999999.0
>     I checked again against the gdalwarp.cpp code and the only
>     difference I'm able to identify is that in gdalwarp_mex I'm using
>     the MEM driver (I have to since data never lands on hard disk).
>     I'm lost on this one.
>
>     Joaquim
>
>
>
>
> -- 
> Best regards,
> Chaitanya kumar CH.
> /tʃaɪθənjə/ /kʊmɑr/
> +91-9848167848
> 17.2416N 80.1426E

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20100512/e254eb3f/attachment.html