[gdal-dev] EHdr guesses wrong pixel type...

[Carl Godkin]

Hi,

I'm using GDAL 1.9.2 to read a .bil data set that has an accompanying .hdr
file which does not include PIXELTYPE.  It does have NBITS = 32.

The documentation for the EHdr format mentions

This driver does not always do well differentiating between floating point
> and integer data. The GDAL extension to the .hdr format to differentiate is
> to add a field named PIXELTYPE with values of either FLOAT, SIGNEDINT or
> UNSIGNEDINT. In combination with the NBITS field it is possible to
> described all variations of pixel types.



Unfortunately,  the .hdr file includes a negative NODATA value

NODATA         -9999


which causes the pixeltype to be guessed wrong due to this code in
ehdrdataset.cpp:

 /* -------------------------------------------------------------------- */
> /*      If we have a negative nodata value, let's assume that the       */
> /*      pixel type is signed. This is necessary for datasets from       */
> /*      http://www.worldclim.org/futdown.htm                            */
> /* -------------------------------------------------------------------- */
>     if( bNoDataSet && dfNoData < 0 && chPixelType == 'N' )
>     {
>         chPixelType = 'S';
>     }



I'm not sure where my user got this particular data set (which can make all
the difference) but it's really meant to be
pixeltype FLOAT though it's not explicit as I said.

Do you have a suggestion besides getting him to rename his .bil files to
.flt to cause the code to guess FLOAT instead?
Is there a way to supply GDAL with a hint in this case, for instance?  I
could locally modify my GDAL library of course
but if there's another way, I'd prefer it.

(It's funny: I used to have some hand-written code to read .bil datasets
and the like where my default pixel type was FLOAT. Now
the user tells me "this used to work" when in actuality I've really cleaned
up the code by starting to use GDAL instead.  That's
hard to explain to anyone but a programmer of course.)


Thanks for any suggestions!

carl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20121024/9e0385e6/attachment-0001.html>