[Gdal-dev] gdal_merge.py not setting NoDataValue for dst files

[Frank Warmerdam]

On Apr 12, 2005 8:21 AM, Vincent Schut <vincent at ecovla.nl> wrote:
> Frank,
> 
> is it on purpose that gdal_merge.py does not set the nodata value of the
> resulting file?
> 
> I 'fixed' this for myself by adding "t_band.SetNoDataValue(nodata)" in
> raster_copy_with_nodata (line 141). Is this appropriate?

Vincent, 

This isn't really a very general solution.  For one thing, the nodata
value specified on the commandline relates to the source file.  Pixels
of that value are not copied to the destination image.   No effort
is made to pre-initialize the output image to any specific value so it
will normally default to zero which could be considered the output
nodata value.   Of course, we could be copying perfectly valid 
zeros into the output image, so I hesitate to mark that as a nodata
value in the output image. 

If we wanted to handle this properly we would need another 
"-dstnodata" switch or something similar that would (if used) cause
the output image to be pre-initialized to that value, and record it
as the nodata value for the desination image. 

However, it is really my intention to phase out gdal_merge.py, so
I hate to spend too much time working on it.  It is really a "poor cousin"
to the gdalwarp program which is much more general.  It continues
to be useful mainly because it has the ability to work on a bunch of
images in one invocation, and because it has the -seperate stacking
feature.  

Of course, your change may be adequate for your needs if the
input and output are both using 0 for the nodata value. 

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent