[gdal-dev] gdalwarp's default nodata value

[Joaquim Luis]

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

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