Opened 15 years ago

Closed 14 years ago

#1750 closed defect (fixed)

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

Reported by: Even Rouault Owned by: Even Rouault
Priority: normal Milestone: 1.4.3
Component: GDAL_Raster Version: 1.4.2
Severity: normal Keywords: CADRG nitf
Cc: warmerdam

Description

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.

Attachments (2)

gdal_svn_cadrg_meridian180_bug1750.patch (984 bytes ) - added by Even Rouault 15 years ago.
001zc013_meridian180.on1 (286.7 KB ) - added by Even Rouault 15 years ago.
Modified version of 001zc013.on1 whose bounding box is crossing merdian 180°

Download all attachments as: .zip

Change History (9)

by Even Rouault, 15 years ago

comment:1 by Even Rouault, 15 years ago

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.

by Even Rouault, 15 years ago

Attachment: 001zc013_meridian180.on1 added

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

comment:2 by warmerdam, 15 years ago

Keywords: nitf added
Milestone: 1.4.3

Even,

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

comment:3 by warmerdam, 15 years ago

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

comment:4 by Even Rouault, 15 years ago

Resolution: fixed
Status: newclosed

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

comment:5 by globalmapper, 14 years ago

Resolution: fixed
Status: closedreopened

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@…

comment:6 by Even Rouault, 14 years ago

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.

comment:7 by globalmapper, 14 years ago

Resolution: fixed
Status: reopenedclosed

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@…

Note: See TracTickets for help on using tickets.