[gdal-dev] Error in GDALWarp to NWT_GRD

[James Ramm]

doh! for me - yes you have. I will double check this.

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

> Le mercredi 20 juillet 2016 15:55:37, James Ramm a écrit :
> > I may very well be computing the file size wrong, my calculation is:
> >
> > 1024 + nXSize * nYSize * 2
>
> This might perhaps be not the issue in your case, but I warned you before
> about the potential int32 overflow. You should cast one of nXSize or
> nYSize to
> vsi_l_offset.
>
>
> >
> > 1024 is the size of the header. Data on disk is written as an unsigned
> > short hence * 2.
> >
> > I think this is correct when comparing with calculation to seek to a
> given
> > block offset in IReadBlock/IWriteBlock:
> >
> > 1024 + nRecordSize * static_cast<vsi_l_offset>(nBlockYOff),
> >
> > Where nRecordSize = nBlockXSize * 2
> >
> > VSIFTruncateL would be preferred - I will keep looking at it to find what
> > Im doing wrong.
> >
> > On 20 July 2016 at 14:35, Even Rouault <even.rouault at spatialys.com>
> wrote:
> > > Le mercredi 20 juillet 2016 15:29:37, James Ramm a écrit :
> > > > 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?
> > >
> > > If the file is corrupted/truncated, it might be appropriate to return
> an
> > > error.
> > > Or if the operating system doesn't manage to read the block (disk
> > > corruption)
> > >
> > > I still don't get why VSIFTruncateL() wouldn't do the job. Are you sure
> > > you are computing correctly the file size when extending it ?
> > >
> > > > 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.
> > >
> > > The granularity of the information is linked a disk sector (4 KB ?
> might
> > > depend on the filesystem) so it is not surprising that the first block
> > > returns
> > > DATA given there's an header.
> > >
> > > > 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-tp527613
> > >
> > > > > 6
> > > > >
> > > > > > 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
> > >
> > > --
> > > Spatialys - Geospatial professional services
> > > http://www.spatialys.com
>
> --
> 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/1cd93654/attachment-0001.html>