GDALInfo improperly reports LAT / LONG coordinates

[madcatwb]

In working with some imagery (NITF), many of the coordinates were improperly reported. Calculating LAT / LONG coordinate information using GetGeoTransform?() will often return longitude outside of the normal range (0 - 180). The coordinates were reported in the 400+ range for the data I was using. By subtracting 360 from the output, I was able to obtain the proper coordinates.

[warmerdam]

madcatwb,

Can you provide the NITF file in question? Even snagging the first 50K or so of the file would be fine for my purposes if the imagery is restricted distribution.

[madcatwb]

Replying to warmerdam:

madcatwb, Can you provide the NITF file in question? Even snagging the first 50K or so of the file would be fine for my purposes if the imagery is restricted distribution.

Ok, while I cannot provide the imagery, I noticed that this was not a problem exclusive to GdalInfo?. I tried opening the file in OpenEv?, and it was very long and skinny, stretched to an extreme.

The one thing that really stands out is that the numbers provided when I call "GetGeoTransform?" are not the same as those reported by other programs that are displaying the imagery properly. Most of the numbers are exactly the same, but the "x pixel size" is way off. I suspect this is the root of the problem. Here is the data that I can provide for you. I think if you do some math on it, you can see that the numbers cannot possibly come out correctly.

Reported by GDal:

Width: 27072 Height: 125696

T[0]: XXX.01826807676174 T[1]: 0.013297672249307117 T[2]: -0.0000081756544722450775 T[3]: XX.80083620864653 T[4]: -0.0000000044198699674601639 T[5]: -0.0000057462064776166364

Reported By vras:

Width: 27072 Height: 125696

T[0]: XXX.01826807676174 T[1]: -0.000000200083727344615 T[2]: -0.0000081756544722450775 T[3]: XX.80083620864653 T[4]: -0.0000000044198699674601639 T[5]: -0.0000057462064776166364

Here are the calculations based on those numbers. I tried to calculate the LR coordinates based on the origin and the matrices. (I hope they are right...done with notepad, copy + paste, and calc.exe) Either way, you can clearly see that the numbers produced with the values reported by Gdal are obviously not in an acceptible range. I am not sure why the x scale reported would be different between the programs, but it seems that is the cause of the issue.

Gdal:

-0.00541666666667341728 + -1.02764706454331726144 = -1.03306373120999067872 // xOffset from origin

-0.0001196547197590815571008 + -0.7222751694105007289344 = -0.7223948241302598104915008 // yOffset from origin

vras:

359.994583133242271424 + -1.02764706454331726144 = -358.96693606869895416256 // xOffset from origin

-0.0001196547197590815571008 + -0.7222751694105007289344 = -0.7223948241302598104915008 // yOffset from origin

[madcatwb]

Correction:

vras:

-0.00541666666667341728 + -1.02764706454331726144 = -1.03306373120999067872 // xOffset from origin

-0.0001196547197590815571008 + -0.7222751694105007289344 = -0.7223948241302598104915008 // yOffset from origin

Gdal:

359.994583133242271424 + -1.02764706454331726144 = -358.96693606869895416256 // xOffset from origin

-0.0001196547197590815571008 + -0.7222751694105007289344 = -0.7223948241302598104915008 // yOffset from origin

[warmerdam]

OK, the geotransform[1] value does seem to be out of whack.

There are several mechanism by which GDAL can get a geotransform, one of which is by reading PRJPSB/MAPLOB TREs. Do you happen to know if this might apply for this file? Without knowing which mechanism is coming into play, and without the file it is pretty hard for me to look into this problem.

Hmm, digging in the code, it seems improbable that this could be from MAPLOB, since that lacks this degree of precision for pixel size.

Perhaps you have an RPF CoverageSectionSubheader? that might be the source?

In the code I see:

    /* 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->dfURX += 360;
        psImage->dfLRX += 360;
    }

I wonder if this could be coming into play.

Well, as you can see I'm thrashing around here blindly with no real way to narrow things down. Unless you are in a position to debug the code yourself, or somehow provide me with data demonstrating this problem (privately under non-disclosure would be fine) I don't think I'm going to be able to progress on this issue.

[madcatwb]

I'll dig some more and see if there is any additional info that i can provide.

[warmerdam]

Closing pending information sufficient to reproduce.

Feel free to reopen if you can help us reproduce the problem.

[madcatwb]

Replying to warmerdam:

Closing pending information sufficient to reproduce.

I think I found the problem. Today I was looking through the code in ntifimage.c, and I settles on the piece of code you mentioned previously

    /* 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->dfURX += 360;
        psImage->dfLRX += 360;
    }

It seems this is adding 360 any time the left sides are greater than the right. The imagery I am experiencing this problem with are all basically inverted (south up). Because of this, they would satisfy that criteria, and the coordinates would be changed. I verified that it is only the LRX and URX that are showing this behavior. Might I suggest adding a test for negative values in here as well (or instead)?

[warmerdam]

Even,

Any thoughts on this?

[madcatwb]

Replying to warmerdam:

One other thing to mention. I am not sure if I am being short sighted (my view is narrow on this particular piece of code) but it seems that this code is attempting to fix an issue if you are crossing the prime meridian. It should be noted that this only seems to account for a situation where two corners cross. I am sure it is not all that rare to see a single corner cross, with the other three remaining on the same side. I am not sure if this has any bearing on what is being addressed, but I thought I'd point it out. This issue is not really realated to this particular bug, but was more of an observation between myself and a coworker.

[rouault]

I narrowed the test to just catch the case where :

• the image is north-up
• the left longitudes are > 170°
• the right longitudes are < -170°

Fix commited in trunk in r14256, in branches/1.5 in r14257 and in branches/1.4 in r14258

[madcatwb]

Fantastic.