[gdal-dev] python GDAL issue

[Brad Hards]

I think the problem is that there isn't any real way to handle the IEEE-754
(or raw int/uint bitmask) in GDAL at the moment. 

 

Working through the part you've posted:

S is the unit quantity

 

The part that looks like:

B\\0\\0\\0

is therefore the SCALE FACTOR, which is really IEEE 754-2008 binary encoded,
and the existing TRE XML definition and parsing code doesn't handle that
case AFAICT.

 

This part is the ROW_GSD and COL_GSD + units:

0030.00

M

0030.00

M

 

In that case, I think there is a missing value in the TRE (because there has
to be four bytes, and there are only three shown in your sample, which I
assume is the test data that NGA derived from LANDSAT 8).

 

I've also been looking at handling "weird" TREs better (on and off for a
while). I have a Java implementation that shares the XML definition, and the
plan is to add two new types to the field definition:

        <xs:attribute name="type" use="optional">

            <xs:simpleType>

                <xs:restriction base="xs:string">

                    <xs:enumeration value="string"/>

                    <xs:enumeration value="integer"/>

                    <xs:enumeration value="real"/>

                    <xs:enumeration value="UINT"/>

                    <xs:enumeration value="IEEE754"/>

                </xs:restriction>

            </xs:simpleType>

        </xs:attribute>

 

(where UINT and IEEE754 values are new, and are binary encoded instead of
string encoded).

 

Happy to collaborate on this if you're interested.

 

Brad

 

 

From: Edson, Adam Robert <are131 at psu.edu> 
Sent: Monday, 14 October 2019 10:02 PM
To: Brad Hards <bradh at frogmouth.net>; gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] python GDAL issue

 

I am working on adding BANDSB and the other TREs listed in the SNIP
document.

 

I am not sure what you are asking for.

However, here is the output from gdal.getMetadata('TRE') for the relevant
portion of the BANDSB TRE

SPECTRAL RADIANCE       SB\\0\\0\\0\\0\\0\\00030.00M0030.00M-------M-------M

                                               \\0\\0DETECTOR
<file://0//0DETECTOR>                 \x7fU

This is the section from the radiometric_quantity field to wave_length_unit
field.

 

Thanks!

Adam

 

  _____  

From: Brad Hards <bradh at frogmouth.net <mailto:bradh at frogmouth.net> >
Sent: Saturday, October 12, 2019 1:51 AM
To: Edson, Adam Robert <are131 at psu.edu <mailto:are131 at psu.edu> >;
gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
<gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org> >
Subject: RE: [gdal-dev] python GDAL issue 

 

GDAL's NITF encoding doesn't appear to have BANDSB yet:
https://github.com/OSGeo/gdal/blob/master/gdal/data/nitf_spec.xml

 

It would definitely help to see how that file encodes it. Can you open the
NITF file, find the part that starts with BANDSB0nnnn (where 0nnnn is some
length value), and copy out the following 0nnnn characters?

 

Brad

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20191015/2a7c3930/attachment-0001.html>