[gdal-dev] Reading ERS format with "HeaderOffset" field

[Frank Horowitz]

Hi all,

We've been trying to read some ERS ("foo.ers") files in ERMapper raw  
raster format. While many of them work perfectly (thanks for the great  
software, BTW!) we're finding a bug in reading some of those files  
which incorporate the "HeaderOffset" field.

The obvious thing is happening when reading a file with such a header:  
the values are shifted right "HeaderOffset" pixels, and the header is  
being read as data in the image.

Looking through the code, I had a go a hacking (emphasis on hacking) a  
simple patch:

--- /home/bonzo3/frank/src/gdal/gdal_vanilla/gdal-1.5.1/frmts/ers/ 
ersdataset.cpp	2007-09-04 12:20:57.000000000 +0800
+++ ersdataset.cpp	2008-07-03 16:01:24.000000000 +0800
@@ -674,6 +674,16 @@
     poDS->nRasterYSize = atoi(poHeader- 
 >Find( "RasterInfo.NrOfLines" ));

/*  
-------------------------------------------------------------------- */
+/*     Get the HeaderOffset if it exists in the  
header                  */
+/*  
-------------------------------------------------------------------- */
+    int headerOffset;
+    headerOffset = 0;
+    if( poHeader->FindNode( "HeaderOffset" ) != NULL )
+    {
+       headerOffset = atoi(poHeader->Find( "HeaderOffset" ));
+    }
+
+/*  
-------------------------------------------------------------------- */
/*      Establish the data  
type.                                        */
/*  
-------------------------------------------------------------------- */
     GDALDataType eType;
@@ -776,9 +786,9 @@
                 poDS->SetBand(
                     iBand+1,
                     new RawRasterBand( poDS, iBand+1, poDS->fpImage,
-                                       iWordSize * iBand * poDS- 
 >nRasterXSize,
+                                       headerOffset + iWordSize *  
iBand * poDS->nRasterXSize,
                                        iWordSize,
-                                       iWordSize * nBands * poDS- 
 >nRasterXSize,
+                                       headerOffset + iWordSize *  
nBands * poDS->nRasterXSize,
                                        eType, bNative, TRUE ));
             }
         }

The trouble is, I'm shooting blind, without understanding details of  
GDAL's data model, API, codebase, etc. etc. etc. This patch does not  
appear to work, with results ranging from simple failure to account  
for the header when actually reading such a file to segfaults.

At this point, I'm going to ask for advice from the experts on this  
list. What else need to be done to actually do the job?

Thanks in advance for any help you might be able to provide!
	Cheers,
		Frank Horowitz
		CSIRO
		Perth, Australia