Some CADRG crossing 180 have wrong extent.

[gaopeng]

Some CADRG crossing 180 have wrong extent. Here are the good and bad extents for attached image:

GDAL:         174.375, 41.538, 517.5, 51.923
It should be: 174.375, 41.538, 191.25, 51.923

[Even Rouault]

Frank,

I also got into this issue some time ago with other similar CADRG products. I had done a broader fix in the past, but I had to make more narrow due to #2135. The proposed patch basically comes back to my original fix, but restrict it only to CADRG products. So hopefully it shouldn't cause regressions in other NITF profiles that can have non north-up images, and not to CADRG products themselves as, to the best of my knowledge, they have not fancy orientations.

[warmerdam]

With 1.6-esri, 1.7 and trunk I was seeing this for the geotransform:

Origin = (174.375000000000000,51.923076923076927)
Pixel Size = (-0.223388671875000,-0.006760817307692)
Corner Coordinates:
Upper Left  ( 174.3750000,  51.9230769) (174d22'30.00"E, 51d55'23.08"N)
Lower Left  ( 174.3750000,  41.5384615) (174d22'30.00"E, 41d32'18.46"N)
Upper Right (-168.7500000,  51.9230769) (168d45'0.00"W, 51d55'23.08"N)
Lower Right (-168.7500000,  41.5384615) (168d45'0.00"W, 41d32'18.46"N)

Which does not give the right side bound of 517.5 reported above. I'm not sure how you got that. But this is also wrong, with a negative x pixel size due to the dateline confusion. Even's patch seems to do the reasonable thing and I have applied it in trunk (r18740), 1.7 (r18741) and 1.6-esri (r18742).

The trunk change also includes an autotest with this file.

Gao, could you confirm that this commit fixes things for you, and close the ticket?

[gaopeng]

Yes. It fixed my problems.