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 <[email protected]> wrote: > On 12-05-2010 05:55, Chaitanya kumar CH wrote: > > Joaquim, > > On Wed, May 12, 2010 at 5:07 AM, Joaquim Luis <[email protected]> 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
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
