doh! for me - yes you have. I will double check this.
On 20 July 2016 at 14:58, Even Rouault 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 n
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 nX
I may very well be computing the file size wrong, my calculation is:
1024 + nXSize * nYSize * 2
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/IWriteBloc
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 call
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 IReadBl
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(po
I added the following to the end of the Create method in
frmts/northwood/grddataset.cpp:
vsi_l_offset nFileSize = 1024 + nXSize * nYSize * 2;
if (VSIFTruncateL(poDS->fp, nFileSize) != 0) {
CPLError(CE_Failure, CPLE_FileIO,
"Failed to allocat
Yes I am finding it can be dependent on the input dataset dimensions - Im
only reproducing with a large raster. It is perhaps a small problem anyway
since apparently MapInfo will not handle files > 2GB anyway.
I will try using VSIFTruncateL to initialize.
On 13 July 2016 at 15:21, Even Rouault wr
Le mercredi 13 juillet 2016 15:41:36, jramm a écrit :
> jramm wrote
>
> > gdalwarp -of NWT_GRD -ot Float32 -t_srs EPSG:4326 test.tif test.grd
> >
> > very quickly returns
>
> Sorry this meant to read:
>
> very quickly returns:
>
> 0ERROR 1: /home/jamesramm/test.grd, band 1: IReadBlock failed a
jramm wrote
> gdalwarp -of NWT_GRD -ot Float32 -t_srs EPSG:4326 test.tif test.grd
>
> very quickly returns
Sorry this meant to read:
very quickly returns:
0ERROR 1: /home/jamesramm/test.grd, band 1: IReadBlock failed at X offset 0,
Y offset 0
ERROR 1: GetBlockRef failed at X block offset 0, Y b
I have a strange error when reprojecting a dataset to NWT_GRD format.
e.g.
gdalwarp -of NWT_GRD -ot Float32 -t_srs EPSG:4326 test.tif test.grd
very quickly returns
Stepping through, I've traced this to a call to `GetLockedBlockRef` in
IRasterIO (rasterio.cpp) which is called when GDALWarp att
11 matches
Mail list logo
