Re: [gdal-dev] GDAL 3.9.0beta1 available for testing
No adverse impacts of GDAL 3.9.0 beta1 on reverse dependency checks of 935 R packages depending on R packages sf and/or terra, both linking to GDAL. I had to wait a bit to transition to Fedora 40, gcc 14.0.1, and R 4.4.0 released yesterday, but all good as far as I can tell. Roger -- Roger Bivand Emeritus Professor Norwegian School of Economics Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway roger.biv...@nhh.no ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 3.9.0beta1 available for testing
Even, Thanks for the quick fix, I can confirm that it works. Holger Am 22.04.24 um 23:52 schrieb Even Rouault: Holger, thanks for the report. This should be fixed per https://github.com/OSGeo/gdal/commit/fba559b5bd8d33aac215681df4f6a613517a6c43 which I've backported to the release/3.9 branch A workaround is to explicitly run "cmake --target generate_gdal_version_h" before building all other targets Even Le 22/04/2024 à 23:28, Holger Jaekel via gdal-dev a écrit : Hi Even, Am 22.04.24 um 14:12 schrieb Even Rouault via gdal-dev: I've prepared a beta1 of GDAL 3.9.0 to get feedback from early testers. I tried to build on Alpine Linux Edge and got the following error: /builds/hjaekel/aports/community/gdal/src/gdal-3.9.0beta1/ogr/ogr_core.h:38:10: fatal error: gdal_version.h: No such file or directory 38 | #include "gdal_version.h" | ^~~~ compilation terminated. gdal_version.h seems not to be generated to build/gcore. You can find the full build logs here: https://gitlab.alpinelinux.org/hjaekel/aports/-/pipelines/228841 Holger ___ 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
Re: [gdal-dev] GDAL 3.9.0beta1 available for testing
All OK with https://github.com/airbusgeo/godal 's test suite, with changes that did have to be made to account for the default gtiff mask band handling (I believe this change should have been kept back until 4.0. I am not asking for it to be reverted) regards, TB On Mon, Apr 22, 2024 at 2:12 PM Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hi, > > I've prepared a beta1 of GDAL 3.9.0 to get feedback from early testers. > > The NEWS file is here: > >https://github.com/OSGeo/gdal/blob/v3.9.0beta1/NEWS.md > > For packagers, > https://gdal.org/development/rfc/rfc96_deferred_plugin_loading.html may > make it more attractive to build some drivers that typically have heavy > dependencies as plugins, installable in separate packages, due to the > load time penalty having being improved. It is let to the appreciation > of packagers to decide which drivers are worth building as plugins > installable in a separate package. > You may also pass CMake options > ([GDAL/OGR]_DRIVER__PLUGIN_INSTALLATION_MESSAGE=xxx) so > user get a hint of which package they need to install when GDAL detects > that a file may be opened by a plugin which is not available on the file > system but known to have been built as a plugin. Cf > > https://gdal.org/development/building_from_source.html#deferred-loaded-plugins > for more details. > > For end-users, the following utilities have been updated to use a new > argument parsing framework: gdaladdo, gdalinfo, gdal_translate, > gdalwarp, gdal_grid, gdal_viewshed, gdalbuildvrt, nearblack, ogrinfo, > ogr2ogr, sozip. > This helps detecting errors such as specifying twice an argument that > should be specified once (where generally the last instance was the one > used). While we have tried to retain backwards compatibility for nominal > use cases, obviously if you have scripts that accidentally specify an > argument several times whereas it should be specified at most once, they > will have to be corrected. > > Docker images with 3.9.0beta1 are currently cooking. > > master is now marked as 3.10.0dev, and the release/3.9 branch has been > created. All bugfixes for 3.9 should be backported into it. > > Source snapshots at: > > - https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.gz > - https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.xz > - https://download.osgeo.org/gdal/3.9.0/gdal380beta1.zip > > Autotest snapshots: > > - https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.tar.gz > - https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.zip > > 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 > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 3.9.0beta1 available for testing
Am 22.04.24 um 14:12 schrieb Even Rouault via gdal-dev:
Hi,
I've prepared a beta1 of GDAL 3.9.0 to get feedback from early testers.
I did a test build in vcpkg, and I see downstream problems with static
linkage. It now raises:
CMake Error at /mnt/vss/_work/1/s/scripts/buildsystems/vcpkg.cmake:859
(_find_package):
_find_package given CONFIGS option followed by invalid file name "3.8".
The names given must be file names without a path and with a ".cmake"
extension.
Call Stack (most recent call first):
/mnt/vcpkg-ci/downloads/tools/cmake-3.29.2-linux/cmake-3.29.2-linux-x86_64/share/cmake-3.29/Modules/CMakeFindDependencyMacro.cmake:76
(find_package)
/mnt/vcpkg-ci/installed/x64-linux/share/gdal/GDALConfig.cmake:37
(find_dependency)
/mnt/vcpkg-ci/installed/x64-linux/share/gdal/vcpkg-cmake-wrapper.cmake:13
(_find_package)
/mnt/vss/_work/1/s/scripts/buildsystems/vcpkg.cmake:813 (include)
CMakeLists.txt:36 (find_package)
(Don't get distracted by vcpkg: _find_package is CMake's regular
find_package.)
IIUC the generated CMake config is wrong when dependency versions are
used together with config names, as in:
find_dependency(GEOS NAMES GEOS CONFIGS geos-config.cmake 3.8)
find_dependency(NetCDF NAMES netCDF CONFIGS netCDFConfig.cmake 4.7)
AFAICT the version number must be the 2nd argument. Maybe VERSION wasn't
used often enough before, or/and it is a new CMake feature.
A tentative patch is attached, end-to-end tests pending.
Kai
diff --git a/cmake/helpers/CheckDependentLibraries.cmake b/cmake/helpers/CheckDependentLibraries.cmake
index 6eeb5d8..5d19b47 100644
--- a/cmake/helpers/CheckDependentLibraries.cmake
+++ b/cmake/helpers/CheckDependentLibraries.cmake
@@ -142,7 +142,7 @@ macro (gdal_check_package name purpose)
gdal_check_package_target(${name} ${GDAL_CHECK_PACKAGE_${name}_TARGETS} REQUIRED)
if (${name}_FOUND)
get_filename_component(_find_dependency_args "${${name}_CONFIG}" NAME)
-string(REPLACE ";" " " _find_dependency_args "${name} NAMES ${GDAL_CHECK_PACKAGE_${name}_NAMES} CONFIGS ${_find_dependency_args} ${_find_package_args}")
+string(REPLACE ";" " " _find_dependency_args "${name} ${_find_package_args} NAMES ${GDAL_CHECK_PACKAGE_${name}_NAMES} CONFIGS ${_find_dependency_args}")
endif ()
endif ()
if (NOT ${name}_FOUND)
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 3.9.0beta1 available for testing
The Docker images are now available: ghcr.io/osgeo/gdal:alpine-small-3.9.0beta1 ghcr.io/osgeo/gdal:ubuntu-small-3.9.0beta1 ghcr.io/osgeo/gdal:alpine-normal-3.9.0beta1 ghcr.io/osgeo/gdal:ubuntu-full-3.9.0beta1 Le 22/04/2024 à 14:12, Even Rouault via gdal-dev a écrit : Hi, I've prepared a beta1 of GDAL 3.9.0 to get feedback from early testers. The NEWS file is here: https://github.com/OSGeo/gdal/blob/v3.9.0beta1/NEWS.md For packagers, https://gdal.org/development/rfc/rfc96_deferred_plugin_loading.html may make it more attractive to build some drivers that typically have heavy dependencies as plugins, installable in separate packages, due to the load time penalty having being improved. It is let to the appreciation of packagers to decide which drivers are worth building as plugins installable in a separate package. You may also pass CMake options ([GDAL/OGR]_DRIVER__PLUGIN_INSTALLATION_MESSAGE=xxx) so user get a hint of which package they need to install when GDAL detects that a file may be opened by a plugin which is not available on the file system but known to have been built as a plugin. Cf https://gdal.org/development/building_from_source.html#deferred-loaded-plugins for more details. For end-users, the following utilities have been updated to use a new argument parsing framework: gdaladdo, gdalinfo, gdal_translate, gdalwarp, gdal_grid, gdal_viewshed, gdalbuildvrt, nearblack, ogrinfo, ogr2ogr, sozip. This helps detecting errors such as specifying twice an argument that should be specified once (where generally the last instance was the one used). While we have tried to retain backwards compatibility for nominal use cases, obviously if you have scripts that accidentally specify an argument several times whereas it should be specified at most once, they will have to be corrected. Docker images with 3.9.0beta1 are currently cooking. master is now marked as 3.10.0dev, and the release/3.9 branch has been created. All bugfixes for 3.9 should be backported into it. Source snapshots at: - https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.gz - https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.xz - https://download.osgeo.org/gdal/3.9.0/gdal380beta1.zip Autotest snapshots: - https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.tar.gz - https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.zip 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
Re: [gdal-dev] GDAL 3.9.0beta1 available for testing
Thanks for the fix and suggestions! I'm looking forward to 3.9.0. On Mon, Apr 22, 2024 at 11:27 AM Even Rouault wrote: > Sean, > > Rasterio's test suite has 4 errors with GDAL 3.9.0beta1. > > Metadata output of gdalinfo has changed. > > ok, I've run locally rasterio tests and I see gdalinfo now outputs: > Metadata: > a=1 > b=2 > AREA_OR_POINT=Area > > whereas the test expects > > Metadata: > a=1 > AREA_OR_POINT=Area > b=2 > > Order of metadata items shouldn't be relied upon. I believe we have > changed something internally (likely changing from char** to CPLStringList > that does sorting) that might indeed have affected it. You could also > potentially use "gdalinfo -json" output to get something easier to parse. > But don't you have a rasterio API to get GDAL metadata that would avoid > using gdalinfo at all? > > As soon as there are docker images I'll look more closely at this. > > ghcr.io/osgeo/gdal:ubuntu-full-3.9.0beta1 is already available > > > Writing a mask to a Rasterio RGB.byte.tif dataset no longer creates a > RGB.byte.tif.msk > file: > https://github.com/rasterio/rasterio/actions/runs/8786444142/job/24109342188#step:8:2231 > . > > Yes, this is intended. Due to this change: > GTiff driver: > * change default value of GDAL_TIFF_INTERNAL_MASK config option to YES > > You might run the test under GDAL_TIFF_INTERNAL_MASK=NO if you want to > test external mask. > > > The text of an error message which was "tests/data/corrupt.tif, band 1: > IReadBlock failed at X offset 1, Y offset 1: TIFFReadEncodedTile() failed." > in 3.8 has changed to "corrupt.tif, band 1: IReadBlock failed at X offset > 1, Y offset 1: TIFFReadEncodedTile() failed." This is not a big deal, we > can adjust Rasterio's test. > > Yes, related to > https://github.com/OSGeo/gdal/commit/cb5161d907e8b4fa5cb68aaf891c1a258d6475b0 > > > Behavior of SRC_METHOD/DST_METHOD=NO_GEOTRANSFORM for warp options seems > to have changed: > https://github.com/rasterio/rasterio/actions/runs/8786444142/job/24109342188#step:8:2287. > I'm not entirely sure what the intent is in Rasterio's test, will dig into > that. I just wanted to say that I see a change in GDAL. > > ok, this is related to https://github.com/OSGeo/gdal/pull/9336 , which > indeed wasn't honoring the SRC_METHOD=NO_GEOTRANSFORM and was using > directly the geotransform from the source dataset. > > Fix queued in https://github.com/OSGeo/gdal/pull/9724 > > (that said, tests reprojecting from 4326 to 3857 while ignoring the > geotransform are a bit weird) > > Even > > -- http://www.spatialys.com > My software is free, but my time generally not. > > -- Sean Gillies ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 3.9.0beta1 available for testing
Thanks, Jukka! On Mon, Apr 22, 2024 at 10:48 AM Rahkonen Jukka < jukka.rahko...@maanmittauslaitos.fi> wrote: > Hi, > > > > The mask thing may happen due to https://github.com/OSGeo/gdal/pull/9604. > > > > -Jukka Rahkonen- > > > > *Lähettäjä:* gdal-dev *Puolesta *Sean > Gillies via gdal-dev > *Lähetetty:* maanantai 22. huhtikuuta 2024 19.15 > *Vastaanottaja:* Even Rouault > *Kopio:* gdal-dev@lists.osgeo.org > *Aihe:* Re: [gdal-dev] GDAL 3.9.0beta1 available for testing > > > > Hi Even, > > > > Rasterio's test suite has 4 errors with GDAL 3.9.0beta1. > > > > Metadata output of gdalinfo has changed. As soon as there are docker > images I'll look more closely at this. > > > > Writing a mask to a Rasterio RGB.byte.tif dataset no longer creates a > RGB.byte.tif.msk > file: > https://github.com/rasterio/rasterio/actions/runs/8786444142/job/24109342188#step:8:2231 > . > > > > The text of an error message which was "tests/data/corrupt.tif, band 1: > IReadBlock failed at X offset 1, Y offset 1: TIFFReadEncodedTile() failed." > in 3.8 has changed to "corrupt.tif, band 1: IReadBlock failed at X offset > 1, Y offset 1: TIFFReadEncodedTile() failed." This is not a big deal, we > can adjust Rasterio's test. > > > > Behavior of SRC_METHOD/DST_METHOD=NO_GEOTRANSFORM for warp options seems > to have changed: > https://github.com/rasterio/rasterio/actions/runs/8786444142/job/24109342188#step:8:2287. > I'm not entirely sure what the intent is in Rasterio's test, will dig into > that. I just wanted to say that I see a change in GDAL. > > > > > > On Mon, Apr 22, 2024 at 6:12 AM Even Rouault via gdal-dev < > gdal-dev@lists.osgeo.org> wrote: > > Hi, > > I've prepared a beta1 of GDAL 3.9.0 to get feedback from early testers. > > The NEWS file is here: > >https://github.com/OSGeo/gdal/blob/v3.9.0beta1/NEWS.md > > For packagers, > https://gdal.org/development/rfc/rfc96_deferred_plugin_loading.html may > make it more attractive to build some drivers that typically have heavy > dependencies as plugins, installable in separate packages, due to the > load time penalty having being improved. It is let to the appreciation > of packagers to decide which drivers are worth building as plugins > installable in a separate package. > You may also pass CMake options > ([GDAL/OGR]_DRIVER__PLUGIN_INSTALLATION_MESSAGE=xxx) so > user get a hint of which package they need to install when GDAL detects > that a file may be opened by a plugin which is not available on the file > system but known to have been built as a plugin. Cf > > https://gdal.org/development/building_from_source.html#deferred-loaded-plugins > for more details. > > For end-users, the following utilities have been updated to use a new > argument parsing framework: gdaladdo, gdalinfo, gdal_translate, > gdalwarp, gdal_grid, gdal_viewshed, gdalbuildvrt, nearblack, ogrinfo, > ogr2ogr, sozip. > This helps detecting errors such as specifying twice an argument that > should be specified once (where generally the last instance was the one > used). While we have tried to retain backwards compatibility for nominal > use cases, obviously if you have scripts that accidentally specify an > argument several times whereas it should be specified at most once, they > will have to be corrected. > > Docker images with 3.9.0beta1 are currently cooking. > > master is now marked as 3.10.0dev, and the release/3.9 branch has been > created. All bugfixes for 3.9 should be backported into it. > > Source snapshots at: > > - https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.gz > - https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.xz > - https://download.osgeo.org/gdal/3.9.0/gdal380beta1.zip > > Autotest snapshots: > > - https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.tar.gz > - https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.zip > > Even > > > > -- > > Sean Gillies > -- Sean Gillies ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 3.9.0beta1 available for testing
Holger, thanks for the report. This should be fixed per https://github.com/OSGeo/gdal/commit/fba559b5bd8d33aac215681df4f6a613517a6c43 which I've backported to the release/3.9 branch A workaround is to explicitly run "cmake --target generate_gdal_version_h" before building all other targets Even Le 22/04/2024 à 23:28, Holger Jaekel via gdal-dev a écrit : Hi Even, Am 22.04.24 um 14:12 schrieb Even Rouault via gdal-dev: I've prepared a beta1 of GDAL 3.9.0 to get feedback from early testers. I tried to build on Alpine Linux Edge and got the following error: /builds/hjaekel/aports/community/gdal/src/gdal-3.9.0beta1/ogr/ogr_core.h:38:10: fatal error: gdal_version.h: No such file or directory 38 | #include "gdal_version.h" | ^~~~ compilation terminated. gdal_version.h seems not to be generated to build/gcore. You can find the full build logs here: https://gitlab.alpinelinux.org/hjaekel/aports/-/pipelines/228841 Holger ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- 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
Re: [gdal-dev] GDAL 3.9.0beta1 available for testing
Hi Even, Am 22.04.24 um 14:12 schrieb Even Rouault via gdal-dev: I've prepared a beta1 of GDAL 3.9.0 to get feedback from early testers. I tried to build on Alpine Linux Edge and got the following error: /builds/hjaekel/aports/community/gdal/src/gdal-3.9.0beta1/ogr/ogr_core.h:38:10: fatal error: gdal_version.h: No such file or directory 38 | #include "gdal_version.h" | ^~~~ compilation terminated. gdal_version.h seems not to be generated to build/gcore. You can find the full build logs here: https://gitlab.alpinelinux.org/hjaekel/aports/-/pipelines/228841 Holger ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 3.9.0beta1 available for testing
It should have read https://download.osgeo.org/gdal/3.9.0/gdal390beta1.zip Le 22/04/2024 à 21:29, Abel Pau via gdal-dev a écrit : Hi, I only want to advice that https://download.osgeo.org/gdal/3.9.0/gdal380beta1.zip is not found. Thanks. -Mensaje original- De: gdal-dev En nombre de Even Rouault via gdal-dev Enviado el: dilluns, 22 d’abril de 2024 14:13 Para: gdal-dev@lists.osgeo.org Asunto: [gdal-dev] GDAL 3.9.0beta1 available for testing Hi, I've prepared a beta1 of GDAL 3.9.0 to get feedback from early testers. The NEWS file is here: https://github.com/OSGeo/gdal/blob/v3.9.0beta1/NEWS.md For packagers, https://gdal.org/development/rfc/rfc96_deferred_plugin_loading.html may make it more attractive to build some drivers that typically have heavy dependencies as plugins, installable in separate packages, due to the load time penalty having being improved. It is let to the appreciation of packagers to decide which drivers are worth building as plugins installable in a separate package. You may also pass CMake options ([GDAL/OGR]_DRIVER__PLUGIN_INSTALLATION_MESSAGE=xxx) so user get a hint of which package they need to install when GDAL detects that a file may be opened by a plugin which is not available on the file system but known to have been built as a plugin. Cf https://gdal.org/development/building_from_source.html#deferred-loaded-plugins for more details. For end-users, the following utilities have been updated to use a new argument parsing framework: gdaladdo, gdalinfo, gdal_translate, gdalwarp, gdal_grid, gdal_viewshed, gdalbuildvrt, nearblack, ogrinfo, ogr2ogr, sozip. This helps detecting errors such as specifying twice an argument that should be specified once (where generally the last instance was the one used). While we have tried to retain backwards compatibility for nominal use cases, obviously if you have scripts that accidentally specify an argument several times whereas it should be specified at most once, they will have to be corrected. Docker images with 3.9.0beta1 are currently cooking. master is now marked as 3.10.0dev, and the release/3.9 branch has been created. All bugfixes for 3.9 should be backported into it. Source snapshots at: - https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.gz - https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.xz - https://download.osgeo.org/gdal/3.9.0/gdal380beta1.zip Autotest snapshots: - https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.tar.gz - https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.zip 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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- 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
Re: [gdal-dev] GDAL 3.9.0beta1 available for testing
Hi, I only want to advice that https://download.osgeo.org/gdal/3.9.0/gdal380beta1.zip is not found. Thanks. -Mensaje original- De: gdal-dev En nombre de Even Rouault via gdal-dev Enviado el: dilluns, 22 d’abril de 2024 14:13 Para: gdal-dev@lists.osgeo.org Asunto: [gdal-dev] GDAL 3.9.0beta1 available for testing Hi, I've prepared a beta1 of GDAL 3.9.0 to get feedback from early testers. The NEWS file is here: https://github.com/OSGeo/gdal/blob/v3.9.0beta1/NEWS.md For packagers, https://gdal.org/development/rfc/rfc96_deferred_plugin_loading.html may make it more attractive to build some drivers that typically have heavy dependencies as plugins, installable in separate packages, due to the load time penalty having being improved. It is let to the appreciation of packagers to decide which drivers are worth building as plugins installable in a separate package. You may also pass CMake options ([GDAL/OGR]_DRIVER__PLUGIN_INSTALLATION_MESSAGE=xxx) so user get a hint of which package they need to install when GDAL detects that a file may be opened by a plugin which is not available on the file system but known to have been built as a plugin. Cf https://gdal.org/development/building_from_source.html#deferred-loaded-plugins for more details. For end-users, the following utilities have been updated to use a new argument parsing framework: gdaladdo, gdalinfo, gdal_translate, gdalwarp, gdal_grid, gdal_viewshed, gdalbuildvrt, nearblack, ogrinfo, ogr2ogr, sozip. This helps detecting errors such as specifying twice an argument that should be specified once (where generally the last instance was the one used). While we have tried to retain backwards compatibility for nominal use cases, obviously if you have scripts that accidentally specify an argument several times whereas it should be specified at most once, they will have to be corrected. Docker images with 3.9.0beta1 are currently cooking. master is now marked as 3.10.0dev, and the release/3.9 branch has been created. All bugfixes for 3.9 should be backported into it. Source snapshots at: - https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.gz - https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.xz - https://download.osgeo.org/gdal/3.9.0/gdal380beta1.zip Autotest snapshots: - https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.tar.gz - https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.zip 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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 3.9.0beta1 available for testing
Sean, Rasterio's test suite has 4 errors with GDAL 3.9.0beta1. Metadata output of gdalinfo has changed. ok, I've run locally rasterio tests and I see gdalinfo now outputs: Metadata: a=1 b=2 AREA_OR_POINT=Area whereas the test expects Metadata: a=1 AREA_OR_POINT=Area b=2 Order of metadata items shouldn't be relied upon. I believe we have changed something internally (likely changing from char** to CPLStringList that does sorting) that might indeed have affected it. You could also potentially use "gdalinfo -json" output to get something easier to parse. But don't you have a rasterio API to get GDAL metadata that would avoid using gdalinfo at all? As soon as there are docker images I'll look more closely at this. ghcr.io/osgeo/gdal:ubuntu-full-3.9.0beta1 is already available Writing a mask to a Rasterio RGB.byte.tif dataset no longer creates a RGB.byte.tif.msk file: https://github.com/rasterio/rasterio/actions/runs/8786444142/job/24109342188#step:8:2231. Yes, this is intended. Due to this change: GTiff driver: * change default value of GDAL_TIFF_INTERNAL_MASK config option to YES You might run the test under GDAL_TIFF_INTERNAL_MASK=NO if you want to test external mask. The text of an error message which was "tests/data/corrupt.tif, band 1: IReadBlock failed at X offset 1, Y offset 1: TIFFReadEncodedTile() failed." in 3.8 has changed to "corrupt.tif, band 1: IReadBlock failed at X offset 1, Y offset 1: TIFFReadEncodedTile() failed." This is not a big deal, we can adjust Rasterio's test. Yes, related to https://github.com/OSGeo/gdal/commit/cb5161d907e8b4fa5cb68aaf891c1a258d6475b0 Behavior of SRC_METHOD/DST_METHOD=NO_GEOTRANSFORM for warp options seems to have changed: https://github.com/rasterio/rasterio/actions/runs/8786444142/job/24109342188#step:8:2287. I'm not entirely sure what the intent is in Rasterio's test, will dig into that. I just wanted to say that I see a change in GDAL. ok, this is related to https://github.com/OSGeo/gdal/pull/9336 , which indeed wasn't honoring the SRC_METHOD=NO_GEOTRANSFORM and was using directly the geotransform from the source dataset. Fix queued in https://github.com/OSGeo/gdal/pull/9724 (that said, tests reprojecting from 4326 to 3857 while ignoring the geotransform are a bit weird) 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
Re: [gdal-dev] GDAL 3.9.0beta1 available for testing
Hi, The mask thing may happen due to https://github.com/OSGeo/gdal/pull/9604. -Jukka Rahkonen- Lähettäjä: gdal-dev Puolesta Sean Gillies via gdal-dev Lähetetty: maanantai 22. huhtikuuta 2024 19.15 Vastaanottaja: Even Rouault Kopio: gdal-dev@lists.osgeo.org Aihe: Re: [gdal-dev] GDAL 3.9.0beta1 available for testing Hi Even, Rasterio's test suite has 4 errors with GDAL 3.9.0beta1. Metadata output of gdalinfo has changed. As soon as there are docker images I'll look more closely at this. Writing a mask to a Rasterio RGB.byte.tif dataset no longer creates a RGB.byte.tif.msk file: https://github.com/rasterio/rasterio/actions/runs/8786444142/job/24109342188#step:8:2231. The text of an error message which was "tests/data/corrupt.tif, band 1: IReadBlock failed at X offset 1, Y offset 1: TIFFReadEncodedTile() failed." in 3.8 has changed to "corrupt.tif, band 1: IReadBlock failed at X offset 1, Y offset 1: TIFFReadEncodedTile() failed." This is not a big deal, we can adjust Rasterio's test. Behavior of SRC_METHOD/DST_METHOD=NO_GEOTRANSFORM for warp options seems to have changed: https://github.com/rasterio/rasterio/actions/runs/8786444142/job/24109342188#step:8:2287. I'm not entirely sure what the intent is in Rasterio's test, will dig into that. I just wanted to say that I see a change in GDAL. On Mon, Apr 22, 2024 at 6:12 AM Even Rouault via gdal-dev mailto:gdal-dev@lists.osgeo.org>> wrote: Hi, I've prepared a beta1 of GDAL 3.9.0 to get feedback from early testers. The NEWS file is here: https://github.com/OSGeo/gdal/blob/v3.9.0beta1/NEWS.md For packagers, https://gdal.org/development/rfc/rfc96_deferred_plugin_loading.html may make it more attractive to build some drivers that typically have heavy dependencies as plugins, installable in separate packages, due to the load time penalty having being improved. It is let to the appreciation of packagers to decide which drivers are worth building as plugins installable in a separate package. You may also pass CMake options ([GDAL/OGR]_DRIVER__PLUGIN_INSTALLATION_MESSAGE=xxx) so user get a hint of which package they need to install when GDAL detects that a file may be opened by a plugin which is not available on the file system but known to have been built as a plugin. Cf https://gdal.org/development/building_from_source.html#deferred-loaded-plugins for more details. For end-users, the following utilities have been updated to use a new argument parsing framework: gdaladdo, gdalinfo, gdal_translate, gdalwarp, gdal_grid, gdal_viewshed, gdalbuildvrt, nearblack, ogrinfo, ogr2ogr, sozip. This helps detecting errors such as specifying twice an argument that should be specified once (where generally the last instance was the one used). While we have tried to retain backwards compatibility for nominal use cases, obviously if you have scripts that accidentally specify an argument several times whereas it should be specified at most once, they will have to be corrected. Docker images with 3.9.0beta1 are currently cooking. master is now marked as 3.10.0dev, and the release/3.9 branch has been created. All bugfixes for 3.9 should be backported into it. Source snapshots at: - https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.gz - https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.xz - https://download.osgeo.org/gdal/3.9.0/gdal380beta1.zip Autotest snapshots: - https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.tar.gz - https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.zip Even -- Sean Gillies ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 3.9.0beta1 available for testing
Hi Even, Rasterio's test suite has 4 errors with GDAL 3.9.0beta1. Metadata output of gdalinfo has changed. As soon as there are docker images I'll look more closely at this. Writing a mask to a Rasterio RGB.byte.tif dataset no longer creates a RGB.byte.tif.msk file: https://github.com/rasterio/rasterio/actions/runs/8786444142/job/24109342188#step:8:2231 . The text of an error message which was "tests/data/corrupt.tif, band 1: IReadBlock failed at X offset 1, Y offset 1: TIFFReadEncodedTile() failed." in 3.8 has changed to "corrupt.tif, band 1: IReadBlock failed at X offset 1, Y offset 1: TIFFReadEncodedTile() failed." This is not a big deal, we can adjust Rasterio's test. Behavior of SRC_METHOD/DST_METHOD=NO_GEOTRANSFORM for warp options seems to have changed: https://github.com/rasterio/rasterio/actions/runs/8786444142/job/24109342188#step:8:2287. I'm not entirely sure what the intent is in Rasterio's test, will dig into that. I just wanted to say that I see a change in GDAL. On Mon, Apr 22, 2024 at 6:12 AM Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hi, > > I've prepared a beta1 of GDAL 3.9.0 to get feedback from early testers. > > The NEWS file is here: > >https://github.com/OSGeo/gdal/blob/v3.9.0beta1/NEWS.md > > For packagers, > https://gdal.org/development/rfc/rfc96_deferred_plugin_loading.html may > make it more attractive to build some drivers that typically have heavy > dependencies as plugins, installable in separate packages, due to the > load time penalty having being improved. It is let to the appreciation > of packagers to decide which drivers are worth building as plugins > installable in a separate package. > You may also pass CMake options > ([GDAL/OGR]_DRIVER__PLUGIN_INSTALLATION_MESSAGE=xxx) so > user get a hint of which package they need to install when GDAL detects > that a file may be opened by a plugin which is not available on the file > system but known to have been built as a plugin. Cf > > https://gdal.org/development/building_from_source.html#deferred-loaded-plugins > for more details. > > For end-users, the following utilities have been updated to use a new > argument parsing framework: gdaladdo, gdalinfo, gdal_translate, > gdalwarp, gdal_grid, gdal_viewshed, gdalbuildvrt, nearblack, ogrinfo, > ogr2ogr, sozip. > This helps detecting errors such as specifying twice an argument that > should be specified once (where generally the last instance was the one > used). While we have tried to retain backwards compatibility for nominal > use cases, obviously if you have scripts that accidentally specify an > argument several times whereas it should be specified at most once, they > will have to be corrected. > > Docker images with 3.9.0beta1 are currently cooking. > > master is now marked as 3.10.0dev, and the release/3.9 branch has been > created. All bugfixes for 3.9 should be backported into it. > > Source snapshots at: > > - https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.gz > - https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.xz > - https://download.osgeo.org/gdal/3.9.0/gdal380beta1.zip > > Autotest snapshots: > > - https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.tar.gz > - https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.zip > > Even > > -- Sean Gillies ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL 3.9.0beta1 available for testing
Robert, If you want to use ready-made binaries, then using Conda gdal-master builds might be the easiest way for all major platforms: https://gdal.org/download.html#gdal-master-conda-builds . They track gdal master, but that's more or less the same as 3.9.0beta1 right now. Otherwise if you want to build from source, you can take inspiration from the build recipe we use for continuous integration: https://github.com/OSGeo/gdal/blob/master/.github/workflows/ubuntu_22.04/Dockerfile.ci https://github.com/OSGeo/gdal/blob/master/.github/workflows/ubuntu_22.04/build.sh (you don't necessarily need all the dependencies) And as I mentioned, Docker images are building. Should be ready by tomorrow. Even Le 22/04/2024 à 15:18, Robert Hewlett via gdal-dev a écrit : Any advice on how to become a tester such as testing on prefered OS and setup? I have access to a proxmox server but I usually stick to LINUX OSes. Or is at easy as following the notes here: https://gdal.org/development/dev_environment.html Ubuntu 22.x is the goto right now. Any advice would be appreciated. Rob On Mon, Apr 22, 2024 at 5:12 AM Even Rouault via gdal-dev wrote: Hi, I've prepared a beta1 of GDAL 3.9.0 to get feedback from early testers. The NEWS file is here: https://github.com/OSGeo/gdal/blob/v3.9.0beta1/NEWS.md For packagers, https://gdal.org/development/rfc/rfc96_deferred_plugin_loading.html may make it more attractive to build some drivers that typically have heavy dependencies as plugins, installable in separate packages, due to the load time penalty having being improved. It is let to the appreciation of packagers to decide which drivers are worth building as plugins installable in a separate package. You may also pass CMake options ([GDAL/OGR]_DRIVER__PLUGIN_INSTALLATION_MESSAGE=xxx) so user get a hint of which package they need to install when GDAL detects that a file may be opened by a plugin which is not available on the file system but known to have been built as a plugin. Cf https://gdal.org/development/building_from_source.html#deferred-loaded-plugins for more details. For end-users, the following utilities have been updated to use a new argument parsing framework: gdaladdo, gdalinfo, gdal_translate, gdalwarp, gdal_grid, gdal_viewshed, gdalbuildvrt, nearblack, ogrinfo, ogr2ogr, sozip. This helps detecting errors such as specifying twice an argument that should be specified once (where generally the last instance was the one used). While we have tried to retain backwards compatibility for nominal use cases, obviously if you have scripts that accidentally specify an argument several times whereas it should be specified at most once, they will have to be corrected. Docker images with 3.9.0beta1 are currently cooking. master is now marked as 3.10.0dev, and the release/3.9 branch has been created. All bugfixes for 3.9 should be backported into it. Source snapshots at: - https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.gz - https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.xz - https://download.osgeo.org/gdal/3.9.0/gdal380beta1.zip Autotest snapshots: - https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.tar.gz - https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.zip 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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- 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
Re: [gdal-dev] GDAL 3.9.0beta1 available for testing
Any advice on how to become a tester such as testing on prefered OS and setup? I have access to a proxmox server but I usually stick to LINUX OSes. Or is at easy as following the notes here: https://gdal.org/development/dev_environment.html Ubuntu 22.x is the goto right now. Any advice would be appreciated. Rob On Mon, Apr 22, 2024 at 5:12 AM Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hi, > > I've prepared a beta1 of GDAL 3.9.0 to get feedback from early testers. > > The NEWS file is here: > >https://github.com/OSGeo/gdal/blob/v3.9.0beta1/NEWS.md > > For packagers, > https://gdal.org/development/rfc/rfc96_deferred_plugin_loading.html may > make it more attractive to build some drivers that typically have heavy > dependencies as plugins, installable in separate packages, due to the > load time penalty having being improved. It is let to the appreciation > of packagers to decide which drivers are worth building as plugins > installable in a separate package. > You may also pass CMake options > ([GDAL/OGR]_DRIVER__PLUGIN_INSTALLATION_MESSAGE=xxx) so > user get a hint of which package they need to install when GDAL detects > that a file may be opened by a plugin which is not available on the file > system but known to have been built as a plugin. Cf > > https://gdal.org/development/building_from_source.html#deferred-loaded-plugins > for more details. > > For end-users, the following utilities have been updated to use a new > argument parsing framework: gdaladdo, gdalinfo, gdal_translate, > gdalwarp, gdal_grid, gdal_viewshed, gdalbuildvrt, nearblack, ogrinfo, > ogr2ogr, sozip. > This helps detecting errors such as specifying twice an argument that > should be specified once (where generally the last instance was the one > used). While we have tried to retain backwards compatibility for nominal > use cases, obviously if you have scripts that accidentally specify an > argument several times whereas it should be specified at most once, they > will have to be corrected. > > Docker images with 3.9.0beta1 are currently cooking. > > master is now marked as 3.10.0dev, and the release/3.9 branch has been > created. All bugfixes for 3.9 should be backported into it. > > Source snapshots at: > > - https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.gz > - https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0beta1.tar.xz > - https://download.osgeo.org/gdal/3.9.0/gdal380beta1.zip > > Autotest snapshots: > > - https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.tar.gz > - https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0beta1.zip > > 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 > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
