On 17 July 2015 at 11:58, Even Rouault wrote:
> In your above example, only the first band of var_stacked.vrt will be used. So
> basically you're computing the average of all lines of a block (possibly a
> single line depending on the dataset), and this average line will be written
> in the first
On Friday 17 July 2015 11:29:11 Mike Toews wrote:
> On 17 July 2015 at 11:13, Even Rouault wrote:
> > But when you have more than 26 input files, it is dubious that you really
> > want to individually identify them with a particular letter/name. As in
> > one of the examples, you likely just want
On 17 July 2015 at 11:13, Even Rouault wrote:
> But when you have more than 26 input files, it is dubious that you really want
> to individually identify them with a particular letter/name. As in one of the
> examples, you likely just want to apply a global operation on them, like sum,
> mean, ...
On Thursday 16 July 2015 21:03:52 Armin Schmidt wrote:
> I have a very simple point-shapefile which throws various memory
> allocation errors when I try to grid it with gdal_grid using "nearest",
> but works absolutely fine and fast when using the "invdist" algorithm. I
> never had this problem bef
On Thursday 16 July 2015 20:38:44 Jukka Rahkonen wrote:
> Hi,
>
> Have a look at this gis.stackexchange question:
> http://gis.stackexchange.com/questions/149006/does-gdal-calc-only-support-26
> -input-raster-files-at-a-time
>
> So, what users can do if they have more than 26 input files?
Hi Ju
Hi,
Have a look at this gis.stackexchange question:
http://gis.stackexchange.com/questions/149006/does-gdal-calc-only-support-26-input-raster-files-at-a-time
So, what users can do if they have more than 26 input files?
-Jukka Rahkonen-
___
gdal-dev ma
I have a very simple point-shapefile which throws various memory
allocation errors when I try to grid it with gdal_grid using "nearest",
but works absolutely fine and fast when using the "invdist" algorithm. I
never had this problem before. Does anyone have any idea what is wrong?
If it would h
Ramiro Marco Figuera jacobs-university.de> writes:
>
> Hi,
>
> I'm re-projecting (from stereographic to gnomonic) the PDS LOLA 20m/pix
> DTMS from the lunar south pole. Im using gdalwarp like this: 'gdalwarp
> -t_srs '+proj=gnom +lat_0=-90 +lat_ts=-90 +lon_0=0 +k=1 +x_0=0 +y_0=0
> +a=1737400
Hi,
I'm re-projecting (from stereographic to gnomonic) the PDS LOLA 20m/pix
DTMS from the lunar south pole. Im using gdalwarp like this: 'gdalwarp
-t_srs '+proj=gnom +lat_0=-90 +lat_ts=-90 +lon_0=0 +k=1 +x_0=0 +y_0=0
+a=1737400 +b=1737400 +units=m +no_defs' topo_stereo.tif topo_gnom.tif'
.
Hi,
Are you launching multiple at the same time or are you looping and treating one
file at a time? If so, your computer is just waiting to the last file to
finish before it starts the next. When the file are smaller, they appear to be
running at the same time but when the files get bigger, t
Hi,
I had the same problem with gdal_warp. I recompiled the code using the latest
ms visual studio community and the buffer was increased from 15 Mb to 1.5 GB.
It's was a first for me because I usually work in python. It's easy to do.
That fixed all the issue. I am told that buffer size is
gdal_rasterize is limited to use just 10MB of memory (line ~640 of
gdalrasterize.cpp).
Is there anyway to change this (without having to recompile?)
I'm noticing that changing the output data format from Byte to Int16 or even
Int32 drastically reduces performance. This must be because the strict
12 matches
Mail list logo
