On vendredi 13 mars 2020 16:23:27 CET Jon Morris wrote:
> Thanks for the quick fix, Even! Glad it wasn't just something I'd missed.
>
> I'm not entirely clear on the uses for gdal_array. Are there cases where it
> is better than using a MEM raster?
I don't think so. It uses the MEM driver underne
Thanks for the quick fix, Even! Glad it wasn't just something I'd missed.
I'm not entirely clear on the uses for gdal_array. Are there cases where it is
better than using a MEM raster? Is there any more detailed documentation?
Thanks,
Jon
-Original Message-
From: Even Rouault
Sent: 13
Jon,
> I'm trying to upgrade from GDAL 2.2.0 to 3.0.4 and some of our tests are
> failing. We're using gdal_array.OpenArray() to create temporary datasets
> and all the tests where we call band.WriteArray() are failing with the
> error "CPLError: Write operation not permitted on dataset opened in
Hello all,
I'm trying to upgrade from GDAL 2.2.0 to 3.0.4 and some of our tests are
failing. We're using gdal_array.OpenArray() to create temporary datasets and
all the tests where we call band.WriteArray() are failing with the error
"CPLError: Write operation not permitted on dataset opened in
Hi,
You asked help for understanding, so
Check the size of the original image:
309153 x 277451
Check how many bands:
1
Check how many bits per pixel for each band:
32 bits (makes 4 bytes)
Multiply:
309153 x 277451 x 4 = number of bytes as uncompressed = 3.43099E+11 = 343 GB
Compare with the 120
Given the filesize of the original raster, I suspect it’s mostly empty, and so
I’d suggest also specifying:
-co “SPARSE_OK=TRUE”
That instructs GDAL to avoid writing any data at all where the entirety of a
tile is nodata, rather than writing a (compressed) block of nodata values.
However, the
if you run without the switch it will create the result without
compression, so you will be back to a 400Gb file. Instead run everything in
one single command.
With compression it is likely to take some extra time, as some calculation
has to be done to achieve that.
If you want speed, tile the rast
Here is the gdalinfo output I am just re-projecting to 4326
Driver: VRT/Virtual Raster
Files: Depth (Max).vrt
Depth (Max).Terrainredacted.tif
Depth (Max). redacted .tif
Size is 309153, 277451
Coordinate System is:
PROJCS["USA_Contiguous_Albers_Equal_Area_Conic_USGS_version",
GEOG
What is the source (and target) projection and extent? Some projections
have expansive limits, but you can specify the target extent with -te
HTH
On Fri., 13 Mar. 2020, 23:43 Brian, wrote:
> Is it faster to do a gdal_warp with compression then without? Is it safe
> to assume the drive write spe
Is it faster to do a gdal_warp with compression then without? Is it safe
to assume the drive write speed would be the limiting factor for speed in
this case?
On Fri, Mar 13, 2020 at 8:33 AM Cainã K. Campos
wrote:
> Hello Brian,
>
> Try to add the switch -co "COMPRESS=LZW" to the command line t
Hello Brian,
Try to add the switch -co "COMPRESS=LZW" to the command line to generate
a compressed result with lossless compression.
On Fri, Mar 13, 2020 at 9:07 AM Brian wrote:
> So compressed this raster is fairly small about 120mb but running
> gdal_warp produces a raster that is about 416
So compressed this raster is fairly small about 120mb but running gdal_warp
produces a raster that is about 416 gb, is this something this list can
help with? If so I can upload the file somewhere and let you guys/gals take
a look at it.
___
gdal-dev mail
Hi Even, Jeff
I checked both the 3.0.x and 2.4.4 release from http://www.gisinternals.com/
They both report :
GDAL_HAS_HDF4=YES
GDAL_HAS_HDF5=YES
NETCDF_CONVENTIONS=CF-1.5
NETCDF_HAS_NC2=YES
NETCDF_VERSION=4.3.2 of Sep 3 2017 18:13:37
Are the gdal nuget package based on the
13 matches
Mail list logo
