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.
