Ticket #1714 (closed defect: fixed)

Opened 1 year ago

Last modified 1 year ago

Problem RPF NITF File - geotransform mixed up

Reported by: warmerdam Assigned to: warmerdam
Priority: normal Milestone: 1.4.3
Component: GDAL_Raster Version: 1.4.0
Severity: normal Keywords: nitf
Cc: gaopeng

Description

File: http://download.osgeo.org/gdal/data/nitf/bugs/NITF21_CGM_ANNO_Uncompressed_unmasked.ntf

The IGEOLO information is ok, but GDAL uses the RPF geolocation information in preference and it seems to be mixed up about the proper offset to this info in the file.

The following debug messages indicate the NITF driver is doing some hackey stuff to try and correct for location table errors. Apparently it is not working well. 

 NITF: Location table offsets off by 257 bytes, adjusting accordingly.
 NITF: Got spatial info from CoverageSection

This bug is related to the fix for ticket #1313.

Change History

07/30/07 11:22:57 changed by warmerdam

The file is produced with GeoView?, and is reported as corrupt by some other NITF validation programs (Mr.BIFF and SNIPER)

I see the file which lead to the hacky code for searching for the RPFHDR in #1313 was named similar to this problem file. I imagine it was produced by the same product. I think the solution is to stop the guesswork about the RPF header info location and just ignore it if it isn't where it should be. This would make the reader much more robust in the face of these files.

07/30/07 13:23:04 changed by warmerdam

  • status changed from new to closed.
  • version changed from svn-trunk to 1.4.0.
  • resolution set to fixed.
  • milestone changed from 1.5.0 to 1.4.3.

I have changed the code to just ignore the location table in LoadLocationTable?() if the RPFHDR object isn't where it should be according to the location table. This change has been incorporated into trunk, 1.4.x and 1.4-esri branches.