Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#3780 closed defect (fixed)

python GetDescription() returns empty strings on > 1.7.0

Reported by: mattrigal Owned by: warmerdam
Priority: normal Milestone: 1.8.0
Component: GDAL_Raster Version: svn-trunk
Severity: normal Keywords: pam description
Cc:

Description

Hi Frank and Even,

Thanks for your replies. From what I can see, it is not related to the aux.xml files, because this still works after deletion.

I must add that I have the same problem when working on .pix images, so it is probably not driver specific... it may be specific to the SWIG or to python...

Best Regards, Matthieu

Selon Matthieu Rigal <rigal@…>:

Matthieu,

I can reproduce in trunk too. I'm not aware that this issue was known. I'm even a bit surprised this has worked before as the SetDescription?() method in GDALPamRasterBand doesn't seem to have been ever overloaded, so a bit of investigation is necessary.

In 1.6.x branch, I suppose this worked before the band description was written in a .aux.xml file ?

Best regards,

Even

On Monday 11 October 2010 16:33:51 Frank Warmerdam wrote:

Matthieu Rigal wrote:

Hi folks,

Currently running GDAL 1.7.1, I noticed a regression towards the 1.6.x branch which I could not find in the tickets.

The GetDescription?() always seems to return empty strings, except for just created file and just setted description...

Here is a description of the bug, I don't think it is quite the expected

result :

from osgeo import gdal xT = gdal.GetDriverByName?('GTiff').Create('test-desc.tif',10,10,1) xB = xT.GetRasterBand?(1) xB.SetDescription?('test') xT = None xT2 = gdal.Open('test-desc.tif') xT2.GetRasterBand?(1).GetDescription?()

The 1.6.1 returns: 'test'

Is it a known bug ? Solved in further versions ?

Matthieu,

I confirmed the problem but was unable to reproduce correction operation against the current 1.6 branch so whatever changed appears to have changed there as well.

I presume with 1.6.1 you are seeing a .aux.xml file created - is that right?

There is no special handling of the raster band description in the geotiff driver itself, so saving it falls to the GDALPamRasterBand. I see it also has no override for SetDescription?() so it falls to GDALMajorObject to hold the description. In GDALPamRasterBand::SerializeToXML() a non-empty description will be saved to the .aux.xml file; however, SerializeToXML() is not called unless there is some record of the PAM information being dirty.

Since SetDescription?() was not overridded in GDALPamRasterBand there was no mechanism to set GPF_DIRTY in the pam layer.

Without more investigation I can't see why things regressed after 1.6.1. I suspect it was a case of other information being handled a different way so less gets written to the .aux.xml file.

I believe the fix is to override SetDescription?() in GDALPamRasterBand and to set the dirty flag there.

I'd appreciate it if you could file a ticket, and copy in the above discussion.

Change History (4)

comment:1 Changed 9 years ago by warmerdam

Component: PythonBindingsGDAL_Raster
Keywords: pam description added
Owner: changed from hobu to warmerdam

Not a bindings issue. I'll take this.

comment:2 Changed 9 years ago by warmerdam

Milestone: 1.7.31.8.0
Resolution: fixed
Status: newclosed

In trunk I have incorporated logic to capture band descriptions properly (marking pam info as dirty) and also added cloning logic for the band description. I am hesitant to move this all back into 1.7. I do not understand how it could ever have worked for geotiff without saving it to an .aux.xml file - so I can't explain why you see it working in 1.6.1.

The problem is pretty generic and would apply to essentially all pam enabled formats.

comment:3 Changed 9 years ago by warmerdam

Sorry, the above fixes are in trunk (r20810).

comment:4 Changed 9 years ago by Even Rouault

Test added in r20812

Note: See TracTickets for help on using tickets.