doh! for me - yes you have. I will double check this. On 20 July 2016 at 14:58, Even Rouault <even.roua...@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.roua...@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.roua...@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@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 >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev