[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