Opened 7 years ago

Closed 5 years ago

#6779 closed defect (wontfix)

gdal_merge strips nodata values

Reported by: marisn Owned by: warmerdam
Priority: normal Milestone: closed_because_of_github_migration
Component: Utilities Version: 2.1.0
Severity: normal Keywords: gdal_merge
Cc:

Description

If a GeoTIFF with defined nodata value is passed to gdal_merge, the output has no nodata value defined and all nodata values are replaced by 0.

Test by taking any tiff file with defined nodata (as reported by gdalinfo) and run gdalmerge -o out.tif in.tif (I'll attach file for testing)

Attachments (2)

tile2.tif (2.5 KB ) - added by marisn 7 years ago.
GeoTIFF with defined nodata value
singletile.tif (751 bytes ) - added by marisn 7 years ago.
gdal_merge.py -o singletile.tif -co COMPRESS=DEFLATE tile2.tif

Download all attachments as: .zip

Change History (6)

by marisn, 7 years ago

Attachment: tile2.tif added

GeoTIFF with defined nodata value

by marisn, 7 years ago

Attachment: singletile.tif added

gdal_merge.py -o singletile.tif -co COMPRESS=DEFLATE tile2.tif

comment:1 by Jukka Rahkonen, 7 years ago

Gdal_merge.py has a documented option http://www.gdal.org/gdal_merge.html for assigning the nodata value

-a_nodata output_nodata_value:
    (GDAL >= 1.9.0) Assign a specified nodata value to output bands.

You may need to use it with another option

-n nodata_value:
    Ignore pixels from files being merged in with this pixel value.

Do you still consider this is a bug for some reason?

in reply to:  1 comment:2 by marisn, 7 years ago

Replying to jratike80:

Gdal_merge.py has a documented option http://www.gdal.org/gdal_merge.html for assigning the nodata value

Taking into account that it is called gdal_merge not gdal_merge_and_replace_nodata_with_zero, yes. As a minimum, documentation should be updated to clearly state that input nodata areas will be mangled unless -n is used. Judging by current documentation I would use "-n" only if gdalinfo does not report nodata value.

At the moment I have found a safe workaround - first use gdalbuildvrt followed by gdal_translate - and I get nice merged output with all of holes preserved and no need to remember about gdal_merge feeling "special".

comment:3 by Jukka Rahkonen, 7 years ago

Please suggest how to improve the documentation.

Gdal_mergge.py is relatively simple Python script https://trac.osgeo.org/gdal/browser/trunk/gdal/swig/python/scripts/gdal_merge.py. I guess it could be somehow tricky to make is handle nodata automatically if source files are heterogeneous: some having nodata set, some not, or with different nodata, some with alpha channel instead of nodata etc. I also guess that patches are welcome (I am not programmer myself).

comment:4 by Even Rouault, 5 years ago

Milestone: closed_because_of_github_migration
Resolution: wontfix
Status: newclosed

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to https://github.com/OSGeo/gdal/issues if it is not already reported there.

Note: See TracTickets for help on using tickets.