Opened 12 years ago

Closed 12 years ago

#3088 closed enhancement (fixed)

do not remove leading spaces after TRE=xxxx= metadata when writing them

Reported by: cqueen Owned by: warmerdam
Priority: normal Milestone: 1.6.3
Component: GDAL_Raster Version: unspecified
Severity: major Keywords: NITF
Cc:

Description

The Nitf driver currently only has support for the BLOCKA TRE. All other TRE's (ie. SENSRA, AIMIDB, ACFTB) are filed under XDID. They should be placed under the UDID field. The implementation should not be too complicated. Just having a list of registered TRE's somewhere in the code notifying the placement to up date the UDUDL field instead of IXSHDL and that should correct the issue. I may be wrong. But overall there should be support for these registered TRE's. Otherwise it defeats the purpose of registering them.

Attachments (1)

NITF_Driver_Test.cpp (2.1 KB) - added by cqueen 12 years ago.

Download all attachments as: .zip

Change History (7)

comment:1 Changed 12 years ago by warmerdam

Keywords: NITF added
Priority: highnormal
Status: newassigned

It looks to me as if all the TREs are put into IXSHD which is apparently for registered TREs. Are you suggesting that some of the above are not registered TREs, and belong in the UDID area? Can you provide a list of registered TREs? How do we handle the situation where new TREs are registered? Perhaps the metadata needs to differentiate registered from unregistered TREs?

If I were to do some work in this area (not my favorite code!) would you be willing to do some testing and validation?

comment:2 Changed 12 years ago by cqueen

Further research of the NITF format reveals the TRE's can be placed in either field, registered or not. However, there is still an issue with the GDAL parser when placing the TRE's into the file. Certain TRE's allow for some fields within them to be blank spaces. But GDAL removes white-spaces from the beginning of the value for any key-value pair passed in during creations. This causes an illegally formatted TRE to be placed into the NITF file because the length of the TRE must be a certain length and data within it must be in the correct location within the string.

comment:3 Changed 12 years ago by warmerdam

Could you provide a demonstration of this? There should be some means by which the data can be escaped or quoted to work around this.

Changed 12 years ago by cqueen

Attachment: NITF_Driver_Test.cpp added

comment:4 Changed 12 years ago by cqueen

If you look at the attached file (NITF_Driver_Test.cpp) you'll see the output is the following:

Driver NITF supports Create() method. Driver NITF supports CreateCopy?() method. Finished Writing Test.ntf. # of GDAL MetaData? Items for Domain TRE: 1 Field Name: ACFTB = 0000000000 VFFR 20000002009080700000000001015000000.0000N0000000.0000E000.00000000m 0000000u0000000u999.99 0000000

The last line is shows that GDAL is extracting the 20 white spaces from the beginning of the ACFTB field.

comment:5 Changed 12 years ago by Even Rouault

I've commmited a fix in trunk in r17521 that avoids the removal of the leading spaces.

comment:6 Changed 12 years ago by Even Rouault

Milestone: 1.6.3
Resolution: fixed
Status: assignedclosed
Summary: Registered TRE Support for NITF Driverdo not remove leading spaces after TRE=xxxx= metadata when writing them

Backported in branches/1.6 in r17559 and test added in r17558

Note: See TracTickets for help on using tickets.