[Gdal-dev] Problems translating BSB files

[Eric Dönges]

Am 19.01.2006 um 01:03 schrieb Ed McNierney:

> Frank -
>
> Thanks; I'll try to spend some time debugging, but I don't know  
> much about
> the format.  This seems to be a problem with any RNCs downloaded  
> from NOAA's
> site, so it's possible someone else with more expertise will bump  
> into it.
>
> I'll let you know if I come across any useful info, and I'll get  
> the bug
> written up.
>
>      - Ed


Ed, I think the problem is the following code in bsb_read.c (please  
note that this is
from a fairly old version of GDAL, since I have extensively rewritten  
BSB support -
unfortunately, I cannot share this code with the world at large  
because the necessary
information to do the rewrite was obtained under NDA from MapTech -  
so this might not be
exactly like this in recent GDAL code):

     {
         int    nSkipped = 0;

         while( nSkipped < 100
               && (BSBGetc( fp, bNO1 ) != 0x1A || BSBGetc( fp,  
bNO1 ) != 0x00) )
             nSkipped++;

         if( nSkipped == 100 )
         {
             BSBClose( psInfo );
             CPLError( CE_Failure, CPLE_AppDefined,
                       "Failed to find compressed data segment of BSB  
file." );
             return NULL;
         }
     }


The file in question (83116_1.KAP) look like this in the hexdump:

00000f50  32 34 33 31 0d 0a 1a 1a  00 33 01 a0 9e 04 00 02  | 
2431.....3......|

Note the two 0x1a directly following each other. So what happens is  
that in the while
loop above, a BSBGetc is executed, which fetches 0x1a, which means  
the second BSBGetc
in the || clause is executed, which also fetches a 0x1a. Since this  
is not a zero,
the test is true and nSkipped is incremented. In the next run through  
the loop,
BSBGetc gets a zero, and then we never find the 0x1a 0x00 sequence.

With kind regards,
Eric