[gdal-dev] Error in GDALWarp to NWT_GRD

[James Ramm]

The only 'fix' I can get working is to return a zero-filled array if the
call to VSIFReadL fails in IReadBlock.

Given that ReadBlock checks whether the block index is valid, I think it is
safe to assume that if IReadBlock is called, the data is expected to be
retrievable (i.e. VSIFReadL in IReadBlock would not fail due to a user
requesting a block that is out of bounds as that raise an error much
earlier), is it acceptable to do this?

Any reason for VSIFReadL to fail for a valid block index where an error
would be preferable to a zero'd array?

I also tried to see whether VSIGetRangeStatusL could be of any help.
Interestingly, for the newly created raster (without any data added), it
returns VSI_RANGE_STATUS_DATA for the very first block and
VSI_RANGE_STATUS_HOLE
for subsequent blocks.







On 14 July 2016 at 13:26, Even Rouault <even.rouault at spatialys.com> wrote:

> Le jeudi 14 juillet 2016 13:07:42, jramm a écrit :
> > I added the following to the end of the Create method in
> > frmts/northwood/grddataset.cpp:
> >
> >
> >     vsi_l_offset nFileSize = 1024 + nXSize * nYSize * 2;
>
> --> beware of the potential int32 overflow in nXSize * nYSize
>
> >     if (VSIFTruncateL(poDS->fp, nFileSize) != 0) {
> >               CPLError(CE_Failure, CPLE_FileIO,
> >                               "Failed to allocate space for GRD file");
> >               delete poDS;
> >               return NULL;
> >     }
> >     poDS->FlushCache(); // Write the header to disk.
> >
> > Unfortunately still receiving the error. I wonder if it would be better
> if
> > I explicitly write the zeros with VSIFWriteL?
>
> No, that's what VSIFTruncateL() is supposed to do, in a smarter way
> depending
> on filesystem capabilities.
>
> >
> >
> >
> >
> > --
> > View this message in context:
> >
> http://osgeo-org.1560.x6.nabble.com/Error-in-GDALWarp-to-NWT-GRD-tp5276136
> > p5276347.html Sent from the GDAL - Dev mailing list archive at
> Nabble.com.
> > _______________________________________________
> > gdal-dev mailing list
> > gdal-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160720/d6765406/attachment-0001.html>