[gdal-dev] gdalwarp's default nodata value

[Chaitanya kumar CH]

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.

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> 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> 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/0b064ce4/attachment-0001.html