[PATCH] Fixes bouding box for CADRG files crossing meridian 180°

[Even Rouault]

The attached patch fixes handling of some CADRG products whose bounding box crosses meridian 180°. This is the case for cjnc/cjncz01/000k1023.jn1 (and similar) from NIMA 'GNCJNCN' CDROM (unfortunately, I can't attach it as its distribution is restricted)

Currently, gdalinfo reports :

Corner Coordinates:
Upper Left  ( 179.2515593,  33.2307692) (179d15'5.61"E, 33d13'50.77"N)
Lower Left  ( 179.2515593,  29.0769231) (179d15'5.61"E, 29d 4'36.92"N)
Upper Right (-176.2577963,  33.2307692) (176d15'28.07"W, 33d13'50.77"N)
Lower Right (-176.2577963,  29.0769231) (176d15'28.07"W, 29d 4'36.92"N)
Center      (   1.4968815,  31.1538462) (  1d29'48.77"E, 31d 9'13.85"N)

With this BB, the display in OpenEV is incorrect.

The patch just adds +360 to the right longitude when it detects that right longitude < left longitude. This leads to longitude > 180°, but apparently it's ok for OpenEV or gdalwarp (I've warped it successfully to UTM zone 60. EPSG:32660).

After applying the patch, gdalinfo reports :

Upper Left  ( 179.2515593,  33.2307692) (179d15'5.61"E, 33d13'50.77"N)
Lower Left  ( 179.2515593,  29.0769231) (179d15'5.61"E, 29d 4'36.92"N)
Upper Right (     183.742,      33.231) (183d44'31.93"E, 33d13'50.77"N)
Lower Right (     183.742,      29.077) (183d44'31.93"E, 29d 4'36.92"N)
Center      (     181.497,      31.154) (181d29'48.77"E, 31d 9'13.85"N)

Another solution that has come into my mind would be to truncate the right longitude to E180. (as there are no data, just blank, in these products at the right of E180). But we should modify the resolution of the image that is reported. Seemed a bit too complex.

[Even Rouault]

In order people being able to check the problem, I've forged a fake CADRG file, from 001zc013.on1, by just changing the left and right longitude of the LID_CoverageSectionSubheader section (no change made in the section with ASCII coordinates as their values are overriden by those of the LID_CoverageSectionSubheader section). The left and right longitude in this file are respectively 178.875E and 178.875W. Thus, you can observe the same behaviour as described above.

[Even Rouault]

Modified version of 001zc013.on1 whose bounding box is crossing merdian 180°

[warmerdam]

Even,

This change looks good. Please go ahead and apply in trunk, and branches/1.4.

[warmerdam]

PS. please include the bug ticket # in the comments about the issue.

[Even Rouault]

Commited in trunk in r11904 and in branches/1.4 in r11905

[globalmapper]

I have found an instance where this fix causes problems, namely where the NITF data is rotated so that the right side is west of the left side of the image. To fix this, I propose only applying the change above if the difference between the left and right X values is greater than 180.0 degrees, which pretty much assures an actual ATM cross. Here is the updated snippet of code with the change:

/* Bug #1750 */ /* Fix for cjnc/cjncz01/000k1023.jn1 (and similar) from NIMA GNCJNCN CDROM: */ /* this product is crossing meridian 180deg and the upper and lower right longitudes are negative */ /* which causes problems in OpenEV, etc... So we are adjusting their value by setting them above +180 */

if( (psImage->chICORDS == 'G'

psImage->chICORDS == 'D') &&

(psImage->dfURX < psImage->dfULX && psImage->dfLRX < psImage->dfLLX) && ((psImage->dfULX - psImage->dfURX) > 180.0) )

{

psImage->dfURX += 360; psImage->dfLRX += 360;

}

Thanks,

Mike Global Mapper Support support@…

[Even Rouault]

Mike,

I'm not sure which version of GDAL you are using. Because another ticket about that issue, #2135, was opened and fixed a few months ago and a more restrictive test was added, not exactly the one you suggest, but something that I hope will also solve your issue. That fix is included in GDAL 1.5.3 or 1.6.0beta for example.

[globalmapper]

Ah, sorry about that, I was on 1.5.0 and just assumed any follow-up fix would be tacked on to this bug. I'll close this back up.

Thanks,

Mike Global Mapper Support support@…