Le mercredi 24 octobre 2012 16:11:01, Carl Godkin a écrit : > 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.
Carl, No other suggestion unfortunately with the existing code. A possible workaround that could be upstreamed would be to introduce a EHDR_DATATYPE configuration option, in a similar way to AAIGRID_DATATYPE for the AAIGrid driver ( see http://gdal.org/frmt_various.html#AAIGrid ), that could be set in order to override the guess made by the EHdr driver. A more "interesting" approach would be to examine some samples of the .bil file and determine if each 4-byte tuple "looks" more like an IEEE754 Floating point value or a Int32 one. Not sure if this is doable in practice however, and as all heuristics you could always find data that would defeat it. Best regards, Even _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
