Hi Michael,
Le 25/11/2023 à 00:44, Michael Sumner via gdal-dev a écrit :
When I translate this GeoTIFF to 10% original size, it's very very
slow if OVERVIEW_LEVEL=NONE is set.
Fixed per https://github.com/OSGeo/gdal/pull/8819
Even
--
http://www.spatialys.com
My software is free, but my time
Over the network it takes 23 seconds:
time gdal_translate -oo OVERVIEW_LEVEL=NONE -outsize 219 226
/vsicurl/https://github.com/mdsumner/cog-example/raw/main/cog/sentinel-image.tif
net.tif
real 0m23.909s
user 0m4.374s
sys 0m1.021s
Saving the file locally and translating it's fractional sec
When I translate this GeoTIFF to 10% original size, it's very very slow if
OVERVIEW_LEVEL=NONE is set.
The GeoTIFF has no overviews.
export dsn="/vsicurl/
https://github.com/mdsumner/cog-example/raw/main/cog/sentinel-image.tif";
## takes *forever*
gdal_translate $dsn out.tif -outsize 219 226 -oo
Woohoo! I look forward to the cleanups that this will enable. Thank you
Even for working on this!
I am hoping that the hdf4 will get some similar improvements in 2024. I
haven't looked to see if any of the hdf4 cleanup in 2023 could allow GDAL
cleanup. My guess is that there isn't anything yet as
Le 24/11/2023 à 14:34, Sebastiaan Couwenberg via gdal-dev a écrit :
On 11/24/23 13:22, Hernán De Angelis via gdal-dev wrote:
May be this is of help: I have seen the case of the .py utilities not
been compiled and installed a couple of times when I mistakenly had
two Python versions present and
On 11/24/23 13:22, Hernán De Angelis via gdal-dev wrote:
May be this is of help: I have seen the case of the .py utilities not
been compiled and installed a couple of times when I mistakenly had two
Python versions present and acccessible.
There is an issue with setuptools silently failing wit
On 11/24/23 13:16, Even Rouault via gdal-dev wrote:
The Python utilities are no longer installed with the .py extension,
this broke their use in QGIS when we removed this in the Debian
package some time ago. Don't know if that's still the case. Either
way, this doesn't seem like an appropriate
Hi Carsten,
should be fixed per https://github.com/OSGeo/gdal/pull/8810
Even
--
http://www.spatialys.com
My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-d
May be this is of help: I have seen the case of the .py utilities not
been compiled and installed a couple of times when I mistakenly had two
Python versions present and acccessible.
/H.
Den 2023-11-24 kl. 13:16, skrev Even Rouault via gdal-dev:
Bas,
The Python utilities are no longer instal
Bas,
The Python utilities are no longer installed with the .py extension,
this broke their use in QGIS when we removed this in the Debian
package some time ago. Don't know if that's still the case. Either
way, this doesn't seem like an appropriate change for a .1 patch release.
Are you sure a
Hi,
Please find "RFC 98: Build requirements for GDAL 3.9" in
https://github.com/OSGeo/gdal/pull/8802 for review & comments
Summary:
The document updates RFC68 with the new build requirements for GDAL 3.9:
* C++ >= 17
* CMake >= 3.16
* PROJ >= 6.3.1
The minimum version for the following o
Hi,
OK, I've reverted that change. I'll guess someone will have to figure
out how to have both .py scripts and .exe/.sh launchers at the same time...
Pick up an archive among the following ones (by ascending size):
https://download.osgeo.org/gdal/3.8.1/gdal-3.8.1rc2.tar.xz
https://downloa
Hallo!
> On 23. Nov 2023, at 18:12, Javier Jimenez Shaw via gdal-dev
> wrote:
>
> My colleague (I have only Linux) will give more info.
I am that colleague.
>
> On Thu, 23 Nov 2023 at 16:25, Even Rouault wrote:
>
>>>
>>> I thought that it was enough disabling GDAL_USE_EXTERNAL_LIBS (we ar
13 matches
Mail list logo
