gdal_translate and .aux.xml files

[Even Rouault]

In the following scenario :

apps/gdal_translate  -co "COMPRESS=DEFLATE" ../../CADRG/001zc013.on1 001zc013.tif
apps/gdal_translate  ../../CADRG/001zc013.on1 001zc013.tif

the resulting 001zc013.tif will containing into it's GDAL specific tag "COMPRESSION=DEFLATE" because at first step a 001zc013.tif.aux.xml has been produced containing this item. To avoid this problem, one must delete the .aux.xml file before the second gdal_translate.

This behaviour has been introduced with metadata output enabled by default.

Frank's point of view :

[20:11] <FrankW> I think it is a problem, but I don't think it is appropriate for gdal_translate to specifically delete the .aux.xml file.

[20:11] <FrankW> One possibility might be for gdal_translate to try and open the destination dataset, and if successful to use the corresponding driver to delete the destination driver before re-creating.

[20:12] <FrankW> This would result in the .aux.xml file being cleaned up.

[20:12] <FrankW> Or perhaps GDALCreate() ought to do that.

[warmerdam]

This particular problem seems to be gone now. COMPRESS is now in the IMAGE_STRUCTURE comain and this is not copied by gdal_translate and so it does not appear in the .aux.xml file.

However, there is a general issue that gdal_translate and the Create() call will replace an existing file without removing or necessarily replacing all it's associated files. I can reproduce this, for instance, with the sequence:

gdal_translate -of PNM utm.tif out.pnm 
gdal_translate -of PNM raw.png out.pnm

The out.pnm.aux.xml produced by the first translation is left around applying to the second.

[warmerdam]

I have modified (r12704) GDALDriver::Create() and GDALDriver::CreateCopy() to pre-delete the target files using the appropriate delete technology. This cleans up hanging .aux.xml files, etc.