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