#3985 closed defect (fixed)
Statistics are not persisted for NITF format datasets
Reported by: | ajain | Owned by: | warmerdam |
---|---|---|---|
Priority: | high | Milestone: | 1.9.0 |
Component: | GDAL_Raster | Version: | 1.8.0 |
Severity: | normal | Keywords: | NITF statistics |
Cc: | rprinceley |
Description
After computing statistics on the attached nitf data, the stats are not persisted with the dataset. This can be seen when GetStatistics is called on the re-opened dataset instance from the sample test script used to reproduce the problem.
I also noticed that the destructor of NITFWrapperRasterBand is not called when the dataset is closed (my breakpoint is not hit while debugging) - indicating that there is a leak in the nitf driver.
Attachments (1)
Change History (7)
by , 13 years ago
Attachment: | NITFStats.rar added |
---|
comment:1 by , 13 years ago
comment:2 by , 13 years ago
The change seems to fix the problem partially. If stats are computed for the test data using ComputeStatistics and GetStatistics is called within the same running instance, valid stats are returned. But if I run the program again, but this time only call GetStatistics (by commenting out the code that calls ComputeStatistics), stats are not returned. I would have expected that the ComputeStatistics during the first run would have persisted the stats.
Also, I am debugging using 1.8 version of GDAL sources - which is where I noticed that the destructor of NITFWrapperRasterBand is not called (using my test program).
comment:4 by , 13 years ago
Amit, I have tested Even's changes in trunk and they seem to persist the statistics properly, including after a close and reload. I also tested that patch against GDAL 1.8 branch and it worked properly. Did you port his patch back into 1.8 for your testing?
I tried it with the 1.8-esri branch but merging was challenging due to divergence in the NITF driver.
comment:5 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Frank, thanks for testing this out...I had the code ported back properly, but I think there must have a build problem when I tested this locally earlier. I rebuilt GDAL 1.8 again, and I can see the stats persisted.
Thanks once again for looking into this, and I apologize for my mistake.
comment:6 by , 13 years ago
Milestone: | → 1.9.0 |
---|
I have backported the NITFProxyPamRasterBand implementation to 1.8-esri (r21956). I have confirmed that PAM statistics storage now seems to work properly with the test program.
Sample data and test program