[PATCH] New option for gdal_calc.py

[CYesson]

I have implemented a new option to gdal_calc.py to deal with a specific request about processing layers of different data types.

The old version performs calculations using the native data type of the original input layers, which can be problematic if, say, you are dividing two integers and expect a float output.

The new feature --CalcAsDT will convert the input data to the output data type prior to calculation and thus bypass the above problem. I have not implemented this as the default option because of the potential hit to performance for larger files.

I have attached the new version of gdal_calc.py and a diff from the previous version

• Chris Yesson

[CYesson]

New version of gdal_calc.py with new option

[CYesson]

diff of old gdal_calc.py and new version

[Even Rouault]

For consistency with other utilities, I would instead suggest -ot (output type) for the name of the option, like in gdal_translate or gdalwarp, if that type is the type of the output file. If it is just an indermediate working type, -wt (working type) could be more appropriate (like in gdalwarp).

[CYesson]

gdal_calc.py with working type option as --wt and other options changed for consistency (--ot and --of)

[CYesson]

Thanks for the comment.

I have implemented the notation changes mentioned above for greater consistency with other gdal tools. I have used --wt for working data type and --of for format and --ot for output data type. Note that the optparse package used by gdal_calc to handle options does not accept 2 character options with the single dash "-" notation.

I have uploaded a new version of gdal_calc with these options.

[warmerdam]

In terms of consistency it is not helpful to use --ot, --of and --wt instead of -ot, -of and -wt. I would suggest dispatching with optparse and doing the option processing more conventionally.

[Jukka Rahkonen]

Did this process really stop to considerations about if the options should be "--ot, --of and --wt" or "-ot, -of and -wt"?

[Even Rouault]

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.