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

[vincent at ecovla.nl]

Frank Warmerdam wrote:
> 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,

OK, I understand. It is indeed gdal_merge.py's layer stacking feature
('-separate') that I use, to re-unite sds's from an aster hdf file
(which gdal_translate does not see as one file with several bands).
Because I'd like to view several aster scenes together, I needed the
0's, which are nodata in the original files till they encounter
gdal_merge which doesn't propagate them as nodata, to be nodata to
prevent them from overlapping other good aster data. I think nodata
value propagation is a 'good thing', even in gdal_merge.py, but I fully
understand that you don't want to spend too much time on it. Alas
gdal_translate lacks an option to add a nodata value, otherwise that
would be a solution. Currently there is no other way to have the nodata
value set after using gdal_merge.py, then this 'fix' or creating a vrt
file and editing by hand (which I don't want to do with 500+ scenes...).
So for now I'll keep my fix. But I like the ability of gdal_merge to
create a multilayer file from different single layer files, so please
don't wipe gdal_merge till we have a good substitute for that... :-)
Btw should I file an enhancement request in bugzilla for a -dst_nodata
option for gdal_translate, to be able to add a nodata setting to the
destination file? Or are there caveats for this which I overlook now? I
think this would be a nice and handy and logical extra function of
gdal_translate.

Regards,
Vincent.