[Gdal-dev] gdal_merge.py not setting NoDataValue for dst files
vincent at ecovla.nl
vincent at ecovla.nl
Tue Apr 12 10:24:39 EDT 2005
Frank Warmerdam wrote:
> On Apr 12, 2005 8:21 AM, Vincent Schut <vincent at ecovla.nl> wrote:
>>is it on purpose that gdal_merge.py does not set the nodata value of the
>>I 'fixed' this for myself by adding "t_band.SetNoDataValue(nodata)" in
>>raster_copy_with_nodata (line 141). Is this appropriate?
> 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
> 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
More information about the Gdal-dev