[gdal-dev] Impossible to open an ASRP dataset in java when gdalinfo/translate commands works

[Even Rouault]

On mercredi 23 août 2017 03:32:41 CEST Assemat Pierre-Jean wrote:
> Dear all,
> 
> I work with GDAL 2.2.1 on Windows 7.
> 
> When I try to open an ASRP dataset in java with the following code :
>     Dataset resu = org.gdal.gdal.gdal.Open(filenameOrURL,
> .gdal.gdalconst.gdalconst.GA_ReadOnly) ;
> 
>    I have the following message :
>       ERROR 1: ISO8211 record leader appears to be corrupt.
> 
>     and a null dataset is returned.
> 
> When I try to read this dataset in C++ whith gdalinfo or gdal_translate I do
> have the same message but both commands ignore it and display full info or
> perform translation...
> 
> Question :
> What parameter/function should I call to have the same behavior in java ???

Pierre-Jean,

You can't without modifying the code. For historical reasons, the Java & Python bindings are 
stricter than the C++ API, and will reject a non null dataset if an error has been emitted and 
not cleared by the driver before it returns its dataset object.

A workaround is to add a CPLErrorReset() call before the "return poDS;" calls (there are 
several ones) of SRPDataset::Open() in frmts/adrg/srpdataset.cpp

Another one is to alter in swig/include/gdal.i

#ifdef SWIGJAVA
%newobject Open;
%inline %{
static
GDALDatasetShadow* Open( char const* utf8_path, GDALAccess eAccess) {
  CPLErrorReset();
  GDALDatasetShadow *ds = GDALOpen( utf8_path, eAccess );
  if( ds != NULL && CPLGetLastErrorType() == CE_Failure )
  {
      if ( GDALDereferenceDataset( ds ) <= 0 )
          GDALClose(ds);
      ds = NULL;
  }
  return (GDALDatasetShadow*) ds;
}
%}

to

#ifdef SWIGJAVA
%newobject Open;
%inline %{
static
GDALDatasetShadow* Open( char const* utf8_path, GDALAccess eAccess) {
  CPLErrorReset();
  GDALDatasetShadow *ds = GDALOpen( utf8_path, eAccess );
  return (GDALDatasetShadow*) ds;
}
%}

and regenerate the Java bindings.

A better solution would be to examine if the error is indeed legitimate, and possibly be more 
tolerant to just issue a warning instead of an error.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170823/63ae75be/attachment.html>