Versions 1.8.0 and 1.9.0 cannot read RADARSAT CEOS sard file properly.

[ccin]

When I run the command gdalinfo on a RADARSAT CEOS sard file using versions 1.8.0 and 1.9.0, the file cannot be read properly. Gdalinfo is not able to extract any coordinate system, projection, spheriod, etc, it is not able to read and GCPs, and it describes the extent of the RADARSAT scene as a vector and not a polygon. These results are unexpected, and not useful to my organization. Gdalwarp is not able to transform and reproject the sard file.

Gdalinfo, version 1.6.0, is able to extract from the CEOS sard file a coordinate system, projection, spheriod, etc, it is able to read 15 GCPs, and it describes the extent of the RADARSAT as a polygon. Gdalwarp is able to transform and reproject the sard file.

Please see attached document for comparison.

What has changed from version 1.6.0 to 1.8.0 that no longer allows me to use GDAL to process and transform my RADARSAT CEOS data?

Thanks.

[Even Rouault]

I've reviewed quickly the changes in the driver since 1.6.0 and nothing strikes me as an obvious cause for the regression you see. Could you provide a link to a dataset to download that demonstrates the issue ?

[ccin]

Replying to rouault:

I've reviewed quickly the changes in the driver since 1.6.0 and nothing strikes me as an obvious cause for the regression you see. Could you provide a link to a dataset to download that demonstrates the issue ?

The sample radarsat link is at ​https://docs.google.com/open?id=0B9XiL0SNt7asb09XQVJ6Sy1NT2M The original ceos sard file is huge - about 25MB so I have put it in google docs as a tar.gz file.

We ran gdalinfo on the *.sard file in this folder. I have kept the tifs and jpgs in the zipped folder so that you have some visual reference file. Thank you for helping us with this issue and we are looking forward to hearing from you on how to process the files like these in latest version of gdal.

[Even Rouault]

Frank, I've identified that the following changeset http://trac.osgeo.org/gdal/changeset/22662/trunk/gdal/frmts/ceos2 (ticket #4146) makes that this dataset is now rejected by the SAR_CEOS driver (in 1.6.0 it was recognized by this driver), and is now dealt by the CEOS driver. As a consequence, there is no longer metadata exposed. Definitely not my area of expertise.

[ccin]

Hi Rouault and Frank,

will there be a patch released for this purpose? do you have any other suggestion of how we can do the processing with the later GDALs?

thank you

kumari Web Application Developer, CCIN

Replying to rouault:

Frank, I've identified that the following changeset http://trac.osgeo.org/gdal/changeset/22662/trunk/gdal/frmts/ceos2 (ticket #4146) makes that this dataset is now rejected by the SAR_CEOS driver (in 1.6.0 it was recognized by this driver), and is now dealt by the CEOS driver. As a consequence, there is no longer metadata exposed. Definitely not my area of expertise.

[warmerdam]

ccin,

I believe you could just comment out this code block in sar_ceosdataset.cpp to read your file.

            if( fileid == __CEOS_IMAGRY_OPT_FILE && iThisRecord == 2 )
            {
                CPLDebug( "SAR_CEOS", "Ignoring CEOS file with wrong second record sequence number - likely it has padded records." );
                CPLFree(record);
                CPLFree(temp_body);
                return CE_Warning;
            }
            else
            {
                CPLError( CE_Failure, CPLE_AppDefined, 
                          "Corrupt CEOS File - got record seq# %d instead of the expected %d.",
                          record->Sequence, iThisRecord );
                CPLFree(record);
                CPLFree(temp_body);
                return CE_Failure;
            }

I haven't reviewed your file closely yet, but I'm assuming it has inconsistent record ids and this is caught by our more careful consistency checking.

[Jukka Rahkonen]

The link to the sample file is dead and it is impossible to check the current situation or study it the theory of Frank about the inconsistent record ids was right.

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.