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

[Even Rouault]

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