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

Even Rouault even.rouault at spatialys.com
Sun Aug 28 03:40:19 PDT 2016


Brad,
> 
> 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>
> 

Is the UINT naming somewhat standardized ? Otherwise perhaps uint_be to reflect 
that it is binary encoded with big endianness (contrary to integer)

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

Not sure to have understood the structure of those TREs and couldn't find any 
public resource describing them.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com


More information about the gdal-dev mailing list