Opened 7 years ago

Closed 7 years ago

#5533 closed defect (invalid)

gdal_merge.py 1.11.0 missing -a_nodata

Reported by: dcd Owned by: warmerdam
Priority: normal Milestone: 1.11.1
Component: default Version: 1.11.0
Severity: normal Keywords: merge, nodata
Cc:

Description (last modified by dcd)

gdal_merge.py --version
GDAL 1.11.0, released 2014/04/16

gdal_merge.py -n 0 -a_nodata -9999 ....
Unrecognised command option: -a_nodata

The -a_nodata option was working until recently, so perhaps I've just messed something up after updating my software sources.

Change History (5)

comment:1 Changed 7 years ago by dcd

Description: modified (diff)

comment:2 Changed 7 years ago by Jukka Rahkonen

Does the command work OK without "-a_nodata -9999"?

comment:3 in reply to:  2 Changed 7 years ago by dcd

Replying to jratike80:

Does the command work OK without "-a_nodata -9999"?

I suppose it depends on what you mean by OK. Yes, it runs as expected, but no, I can't assign a "no data" value as I could before.

In terms of how this has an effect on my workflow: I use a binary mask (1,0) to mask out areas in a image representing surface reflectance (1=valid, 0=cloud, shadow, etc.). The surface reflectance imagery has a nodata value of -9999, whereas areas where the mask gets applied receive values of 0. Before, I could specify -n 0 and -a_nodata, to mask all data as -9999, and now I can't.

I'm having a heck of a time figuring out why this worked recently (last week), but isn't working now. I'm just running the same script as last week, but now -a_nodata is not an option (although the website says it should be GDAL >=1.9). Probably one to many repo changes and a few too many sudo apt-gets in the wrong order. In any case, it appears not to be an option anymore. Grep'ing the gdal_merge.py reveals no a_nodata option, although the option might be tucked somewhere else.

comment:4 Changed 7 years ago by Jukka Rahkonen

By "works OK" I was meaning that did you check that it runs without the parameter so that everything else in the command was correct and the reason could not be in some misleading error message. Obviously you had checked it.

If grep does not find "-a_nodata" then you can't have the same version of the script than last week. Because it is a script you can simply get the current version here: http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/python/scripts/gdal_merge.py

I do not believe that this is really a GDAL bug and you may had been served better through GDAL mailing list.

comment:5 in reply to:  4 Changed 7 years ago by dcd

Resolution: invalid
Status: newclosed

Replying to jratike80:

If grep does not find "-a_nodata" then you can't have the same version of the script than last week. Because it is a script you can simply get the current version here: http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/python/scripts/gdal_merge.py

It appears there are two versions of gdal_merge.py on my system, the former being from 2010 and the latter the more recent 2014 version:

/usr/local/bin/gdal_merge.py /usr/bin/gdal_merge.py

I'm not sure how this happened, or why it's referencing the older script, but I leave it here for posterity's sake.

I do not believe that this is really a GDAL bug and you may had been served better through GDAL mailing list.

In hindsight, I concur. Closing this "bug" report as invalid.

Note: See TracTickets for help on using tickets.