MISSING_CONSTANT in PDS format.

[warmerdam]

From Trent Hare:

Using 1.8.0 stable (Jan 26, 2011)

1.) Allow for NoData to be assigned from label if available. Currently I mapped the ISIS2/3 NoData static defaults. This keyword appeared in a recent lunar multi-spectral release, called Diviner. in pdsdataset.cpp lines 885-887 - change to:

        if( bNoDataSet )
            poBand->SetNoDataValue(
               CPLAtofM(GetKeyword("IMAGE.MISSING_CONSTANT",dfNoData)));

[warmerdam]

In looking to setup a test case for this I discovered that the fl73n003_truncated.img file already has a MISSING keyword which was apparently a nodata value. I also don't think the suggested change sounds quite right. I have make a patch that defaults to a nodata value based on the pixel type (as it was previously) but will override this with either the IMAGE.MISSING or IMAGE.MISSING_CONSTANT keyword. The change is only in trunk (r21615) currently.

[michaelaye]

I have a PDS file that has a MISSING_CONSTANT value of:

MISSING_CONSTANT = 16#FF7FFFFB#

which is being interpreted as 16.0: In [4]: band.GetNoDataValue() Out[4]: 16.0

while it should be this value:

In [7]: data[0] Out[7]: array([ -3.40282266e+38, -3.40282266e+38, -3.40282266e+38,

-3.40282266e+38, -3.40282266e+38, -3.40282266e+38, -3.40282266e+38, -3.40282266e+38, -3.40282266e+38, -3.40282266e+38], dtype=float32)

Is the label wrong? Or the interpretation of the label string?

[michaelaye]

I am using: In [8]: gdal.version Out[8]: '1.9.2' on a Mac using KyngChaos GDALs.

[Even Rouault]

trunk (r25983), branches/1.10 (r25984): "PDS: parse correctly MISSING_CONSTANT = "16#FF7FFFFB#" as a IEEE754 single precision float expressed in hexadecimal; add support for ENCODING_TYPE = ZIP (data file compressed in a ZIP); recognize IMAGE_MAP_PROJECTION as an object included in UNCOMPRESSED_FILE object (#3939)"