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

[cqueen]

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.

[warmerdam]

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?

[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.

[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.

[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.

[Even Rouault]

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

[Even Rouault]

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