[gdal-dev] python GDAL issue

[Edson, Adam Robert]

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>
Sent: Monday, October 14, 2019 6:16 PM
To: Edson, Adam Robert <are131 at psu.edu>; gdal-dev at lists.osgeo.org <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>
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<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOSGeo%2Fgdal%2Fblob%2Fmaster%2Fgdal%2Fdata%2Fnitf_spec.xml&data=02%7C01%7Care131%40psu.edu%7C7a494cbbe65340b8c30508d750f4334f%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637066882092744733&sdata=JMlKqzsaCIGCNrJR9ktNo%2BHur9wOxUF%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/20191105/48f82283/attachment-0001.html>