> are you 100% positive you've tested the updated version of the pull
> request? I've just given a try to running gdallimits under Docker from a
> Ubuntu 22.04 host and it successfully takes into account the
> /sys/fs/cgroup/memory.max
> limit
>
> Even
> Le 26/01/202
nfig: Failed to automatically
> find an unused IPv4 subnet, manual configuration required"
>
> Anyway, I've attempted in https://github.com/OSGeo/gdal/pull/7124 to
> better take into account cgroup to get memory limitation. Could you give
> this a try?
>
> Even
> L
, Jan 24, 2023 at 5:50 PM Even Rouault
wrote:
> Angus,
>
> there has been a recent extra fix that landed in GDAL 3.6.2 that might
> possibly help: https://github.com/OSGeo/gdal/pull/6926
>
> Even
> Le 25/01/2023 à 01:36, Angus Dickey a écrit :
>
> Hi all,
>
> I am
Hi all,
I am running into an issue where GDAL is overestimating the amount of
physical memory it has leading to it locking up the OS by taking 100% of
the memory. Here is an example program that illustrates the issue:
#include
#include "gdal.h"
int main(void) {
printf("GDAL version is
Even,
Thanks for having a look at the data, I see what you mean about the NODATA
value in the COGs. They are *supposed* to have an internal NODATA value set
on the band, but they actually do not. I set NODATA with gdal_edit and the
resampling method no longer affects overview usage.
For us, this
Even,
Thank you for your response.
Since you can't reproduce this with your test it makes me think there is
something about the input data. I put together some sample data in a public
S3 bucket and some commands. Would you be able to try them out to see if
that reproduces the behaviour? I tried
Hi all,
I am using gdal_translate to read a VRT file made up of COGs stored in S3.
This works great when downsampling using nearest neighbour (GDAL 2.4.2):
$ time gdal_translate /vsis3/bucket/mosaic.vrt /tmp/out.tiff -projwin
-9177335.364031402 5305341.259217514 -9174889.379126277
