[gdal-dev] python GDAL issue

[Brad Hards]

Hi Adam,

 

https://github.com/codice/imaging-nitf/pull/196 is the work I did for my
java implementation.

 

The spec definition I came up should be directly applicable.

 

However for it to work in GDAL, we need at least:

*	Support for parsing / using the IEEE 754 encoding (which I called
type="IEEE754")
*	Support for parsing / using the 32bit integer encoding (which I
called type="UINT")
*	Support for the "&" condition operator (for bitmask tests)
*	Unit tests

 

I think I can hack my unit test code to output some test files.

 

Brad

 

 

From: Edson, Adam Robert <are131 at psu.edu> 
Sent: Wednesday, 6 November 2019 1:36 AM
To: Brad Hards <bradh at frogmouth.net>; gdal-dev at lists.osgeo.org
Cc: Bradley, Eliza S <esb165 at psu.edu>
Subject: Re: [gdal-dev] python GDAL issue

 

Brad,

 

Sorry it took so long to get back to you.

I am interested in collaborating on this with you.

Any help would be appreciated!

 

Thanks!

Adam

 

 

 

  _____  

From: Brad Hards <bradh at frogmouth.net <mailto:bradh at frogmouth.net> >
Sent: Monday, October 14, 2019 6:16 PM
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 

 

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 <mailto:are131 at psu.edu> > 
Sent: Monday, 14 October 2019 10:02 PM
To: Brad Hards <bradh at frogmouth.net <mailto:bradh at frogmouth.net> >;
gdal-dev at lists.osgeo.org <mailto: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
<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
m%2FOSGeo%2Fgdal%2Fblob%2Fmaster%2Fgdal%2Fdata%2Fnitf_spec.xml&data=02%7C01%
7Care131%40psu.edu%7C7a494cbbe65340b8c30508d750f4334f%7C7cf48d453ddb4389a9c1
c115526eb52e%7C0%7C0%7C637066882092744733&sdata=JMlKqzsaCIGCNrJR9ktNo%2BHur9
wOxUF%2FFKOgXZNzRIw%3D&reserved=0> 

 

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/20191106/8a3ff57d/attachment-0001.html>