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 _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
