Re: [gdal-dev] libgeotiff 1.7.4rc1 available for testing
On 18/02/2025 15:58, Even Rouault via gdal-dev wrote: Hi, Main reason: doesn't build with GCC 15 Download links: - https://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.7.4rc1.tar.gz built on cygwin with both cmake and autoconf using gcc (GCC) 15.0.0 20250105 I noticed few discrepancies cmake - there is no enabled test ? - /usr/bin/makegeo.exe is built but there is no manual - /usr/share/doc/GeoTIFF/* docs are installed autoconf - "make check" passes - /usr/bin/makegeo.exe is not present - /usr/share/doc/GeoTIFF/* docs are NOT installed Regards Marco ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] unsetting configs vs empty values
Hi, To me, that's a bit unexpected and possibly a bug, but not a problem I've ever run into in practice. You're probably aware of this already, but instead of: > export AWS_S3_ENDPOINT=... > gdalmdiminfo ... > unset AWS_S3_ENDPOINT > gdalmdiminfo ... you can do: > AWS_S3_ENDPOINT=... gdalmdiminfo ... > gdalmdiminfo ... Laurentiu On Wed, Feb 19, 2025, at 02:50, Michael Sumner via gdal-dev wrote: > This may well just be a hapless user-question, can we set configs to empty > and expect that to mean "unset"? > > In a fresh session all is well (standard public bucket): > > gdalmdiminfo /vsis3/mur-sst/zarr > > Our non-standard public bucket can't be found of course, so set the endpoint: > > export AWS_S3_ENDPOINT=projects.pawsey.org.au > gdalmdiminfo > /vsis3/idea-10.7289-v5sq8xb5/www.ncei.noaa.gov/data/sea-surface-temperature-optimum-interpolation/v2.1/access/avhrr/198109/oisst-avhrr-v02r01.19810901.nc > > but now > > gdalmdiminfo /vsis3/mur-sst/zarr > ERROR 4: `/vsis3/mur-sst/zarr' not recognized as being in a supported file > format. > > this fails, but I expected it to work: > > export AWS_S3_ENDPOINT= > gdalmdiminfo /vsis3/mur-sst/zarr > > this succeeds: > > unset AWS_S3_ENDPOINT > gdalmdiminfo /vsis3/mur-sst/zarr > > My question is what is the right way to revert the non-standard endpoint? > We have to unset the option? Or, is an empty value a desirable way to mean > "default"? > > Thanks for your help. > > Cheers, Mike > > > > -- > Michael Sumner > Research Software Engineer > Australian Antarctic Division > Hobart, Australia > e-mail: mdsum...@gmail.com > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] unsetting configs vs empty values
This may well just be a hapless user-question, can we set configs to empty and expect that to mean "unset"? In a fresh session all is well (standard public bucket): gdalmdiminfo /vsis3/mur-sst/zarr Our non-standard public bucket can't be found of course, so set the endpoint: export AWS_S3_ENDPOINT=projects.pawsey.org.au gdalmdiminfo /vsis3/idea-10.7289-v5sq8xb5/ www.ncei.noaa.gov/data/sea-surface-temperature-optimum-interpolation/v2.1/access/avhrr/198109/oisst-avhrr-v02r01.19810901.nc but now gdalmdiminfo /vsis3/mur-sst/zarr ERROR 4: `/vsis3/mur-sst/zarr' not recognized as being in a supported file format. this fails, but I expected it to work: export AWS_S3_ENDPOINT= gdalmdiminfo /vsis3/mur-sst/zarr this succeeds: unset AWS_S3_ENDPOINT gdalmdiminfo /vsis3/mur-sst/zarr My question is what is the right way to revert the non-standard endpoint? We have to unset the option? Or, is an empty value a desirable way to mean "default"? Thanks for your help. Cheers, Mike -- Michael Sumner Research Software Engineer Australian Antarctic Division Hobart, Australia e-mail: mdsum...@gmail.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] RFC 108 text: driver removals for GDAL 3.11
"Formalizing" recent discussions: https://github.com/OSGeo/gdal/pull/11862 -- 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-dev
[gdal-dev] libgeotiff 1.7.4rc1 available for testing
Hi, Main reason: doesn't build with GCC 15 Download links: - https://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.7.4rc1.tar.gz - https://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.7.4rc1.zip Changelog: * CMake modernization, automate release generation from tags and refactor CI (#115) - CMake: Bumps the minimum CMake version to 3.13 - CMake: Add BUILD_SHARED_LIBS matrix for ON and OFF using similar config for macos-latest, windows-latest, and ubuntu-latest - CMake: Modernize CMake configuration to prevent flag/feature leaking - CMake: Adds CPack configuration so `package_source` target is available for dist generation - CMake: Updates FindPROJ.cmake with GDAL's recent version - CMake: add BUILD_MAN and BUILD_DOC options - CMake: Windows PDB install with BUILD_SHARED_LIBS - CMake: Remove FindGeoTIFF.cmake - Removes 16 year old dead `makefile.mpw` - Removes 6 year old dead `makefile.vc` - CI: Generates release artifacts and attaches them to every build - CI: Creates a release and attaches release artifacts for every tag of the OSGeo/libgeotiff repository - CI: [Attests](https://github.com/actions/attest-build-provenance) the release artifacts if the `github.repository_owner == OSGeo` - CI: Remove Appveyor config * GTIFGetDefn(): add missing normalization of angular units to degree Contrary to what the documentation of GTIFDefn::ProjParm[] mentionned, we failed to normalize angular measures to degrees when reading them from projection parameters (ProjXGeoKey's) when ProjCoordTransGeoKey was present (but we did normalize them when reading them from the PROJ database when there were was only a EPSG PCS code) Relates to https://github.com/OSGeo/gdal/issues/10154 and https://github.com/OSGeo/gdal/pull/10158 * Fix build with GCC 15 (#131) 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-dev
