Changes between Initial Version and Version 3 of Ticket #3930

Timestamp:

Feb 1, 2011, 6:24:54 AM (13 years ago)

Author:

morabit

Comment:

Replying to rouault:

I knew it remembered me of something. Indeed, you reported identical problems in #3848 and indeed gdalinfo --debug on reports this :

NITF: Adjusting RPFIMG TRE size from 1400 to 1350, which is the remaining size
NITF: The CoverageSectionSubheader content isn't consistant
Warning 1: Ignoring NITF RPF Location table since it seems to be corrupt.
NITF: Adjusting RPFIMG TRE size from 1400 to 1350, which is the remaining size
NITF: Adjusting RPFIMG TRE size from 1400 to 1350, which is the remaining size
GDAL: NITFDataset::Open() wasn't able to derive a first order
geotransform.  It will be returned as GCPs.
NITF: Adjusting RPFIMG TRE size from 1400 to 1350, which is the remaining size
NITF: Adjusting RPFIMG TRE size from 1400 to 1350, which is the remaining size
NITF: Adjusting RPFIMG TRE size from 1400 to 1350, which is the remaining size
NITF: Adjusting RPFIMG TRE size from 1400 to 1350, which is the remaining size

Now the new crap is in the IGEOLO record.

GCP[  0]: Id=UpperLeft, Info=
          (0.5,0.5) -> (12.2436111111111,41.9847222222222,0)
GCP[  1]: Id=UpperRight, Info=
          (1535.5,0.5) -> (12.4263888888889,42.1227777777778,0)
GCP[  2]: Id=LowerRight, Info=
          (1535.5,1535.5) -> (12.4263888888889,41.9847222222222,0)
GCP[  3]: Id=LowerLeft, Info=
          (0.5,1535.5) -> (12.2436111111111,41.9847222222222,0)

It is pretty obvious that the GCP 0 is wrong : the latitude should likely be 42.1227777778. The test added in r21181 tried to check that the CoverageSectionSubheader is consistant with the IGEOLO to decide whether to use the RPF location table at all. As it isn't, we reject the location of VQ tables as well.

The assertion "(entry->vertInterval - (-geoTransf[GEOTRSFRM_NS_RES])) / entry->horizInterval < 0.01" is a direct consequence of that when opening the RPF A.TOC file that refers to that file because there's no valid georeferencing.

So obviously this is still an invalid NITF file from the same data producer. Did you have any news from him ?

No, unfortunely it's extremely complicated for our developement team to trace back the process of data production performed by our actual client.

As I begin to be fed up with dealing with that rubbish, in a hope to "solve" definitely the issue with those datasets, I've added in trunk in r21591 a NITF_DISABLE_RPF_LOCATION_TABLE_SANITY_TESTS configuration option that you can set to TRUE to blindly trust the RPF location table even if it doesn't look sane. With the attached sample, it seems to do the job...

Thank you for your help, perhaps this is the best approach to handle this kind of data, I begin to fed up too with this weird datasets.

Best regards Bruno M.