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 <[email protected]
<mailto:[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]
<mailto:[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
