GDAL/PAM .kea.aux.xml file not removed by Driver.Delete()

[neilflood]

If GDAL is configured to use PAM, and a histogram is added, this will generate a .kea.aux.xml file. When the .kea file is deleted using gdal.Driver.Delete(), it does not remove the .kea.aux.xml file. It should, since that is kind of the purpose of using Driver.Delete().

Not at all urgent, I just thought I would mention it.

A minimal example can be seen with the following Python code (using RIOS to do statistics, just for convenience, as this generates the aux file)

#!/usr/bin/env python
"""
Test KEA's gdal.Driver.Delete operation. It currently fails
to delete an associated .aux.xml file.
"""
import os

import numpy
from osgeo import gdal

from rios import calcstats, cuiprogress

gdal.UseExceptions()

def main():
    print("GDAL version:", gdal.__version__)

    filename = 'test.kea'
    drvr = gdal.GetDriverByName('KEA')
    n = 100
    ds = drvr.Create(filename, n, n, 1, gdal.GDT_Byte)
    band = ds.GetRasterBand(1)
    arr = numpy.zeros((n, n), dtype=numpy.uint8)
    arr[n//2:, :] = 50
    band.WriteArray(arr)
    # Compute statistics, to get a .aux.xml file
    # (assuming our GDAL has PAM enabled)
    progress = cuiprogress.SilentProgress()
    calcstats.addStatistics(ds, progress)
    del band
    del ds

    auxFile = filename + '.aux.xml'
    haveAux = os.path.exists(auxFile)
    if haveAux:
        print("Have aux file '{}'".format(auxFile))

    drvr.Delete(filename)

    if haveAux and os.path.exists(auxFile):
        print("Aux file not removed")
    elif haveAux:
        print("Aux file removed")

if __name__ == "__main__":
    main()

[gillins]

Good spotting. Yes I have been mystified why there is an .aux.xml file at all, but recently discovered that the KEADataset is derived from GDALPamDataset rather than plain old GDALDataset. I have no idea why I did this, maybe blindly copied other code. I think this is why the .aux.xml file gets created. I think this file is redundant because we actually store everything we need in the KEA file (RAT, stats etc). Although I do see that there is some info in here the file, not sure what that is about.

So... a proper fix would be to change the inheritance in the code, then this file wouldn't be created in the first place. Would have to do a bunch of testing, plus make the change upstream in GDAL's copy of the driver...

[neilflood]

Ah, that inheritance thing makes sense. I had also been a bit puzzled, but had assumed that the PAM code was just generally more forceful than one might like. However, the inheritance from GDALPamDataset sounds like the right clue.

It is not causing any problems, so that can just be one for when you have the energy.