Den tirs. 5. dec. 2023 kl. 02.15 skrev Greg Troxel via gdal-dev <
gdal-dev@lists.osgeo.org>:
> Building the
> rust compiler requires the *immediately preceding* compiler, which seems
> unprecented, and I don't understand how people can think that's ok
I don't think this is true - it's merely the
Even Rouault via gdal-dev writes:
> The current situation where numpy is an optional dependency of the
> GDAL Python bindings is quite cumbersome to deal with our setup.py's
> setuptools . All details (a bit tricky) in
> https://github.com/OSGeo/gdal/issues/8069 . It seems it would be
> simpler i
For what it's worth, Rasterio has required Numpy for a few versions, and
there's never been a single complaint about it. The footprint and extra
complexity of numpy is just a drop in the bucket.
I suppose that someone using only the OGR parts of the Python bindings
might be inconvenienced, but not
Agree with Kurt - it's always struck me as a little surprising that it was
optional. There's also not very much of a Python stack you can build that
involves GDAL but doesn't pull in Numpy through another dependency, as Even
said.
I would've thought that in any constrained environment where GDAL i
I lean towards just requiring numpy. It's super common and once a system
brings in gdal python, it can't be a super constrained env where keeping
things really small is critical. Just requiring numpy simplifies a number
of aspects.
I think the setup.py topic as a whole is somewhat separate.l. So
Hi,
The current situation where numpy is an optional dependency of the GDAL
Python bindings is quite cumbersome to deal with our setup.py's
setuptools . All details (a bit tricky) in
https://github.com/OSGeo/gdal/issues/8069 . It seems it would be simpler
if the bindings just required numpy,
Thanks!
On Mon, 4 Dec 2023 at 16:46, Even Rouault
wrote:
> Javier,
>
> TIFFTAG_DATETIME or AREA_OR_POINT are copied by the COG/GTiff drivers from
> the source dataset metadata.
>
> So using gdal_translate / GDALTranslate(), you may set them with the "-mo
> KEY=VALUE" option.
>
> If using an inte
Even,
Thanks for the quick reply. If the getpid() has actually been measured to be an
overhead, then it’s even better that this will now be resolved so that the
faster code can be re-enabled for the Macs.
Since you have already created a PR I will answer there.
Best
Carsten
> On 4. Dec 2023,
Javier,
TIFFTAG_DATETIME or AREA_OR_POINT are copied by the COG/GTiff drivers
from the source dataset metadata.
So using gdal_translate / GDALTranslate(), you may set them with the
"-mo KEY=VALUE" option.
If using an intermediate VRT as the source for GDALCreateCopy(), then
you may call Se
Hi
I am trying to convert a "normal" tiff file into a COG. For that I am using
an intermediate vrt file to add the geolocation parameters, and finally
copy the vrt into a COG.
I am doing it in C++, but it should be similar doing it on the command line
I hope. (In some cases I am using also other p
Carsten,
thanks for the detailed analysis.
There is definitely a cost to getpid() in some circumstances. The worst
case I can imagine is on code like the one below that looks over
OGRCoordinateTransformation::Transform() many times. For each call to
that function, there's a OSRGetProjTLSConte
Hello everyone!
Please let me know if you would have preferred to discuss this on Github.
I have run into a problem with the use of pthread_atfork() in ogr_proj_p.cpp. I
have since seen that the code has been disabled for macOS in 3.8 in response to
https://github.com/OSGeo/gdal/issues/8497, an
12 matches
Mail list logo
