Il 24/10/2016 12:58, Paolo Cavallini ha scritto:
> Il 24/10/2016 12:51, Even Rouault ha scritto:
>
>> Possibly. I've just fixed the issue per
>> https://trac.osgeo.org/gdal/ticket/6694
>> and will issue a GDAL 2.1.2 RC4 with that extra fix.
For the record, ticket open on Processing:
https://hub
Il 24/10/2016 12:51, Even Rouault ha scritto:
> Possibly. I've just fixed the issue per
> https://trac.osgeo.org/gdal/ticket/6694
> and will issue a GDAL 2.1.2 RC4 with that extra fix.
thanks for that.
> Hum, I'm not sure to understand. I don't see any difference when running
> gdalwarp with
> Rather tricky. The same analysis seems to run fine, however, on the same
> data with different software.
On individual polygons yes. But if you just aggregate all the polygons as a
multipolygon (what gdalwarp does), it becomes invalid.
> What would be your advice for gdalwarp usage in QGIS>Pro
Hi Even,
Il 22/10/2016 21:54, Even Rouault ha scritto:
> Since GDAL 2.1, validation of the cutline geometry once reprojected into
> source coordinates is done, and defaults into an error if the validation
> fails.
>
> Here the issue is linked to the fact that when the cutline datasource is mad
On Saturday 22 October 2016 18:30:27 Paolo Cavallini wrote:
> Hi all,
> I'm running gdalwarp on data from
>
> https://github.com/qgis/QGIS-Training-Data/tree/master/training_manual_data/
> processing/iterative
>
> as
>
> gdalwarp -ot Float32 -q -of GTiff -cutline watersheds.shp -co
> COMPRESS=DE
Am 22.10.2016 um 18:30 schrieb Paolo Cavallini:
gdalwarp -ot Float32 -q -of GTiff -cutline watersheds.shp -co
COMPRESS=DEFLATE -co PREDICTOR=1 -co ZLEVEL=6 -wo OPTIMIZE_SIZE=TRUE
dem25.tif OUTPUT.tif
Works for me with GDAL 1.11.3 and 2.0-dev, but fails on GDAL 2.1.0 and
2.1.2. All Gisintenal b
Hi all,
I'm running gdalwarp on data from
https://github.com/qgis/QGIS-Training-Data/tree/master/training_manual_data/processing/iterative
as
gdalwarp -ot Float32 -q -of GTiff -cutline watersheds.shp -co
COMPRESS=DEFLATE -co PREDICTOR=1 -co ZLEVEL=6 -wo OPTIMIZE_SIZE=TRUE
dem25.tif OUTPUT.tif
a
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
18 matches
Mail list logo
