Re: [gdal-dev] RFC 84: Migrating build systems to CMake

Even Rouault writes: > That git tree reorganization alone should hardly impact packagers > still using autoconf, as the release tarball structure will be > unchanged. This only impacts folks building from git > > The full cmake transition will certainly require more time, but that > will probabl

Re: [gdal-dev] RFC 84: Migrating build systems to CMake

Le 15/10/2021 à 20:18, Greg Troxel a écrit : Even Rouault writes: ==> I've thus gone to "git mv gdal/* ." to remove the gdal/ subdirectory. Of course number of boring changes were needed to adapt CI scripts, Docker, mkgdaldist.sh, etc.  This will also impact downstream users building from git

Re: [gdal-dev] RFC 84: Migrating build systems to CMake

Even Rouault writes: > ==> I've thus gone to "git mv gdal/* ." to remove the gdal/ > subdirectory. Of course number of boring changes were needed to adapt > CI scripts, Docker, mkgdaldist.sh, etc.  This will also impact > downstream users building from git once that work will have landed > into

Re: [gdal-dev] RFC 84: Migrating build systems to CMake

Hi, Some news of the preliminary work on this. I've initiated https://github.com/rouault/gdal/tree/import_cmake4gdal with: - the import of the CMake configuration using the deployment script of https://github.com/miurahr/cmake4gdal . Again, this is really an amazing work from Hiroshi ! - an

Re: [gdal-dev] Writing multi-bands vs multi-datasets

Le 15/10/2021 à 15:59, Joaquim Manuel Freire Luís a écrit : Even, sorry to keep bothering you with this but found no docs on this. Well, the ultimate doc is https://github.com/OSGeo/gdal/blob/master/gdal/frmts/netcdf/netcdfdataset.cpp The CreateCopy() solution created me a file with the coo

Re: [gdal-dev] Writing multi-bands vs multi-datasets

Even, sorry to keep bothering you with this but found no docs on this. The CreateCopy() solution created me a file with the coordinates system info stored in the "transverse_mercator" attribute (why?) Metadata: Band1#grid_mapping=transverse_mercator Band1#long_name=GDAL Band Number 1 Band1

Re: [gdal-dev] Running GDAL through Python >= 3.8 on Anaconda - DLL load failed

Found this https://www.mail-archive.com/gdal-dev@lists.osgeo.org/msg35514.html So my guess is that is that the shipped OpenJPEG dll is not compatible with the gdal.dll, it misses that opj_encoder_set_extra_options() function. From: gdal-dev On Behalf Of Even Rouault Sent: Friday, October 15,

Re: [gdal-dev] Running GDAL through Python >= 3.8 on Anaconda - DLL load failed

Le 15/10/2021 à 14:05, Pedro Venâncio a écrit : Hi Even, I've been trying to tackle this issue and these are my last findings: https://github.com/conda-forge/gdal-feedstock/issues/541#issuecomment-944228747 ||

Re: [gdal-dev] Running GDAL through Python >= 3.8 on Anaconda - DLL load failed

Hi Even, I've been trying to tackle this issue and these are my last findings: https://github.com/conda-forge/gdal-feedstock/issues/541#issuecomment-944228747 Does this make sense to you? Do you remember any change between gdal 3.2.1 and 3.2.2 that can explain this behaviour? Thank you very muc