[gdal-dev] Reading ArcInfo binary grids with the R rgdalpackage fails with "GDAL Error 3: Attempt to read past EOF in..../arc.dir"

[Even Rouault]

Le Wednesday 22 July 2009 18:09:28 Gregory, Matthew, vous avez écrit :
> Hi Jason,
>
> Jason Roberts wrote:
> > Markus - thanks for the links to those tickets. Those tickets
> > seem to imply this is a minor annoyance. Unfortunately, for
> > me, it means I can't read the grids at all from R. Perhaps if
> > I was using the C interface there would be a workaround (just
> > ignore the error?) but this is not possible using the R
> > interface, as far as I can tell. For example, the rgdal
> > GDAL.open API fails with the same message.
>
> I was one of the people that wrote up a ticket on this.  Ironically, it
> looks like it was a bug fix that Even implemented (rev. 16460) that
> allowed the INFO directory to be read correctly (so that the VAT is
> read), which exposed the source of these errors.

Yeah, exactly... 

>
> > Is the right solution to get the rgdal developers to code a
> > workaround to ignore the error somehow? Or is it to determine
> > the underlying problem in GDAL? Or perhaps ESRI is generating
> > grids that violate the AIG format specification?
>
> I hadn't worked with this outside of the C interface, but I'm noticing
>
> now that the same problems crop up in the Python bindings:
>   >>> from osgeo import gdal
>   >>> ds = gdal.Open("D:/matt/vat_test/grid1")
>
>   ERROR 3: Attempt to read past EOF in
> D:/matt/vat_test/grid1/../info/../grid1/vat
>   .adf.
>
>   >>> type(ds)
>
>   <type 'NoneType'>
>
> So it seems like either all bindings need to silently ignore this error
> or have it fixed in the GDAL source.  I'll admit that my understanding
> of what really needs to happen is often shaky ...

I've pushed in trunk (r17430) and branches/1.6 (r17431) a workaround to enable 
users to open those datasets that trigger the error with binding languages. 
As Open() in swig/include/gdal.i checks that there is no failure returned by 
CPLGetLastErrorType() even if the dataset is not NULL, the workaround is just 
to reset the error state before returning the dataset.

For people affected by the issue, not being able to build GDAL from source and 
not interested in the raster attribute table, they can just rename the 'info' 
directory, so it won't be read at all and won't trigger the error.

See http://trac.osgeo.org/gdal/ticket/3031

>
> matt
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev