Opened 10 years ago

Closed 10 years ago

#3029 closed defect (fixed)

NITF PRJPSB TRE handling wrong for Transverse Mercator

Reported by: warmerdam Owned by: warmerdam
Priority: normal Milestone: 1.6.2
Component: GDAL_Raster Version: 1.5.3
Severity: normal Keywords: NITF PRJPSB MAPLOB
Cc:

Description

gdalinfo on a Worldview NITF product is producing a coordinate system report like the following due to improper handling of the PRJPSB TRE TM parameters:

PROJCS["unnamed",
    GEOGCS["WGS 84",
        DATUM["WGS_1984",
            SPHEROID["WGS 84",6378137,298.257223563,
                AUTHORITY["EPSG","7030"]],
            TOWGS84[0,0,0,0,0,0,0],
            AUTHORITY["EPSG","6326"]],
        PRIMEM["Greenwich",0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.0174532925199433,
            AUTHORITY["EPSG","9108"]],
        AUTHORITY["EPSG","4326"]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0.9996],
    PARAMETER["central_meridian",-75],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",500000],
    PARAMETER["false_northing",0]]

Change History (8)

comment:1 Changed 10 years ago by warmerdam

Keywords: PRJPSB added
Milestone: 1.6.2
Resolution: fixed
Status: newclosed
Version: unspecified1.5.3

Corrected in trunk (r17239), 1.6 branch (r17240), 1.5 branch (r17241) and 1.6-esri branch (r17242).

Confirmed against the specification.

comment:2 Changed 10 years ago by ysiddiqui

Resolution: fixed
Status: closedreopened

Projection parameters are fine now. However, resolution is still being read wrong (50 meters instead of 0.5 meter). The size of the file comes across as approx. 20x20 degrees, which is totally incorrect.

comment:3 Changed 10 years ago by warmerdam

Keywords: MAPLOB added

I have confirmed the problem. The units of measure field in the MAPLOB TRE were being ignored but should affect how the pixel size is interpreted (cm in this case). Fixed in trunk (r17256), 1.6 branch (r17257), 1.5 branch (r17258) and 1.6-esri (r17259).

comment:4 Changed 10 years ago by warmerdam

Resolution: fixed
Status: reopenedclosed

I have uploaded gdal16-1.6.1-3 and gdal-dev-1.7pre-7 package for OSGeo4W with this fix.

comment:5 Changed 10 years ago by ysiddiqui

Resolution: fixed
Status: closedreopened

I don't mean to be nitpicky, but I noticed that there is no "UNIT" information at the end of the Coordinate System section. Is this because units are not defined for this projection (although it is clearly a standard UTM projection)? Or should it be added?

comment:6 Changed 10 years ago by ysiddiqui

Another question I have here, just to make sure I beat this to death :-) :

I noticed that the georeferencing looks correct as far as starting with the upper left corner as origin and using the resolution times columns/rows to get the lower right corner. However, it does not match the lower right corner listed in the IMD file. Do we know for sure that the lower right corner reported by gdalinfo is correct, i.e. gleaned from inside the NITF file itself? Or is it just calculated?

comment:7 Changed 10 years ago by warmerdam

Yusuf,

The units are optional, and if not specified are assumed to be meters which is what applies for this data.

The MAPLOB TRE contains the origin and pixel size. The bottom right corner is essentially computed from those and the size of the image in pixels and lines.

I see what you mean about the computed lat/long extents not matching well with the MIN/MAX LAT/LON values from the RPC metadata (which is presumably also in the .IMD). It is not immediately obvious to me if this means there is an error or if the lat/long extent values are just approximate. I was not able to download the whole image - I just grabbed the header - so I'm not able to do any ground truthing. Do you believe there is an error in the georeferencing still?

comment:8 Changed 10 years ago by ysiddiqui

Resolution: fixed
Status: reopenedclosed

Frank,

Thanks for clarifying these two issues. I think we will assume that what you have is correct, but will try to check in with DigitalGlobe to make sure.

Note: See TracTickets for help on using tickets.