SRP shall support Main Raster Image (MRI) that contain multiple zone images (IMG)

[gewang]

The current SRP can only load SRP images named ZZZZZZDD.IMG, where DD == 01. For cases where DD is more than 01, it would fail. The reason is that the current implementation assumes that the corresponding GEN files would have the same basename as the IMG file.

According to the ASRP Edition 1.2 specification, General Information File - Dataset Description Record - DRF Field - NOZ Subfield contains a integer value in the range 01 to 99. To cope with cases where DD > 01, the following patch shows my intention but is quite clumsy. Experts' help is needed to make a real fix.

*** old	Mon Oct 19 08:59:49 2009
--- new	Mon Oct 19 09:41:15 2009
***************
*** 30,35 ****
--- 30,36 ----
  
  #include "gdal_pam.h"
  #include "ogr_spatialref.h"
+ #include "cpl_multiproc.h"
  #include "cpl_string.h"
  #include "iso8211.h"
  
***************
*** 39,44 ****
--- 40,47 ----
  {
      friend class SRPRasterBand;
  
+     static const char *ResetTo01( const char* str );
+ 
      FILE*        fdIMG;
      int*         TILEINDEX;
      int          offsetInIMG;
***************
*** 344,349 ****
--- 347,368 ----
  }
  
  /************************************************************************/
+ /*                          ResetTo01()                                 */
+ /* Replace the DD in ZZZZZZDD.XXX with 01.                              */
+ /************************************************************************/
+ 
+ const char *SRPDataset::ResetTo01( const char* str )
+ {
+     char *pszStaticResult = (char *) CPLGetTLS( CTLS_PATHBUF );
+     int size = strlen( str );
+     CPLStrlcpy( pszStaticResult, str, size + 1);
+ 
+     pszStaticResult[6] = '0';
+     pszStaticResult[7] = '1';
+     return pszStaticResult;
+ }
+ 
+ /************************************************************************/
  /*                            GetMetadata()                             */
  /************************************************************************/
  
***************
*** 808,813 ****
--- 827,839 ----
  /* -------------------------------------------------------------------- */
      VSIStatBufL sStatBuf;
  
+     CPLString basename = CPLGetBasename( osFileName );
+     int zoneNumber = CPLScanLong( basename + 6, 2 );
+ 
+     CPLString path = CPLGetDirname( osFileName );
+     CPLString basename01 = ResetTo01( basename );
+     osFileName = CPLFormFilename( path, basename01, ".IMG" );
+ 
      osFileName = CPLResetExtension( osFileName, "GEN" );
      if( VSIStatL( osFileName, &sStatBuf ) != 0 )
      {
***************
*** 831,836 ****
--- 857,863 ----
  /*      Loop processing records - we are basically looking for the      */
  /*      GIN record which is normally first in the .GEN file.            */
  /* -------------------------------------------------------------------- */
+     int recordIndex = 0;
      while (TRUE)
      {
          CPLPushErrorHandler( CPLQuietErrorHandler );
***************
*** 839,844 ****
--- 866,873 ----
          CPLErrorReset();
          if (record == NULL)
            break;
+         if ( ++recordIndex < zoneNumber )
+           continue;
  
          const char* RTY = record->GetStringSubfield( "001", 0, "RTY", 0 );
          if( RTY == NULL || !EQUAL(RTY,"GIN") )

[warmerdam]

Alan Stratford reports the patch works ok for him. I have no appropriate datasets to test the issue.

I have slightly modified the patch to avoid the TLS stuff, and applied it in trunk (r18433).

[warmerdam]

PS. Thank Ge for the patch!

[Even Rouault]

The patch could lead to out-of-buffer read & writes in the case the basename length was shorter than 8 characters. I've fixed that in r18436