[gdal-dev] NITF TRE parsing - possible extensions for MIE4NITF

[Brad Hards]

I'm working on implementing Motion Imagery Extensions for NITF (MIE4NITF,
NGA.STND.0044 version 1.1) which adds quite a few TREs.

Some of it is fairly standard, and should merge into GDAL OK.

However there are two issues that are going to require changes:
1. Some of the fields (e.g. MTIMSA) are big endian integer (i.e. binary as
opposed to BCS-N characters), of between 1 and 8 (potentially up to 16, but
not used) bytes. So instead of "15" as two characters (0x31, 0x35), you get
one byte of 0x0F. My proposed change to the schema looks like:
@@ -130,6 +130,7 @@
                     <xs:enumeration value="string"/>
                     <xs:enumeration value="integer"/>
                     <xs:enumeration value="real"/>
+                    <xs:enumeration value="UINT"/>
                 </xs:restriction>
             </xs:simpleType>
         </xs:attribute>

That binary integer format also gets used for near-future CS***B format TREs
(and DES).
There is a similar case in BANDSB, which embeds IEEE-754 format floating
point numbers. I'm not interested in that case yet, but a similar extension
seems likely.

2. There are TREs which have defined length, but the body is just one field
that is "all of it". So length is signalled by CEL. The simplest of these is
FREESA, which basically just padding of 0xFF characters. There are two TREs
(FSYNWA and FASYWA, for TRE format metadata that applies for a single frame
or at a given time) where we need to recurse into them to parse out the
embedded TREs.  Extending the XSD to handle those cases seems too
complicated, so I'm planning to open code the FSYNWA / FASYWA cases, and
ignore FREESA which never has interesting content anyway.

Anyone have strong feeling about this, or suggestions that can make things
easier?

Brad