<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 12-05-2010 05:55, Chaitanya kumar CH wrote:
<blockquote
cite="mid:AANLkTikCkYbBRtyn_W5J0qE6GYGDrNDmBxX02h5IDx6k@mail.gmail.com"
type="cite">Joaquim,<br>
<br>
<div class="gmail_quote">On Wed, May 12, 2010 at 5:07 AM, Joaquim
Luis <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:jluis@ualg.pt">jluis@ualg.pt</a>></span> wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi,<br>
<br>
Before filling a ticket I would like to ask here if this gdalwarp
behavior is the intended one.<br>
When I convert a grid from geogs to UTM the nodatavalues are filled
with zeros.<br>
I get the expected behaviour if I use the -dstnodata with a numeric
value, but I found no way tom tell it use NaN.<br>
<br>
Summary<br>
<br>
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.<br>
</blockquote>
<div>NaN should always be treated as a special case in coding.
Imagine performing a type conversion.<br>
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.<br>
</div>
</div>
</blockquote>
<br>
Hi Chaitanya,<br>
<br>
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?<br>
<br>
<br>
<blockquote
cite="mid:AANLkTikCkYbBRtyn_W5J0qE6GYGDrNDmBxX02h5IDx6k@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">gdalwarp
-s_srs "+proj=latlong" -t_srs "+proj=utm +zone=29 +datum=WGS84"
swath_grid.grd lixo_utm.tiff<br>
<br>
Furthermore when I load the " lixo_utm.tiff" in Mirone is does not
recognize a nodata value, whilst if I do this instead<br>
<br>
gdalwarp -s_srs "+proj=latlong" -t_srs "+proj=utm +zone=29
+datum=WGS84" -dstnodata 1 swath_grid.grd lixo_utm.tiff<br>
<br>
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.<br>
</blockquote>
<div>Perhaps swath_grid.grd doesn't have a nodata value set.<br>
</div>
</div>
</blockquote>
<br>
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.<br>
But my real problem is with my gdalwarp_mex MEX file used in Mirone.
Even if I add this<br>
<br>
<br>
for (i = 0; i < nBands; i++)<br>
GDALSetRasterNoDataValue( GDALGetRasterBand(hDstDS,
i+1),9999999.0);<br>
<br>
the warped dataset has the correct nodata value in its metadata but the
array still has zeros where it should have 9999999.0<br>
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.<br>
<br>
Joaquim<br>
<br>
</body>
</html>