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
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
