NITF 2.1 TRE BLOCKA parsing bug

[bsmisenh]

When the FRLOC_LOC, LRLC_LOC, LRFC_LOC, and FRFC_LOC fields in BLOCKA are in degrees minutes seconds (DMS) format the corner coordinates output by gdalinfo is incorrect. If these fields are converted to their decimal equivalents then the output for the corner coordinates is correct for gdalinfo. GDAL should handle these fields correctly when they are in the DMS format. Attached is the BLOCKA extension details from the Compendium of Controlled Extensions (CE) for the National Imagery Transmission Format downloaded from ​http://www.gwg.nga.mil/ntb/baseline/documents.html. Due to this error if a file contains BLOCKA with these fields in DMS then the file is incorrectly handled by GDAL resulting in errors in geo placement of the imagery.

[Jukka Rahkonen]

Could you attach some small NITF sample file as well for testing?

[bsmisenh]

blocka added with with coordinates from IGEOLO with .00 added

[bsmisenh]

blocka added with with coordinates from IGEOLO with FFRFC_LOC modified from 325900.00E0850000.00 to 325900.01E0850000.00

[bsmisenh]

I attached some test files. Unfortunately I cannot attach the actual files I am having an issue with due to their contents. After further testing it seems there is some form of validation checking on the coordinates. This issue may not be a problem with the code but a problem with the values paced in BLOCKA even though they seem correct. If this is the case can you please let me know what the verification check is that is being performed, or where I would be able to find it in the code?

[Jukka Rahkonen]

NITF is totally unknown format for me. Are there any free programs which I could use as a reference for handling NITF (meta)data?

I may be wrong, but it looks that GDAL does not report the corner coordinates because with your settings the image area is not a perfect aligned rectangle but a bit distordet because you moved one corner point a bit. Gdalinfo is reporting that image is georeferenced with ground control points.

GCP[  0]: Id=UpperLeft, Info=
          (0.5,0.5) -> (85,32.9833361111111,0)
GCP[  1]: Id=UpperRight, Info=
          (1023.5,0.5) -> (85.0002777777778,32.9833333333333,0)
GCP[  2]: Id=LowerRight, Info=
          (1023.5,1023.5) -> (85.0002777777778,32.9830555555556,0)
GCP[  3]: Id=LowerLeft, Info=
          (0.5,1023.5) -> (85,32.9830555555556,0)

If you convert the issue image into issue_warped.tif with gdalwarp the corner coordinates are at least reported.

gdalwarp -of nitf -co ICORDS=G i_3001a_blocka_issue.ntf i_3001a_blocka_issue_warped.ntf

Corner Coordinates:
Upper Left  (  84.9999999,  32.9833335) ( 85d 0' 0.00"E, 32d59' 0.00"N)
Lower Left  (  84.9999999,  32.9830554) ( 85d 0' 0.00"E, 32d58'59.00"N)
Upper Right (  85.0002779,  32.9833335) ( 85d 0' 1.00"E, 32d59' 0.00"N)
Lower Right (  85.0002779,  32.9830554) ( 85d 0' 1.00"E, 32d58'59.00"N)
Center      (  85.0001389,  32.9831944) ( 85d 0' 0.50"E, 32d58'59.50"N)

[bsmisenh]

Unfortunately I do not know of a free NITF viewer for public use. At this time I do not think this is really a bug in GDAL, but an issue with the data itself. I would suggest marking this as invalid at this time. I will reopen this ticket if I am able to provide a sufficient reason why GDAL should handle this case differently. I appreciate your quick responses to this matter.