Re: [gdal-dev] pixel class

Le 31/07/2024 à 10:19, Javier Jimenez Shaw via gdal-dev a écrit : Hi I am working in an algorithm that uses a lot of pixel positions both as int and double, offset of pixels, etc. Is there any class that avoids me to use a variable for the x and another for the y... for everything? It would

Re: [gdal-dev] Issue converting geo parquet data

Hi Michael, This error comes very deep inside libparquet, actually in libthrift. The more natural assumption would be that it would be due to a corrupted Parquet file. If you disabled multithreading (GDAL_NUM_THREADS=1) and enabled --debug on, perhaps this would happen on the same file ? I

Re: [gdal-dev] ogr2ogr postgres index generation

Please file at ticket about that at https://github.com/OSGeo/gdal/issues Le 30/07/2024 à 10:57, Hanskaspar Frei via gdal-dev a écrit : Hi everybody We used an old GDAL Version (3.2.1) to load data to a postgis db with ogr2ogr. There was an automatic spatial index generation taking place, which

Re: [gdal-dev] Changes in conda-forge packaging for GDAL 3.9.1

Le 29/07/2024 à 08:14, Michał Kowalczuk a écrit : Returning to changes conda packaging: My conda installation is ligdal-core + libgdal-jp2openjpeg using miniconda on Windows. . If my *gdal.dll* and dependencies are in *\root *folder and *gdal_JP2OpenJPEG.dll* is in *\root\gdalplugins* folder

Re: [gdal-dev] Band Initialization

Andrew, Is a newly created raster band initialized to zero? If not, is there some trivial way to perform such an initialization (this is a MEM driver raster, if that matters). This might be indeed driver dependent. Drivers will generally initialize to zero or the nodata value. As far as I

Re: [gdal-dev] Motion: Migrate gdal.org to ReadTheDocs

+1 Even Le 25/07/2024 à 17:01, Howard Butler via gdal-dev a écrit : All, I would like to motion to migrate gdal.org from our self-managed GitHub Pages infrastructure to ReadTheDocs. You can read specific details about the migration in the ticket at

Re: [gdal-dev] Changes in conda-forge packaging for GDAL 3.9.1

Le 25/07/2024 à 11:58, Michał Kowalczuk a écrit : Continuing this topic... What should I do if I want to use lightweight version od GDAL (libgdal-corel) only with JP2 driver. Putting libgdal_-jp2openjpg.dll with gdal.dll is not sufficient. If you use conda installation commands (conda

Re: [gdal-dev] Changes in conda-forge packaging for GDAL 3.9.1

Le 24/07/2024 à 22:19, Michał Kowalczuk a écrit : Hi, I've just updated GDAL with conda and I was surprised about number of dependencies that disappeared. It's quite a big change and should be mentioned in the Release Notes, not only here... Don't you think so? The release notes are only

[gdal-dev] Changes in conda-forge packaging for GDAL 3.9.1

Hi, I just wanted to mention recent work done on the GDAL (and PDAL) packaging on conda-forge that may impact your use of the packages for GDAL >= 3.9.1. All details at https://quansight.com/post/introducing-lightweight-versions-of-gdal-and-pdal/ TL;DR version: - new package libgdal-core

Re: [gdal-dev] Building GDAL documentation with ReadTheDocs

Le 24/07/2024 à 12:33, Javier Jimenez Shaw via gdal-dev a écrit : I see the point, and I agree... but I don't know if it will work RTD redirects to whatever we configure. In proj.org it is going directly to 9.4 (current latest release). Seems like a good idea and something

Re: [gdal-dev] kerchunk

Michael, I don't think this would be a frmts/raw driver, but rather a /vsikerchunk virtual file system that you would combine with the Zarr driver So you would open a dataset with "/vsikerchunk/{path/to.json}", and the ZARR driver would then issue a ReadDir() operation on

Re: [gdal-dev] [EXTERNAL] Re: Expected runtime of polygonize (GDAL 3.9.0) for few very large features.

Le 23/07/2024 à 21:08, Meyer, Jesse R. (GSFC-618.0)[SCIENCE SYSTEMS AND APPLICATIONS INC] a écrit : Excellent, thanks Even!  Do you recall what the runtime was before these changes on your test system? I killed the process at about half an hour. Don't recall the progress it reached, maybe

Re: [gdal-dev] Expected runtime of polygonize (GDAL 3.9.0) for few very large features.

Hi, I've got a chance to have a look at your test dataset. In https://github.com/OSGeo/gdal/pull/10477, I've reduced the runtime to 8 minutes (with GeoParquet output, without spatial sorting), by optimizing some implementation details. I believe this could be further reduced as most of the

Re: [gdal-dev] Building GDAL documentation with ReadTheDocs

Le 23/07/2024 à 19:18, Greg Troxel via gdal-dev a écrit : Daniel Baston via gdal-dev writes: Hello, I've put together a configuration to build GDAL's documentation using ReadTheDocs. As far as I know, this is the simplest way of publishing version-specific documentation and rending

Re: [gdal-dev] r option in gdaladdo

Javier, I've just advertized bilinear. For average_mp vs average_magphase, they are indeed different code paths. My understanding of the code is that: - average_magphase is only available for the complex data types - for the complex data types, average_magphase makes sure that the norm of

Re: [gdal-dev] Extracting data from a parquet file

Le 22/07/2024 à 21:10, Joaquim Manuel Freire Luís a écrit : Even, Thanks for the explanation. But how did you find the name of the geometries (geo_point_2D and geo_shape)? Loading the “world-administrative-boundaries.parquet” in a binary editor I can see them there, but that’s certainly

Re: [gdal-dev] Unknown ASCII raster format

Javier, yes I've came across similarly looking grid files occasionally. I'm not quite sure which ancestor format is behind. This is a bit similar to the IGN France ASCII grid .mnt format documented at

Re: [gdal-dev] Extracting data from a parquet file

Joaquim, The GeoPackage format only supports one geometry field per layer. and the QGIS OGR provider doesn't know currently how to handle several geometry fields per layer too To do what you want, you need to explictly select the desired geometry field name with: ogr2ogr out.gpkg

Re: [gdal-dev] GTI datasets: overview usage question

Salut Thomas, There were actually 2 issues: - contrary to what the documentation stated, OVERVIEW_0_ metadata items were simply ignored, hence you only got overviews starting at the 1/4 reduction - and the documentation also lied when implying that it would automatically add overviews

Re: [gdal-dev] NEWS.md for last release

Hi Javier, Just a logical consequence of how the release process works. Bug fixes releases are done from the release/3.9 branch, so the NEWS.md file for a 3.9.x release is edited there, and not in master. And we don't forward port the changes of the NEWS.md from release/* branches to master.

Re: [gdal-dev] Problems compiling the project

Hi Abel, the error message indicates that the build is trying to link a release version of poppler.lib, whereas your build is a debug one. For multi-config generators like Visual Studio builds, I'm not sure how -DCMAKE_BUILD_TYPE=Debug is effective. You perhaps need to do the following

Re: [gdal-dev] Documentation/explanation on repository structure

Hi, hopefully this proposed improvement of the developer doc https://github.com/OSGeo/gdal/pull/10427 should answer your questions Even Le 14/07/2024 à 21:57, Thomas Larsen Wessel via gdal-dev a écrit : It's hard for me to understand the structure of the repository. Is there any

Re: [gdal-dev] GDAL 3.7.0 Proj 6.3.1 strange behavior when performing NAD83(EPSG:4152) to NAD83 HARN(EPSG:4269) realization transformation

Support for US datum transformations has been vastly improved in PROJ 9.2.0 with NADCON5 grid based transformations Le 15/07/2024 à 17:46, David Klaus via gdal-dev a écrit : Greg, Thank you for that information. I will post my example code shortly. Hopefully there is an obvious mistake in my

Re: [gdal-dev] gdal docker with numpy2-compatible python bindings

Hi, I hoped that the python bindings in the docker image would be compatible with both numpy 1 and 2, but apparently they're not? Would it be possible to create docker images with bindings that are compatible with numpy2? Or would you rather wait until the official ubuntu numpy package moves

Re: [gdal-dev] WMTS cache

yes, you can set the GDAL_DEFAULT_WMS_CACHE_PATH configuration option. It is already mentioned at https://gdal.org/drivers/raster/wmts.html, although not that much visible. I've submitted https://github.com/OSGeo/gdal/pull/10398 to improve that. In the meantime, you can refer to

Re: [gdal-dev] can GDAL render two images as if over-plotted?

Michael, I'm not totally sure if image composition really belongs to gdaldem. It feels it is more generic than that, although making nice looking DEM rendering is definitely a common use case. There's this long existing Python script at

Re: [gdal-dev] [EXTERNAL] [BULK] Re: GetPoint API listing

The doc for the OGRSimpleCurve class, which is the parent class of OGRLineString, where addPoint / setPoint are defined, was missing in that page. Should appear online in ~ 1 hour or so. The Doxygen output at https://gdal.org/doxygen/classOGRLineString.html might be easier to navigate. Le

Re: [gdal-dev] Building GDAL on Ubuntu 22.04

and dependencies in vcpkg, breaking Android.) Kai Am 06.07.24 um 09:59 schrieb Even Rouault via gdal-dev: Hi, when using CLang, GDAL forces the use of libstdc++ for linking, so seeing "cannot find -lstdc++", I suspect you might lack the installation of libstdc++-11-dev pack

Re: [gdal-dev] Mosaic of multidimensional datasets of varying resolution

Hi, Dear list, I have a question about mosaicing multidimensional datasets (netCDF, Zarr etc). These are typically 2 or 3D grids with a time dimension from weather or ocean models (3 or 4D in total). Using a multidimensional VRT: https://gdal.org/drivers/raster/vrt_multidimensional.html

Re: [gdal-dev] Building GDAL on Ubuntu 22.04

Hi, when using CLang, GDAL forces the use of libstdc++ for linking, so seeing "cannot find -lstdc++", I suspect you might lack the installation of libstdc++-11-dev package Even Le 04/07/2024 à 08:01, Eric Knudstrup via gdal-dev a écrit : I'm using WEBP, so the 3.4.1 release of GDAL that

Re: [gdal-dev] ogrinfo behaviour with -al and -json options

Hi, Le 03/07/2024 à 07:25, Andrea Giudiceandrea via gdal-dev a écrit : Hi all, IIUC, the documentation states that with the -al option, ogrinfo should output the info of all layers in a container (e.g. a GPKG file). Anyway, when a layer name is provided in the command line string alongside

Re: [gdal-dev] GDAL 3.9: How to pass negative flag values to GDALArgumentParser?

Hi Craig, this is indeed a regression. I'm on it Even Le 02/07/2024 à 06:39, Craig de Stigter via gdal-dev a écrit : A colleague has noticed a workaround: prefix the argument with a space: $ gdalwarp '-dstnodata' ' -inf' ... On Tue, 2 Jul 2024 at 16:04, Craig de Stigter wrote:

Re: [gdal-dev] Fwd: WMTS huge difference in performance - cache issue

Michał, Le 01/07/2024 à 18:49, Michał Kowalczuk via gdal-dev a écrit : Did my email reached gdal mailing list? yes, it did. I just had a look There's indeed an issue in the WMTS driver which I've ticketed at https://github.com/OSGeo/gdal/issues/10348 . See bottom of the ticket for a

Re: [gdal-dev] Expected runtime of polygonize (GDAL 3.9.0) for few very large features.

I’m able to share the problematic tile(s) if of interest, Yes, please do Even -- http://www.spatialys.com My software is free, but my time generally not. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org

Re: [gdal-dev] Detecting SPARSE rasters

Jon, Recommended solution: use GDALRasterBand::GetDataCoverageStatus() with nXOff, nYOff, nXSize, nYSize matching tile offset and size and check forGDAL_DATA_COVERAGE_STATUS_EMPTY. Cf https://gdal.org/development/rfc/rfc63_sparse_datasets_improvements.html (undocumented solution, mostly

Re: [gdal-dev] GDAL 3.9.1 is released

The Docker images are now available: https://github.com/OSGeo/gdal/tree/master/docker#images-of-releases Even Le 26/06/2024 à 13:53, Even Rouault via gdal-dev a écrit : Hi, On behalf of the GDAL/OGR development team, I am pleased to announce the release of the GDAL/OGR 3.9.1 bug fix version

Re: [gdal-dev] Anyway to embed credential options into a VRT?

Hi Nyall, Reading through the vrt schema, I see that there's currently support for open options for sources, but I can't see any support documented for VSI credential options. Has this been considered in the past? not that I'm aware of I'm unsure if it's an omission by design (i.e.

[gdal-dev] GDAL 3.9.1 is released

Hi, On behalf of the GDAL/OGR development team, I am pleased to announce the release of the GDAL/OGR 3.9.1 bug fix version. Consult the release notes for the list of issues addressed:     https://github.com/OSGeo/gdal/blob/v3.9.1/NEWS.md The sources are available at:    

Re: [gdal-dev] GDAL 3.9.1 RC2 is available, and motion to approve it

Motion passed with +1 from PSC members: JukkaR, TamasS, HowardB, JJShaw and me Le 23/06/2024 à 00:13, Even Rouault via gdal-dev a écrit : I've issued a 2nd release candidate for 3.9.1 with the following additional fixes: - GDALSieveFilter(): avoid assert() when all pixels are masked (3.9.0

Re: [gdal-dev] testclosedondestroydm.test

 : On Tue, 25 Jun 2024, Even Rouault via gdal-dev wrote: Le 25/06/2024 à 16:52, Andrew C Aitchison a écrit : On Tue, 25 Jun 2024, Even Rouault wrote: Le 25/06/2024 à 16:25, Andrew C Aitchison a écrit : On Tue, 25 Jun 2024, Even Rouault via gdal-dev wrote: Can you run "gdb autotes

Re: [gdal-dev] testclosedondestroydm.test

Le 25/06/2024 à 16:52, Andrew C Aitchison a écrit : On Tue, 25 Jun 2024, Even Rouault wrote: Le 25/06/2024 à 16:25, Andrew C Aitchison a écrit : On Tue, 25 Jun 2024, Even Rouault via gdal-dev wrote: Can you run "gdb autotest/cpp/testclosedondestroydm" , "run" , and whe

Re: [gdal-dev] testclosedondestroydm.test

Le 25/06/2024 à 16:25, Andrew C Aitchison a écrit : On Tue, 25 Jun 2024, Even Rouault via gdal-dev wrote: Can you run "gdb autotest/cpp/testclosedondestroydm" , "run" , and when it crashed "bt" so we have a backtrace of where it crashes  (all of that af

Re: [gdal-dev] testclosedondestroydm.test

Can you run "gdb autotest/cpp/testclosedondestroydm" , "run" , and when it crashed "bt" so we have a backtrace of where it crashes  (all of that after running "source ../scripts/setdevenv.sh") Le 25/06/2024 à 15:14, Andrew C Aitchison via gdal-dev a écrit : This is not a new failure, so thre

Re: [gdal-dev] Error linking srsinfo in 3.9.1 (rc1 or rc2)

Le 24/06/2024 à 19:15, Scott a écrit : It's Debian 12. No, it's not clean. It's had several versions of gdal, et al, on it. It appears srsinfo in not finding stdlib.h and all the other apps do, which is the part I found odd. Docker is not the environment I'm building in. yes, but that's

Re: [gdal-dev] Error linking srsinfo in 3.9.1 (rc1 or rc2)

Hi, What is the version of your Debian system ? Is it "clean" ? Can you for example reproduce in the corresponding debian:XXX docker image? https://www.google.com/search?q=fatal+error%3A+stdlib.h%3A+No+such+file+or+directory+; shows that this error message is quite common, although on quick

Re: [gdal-dev] GDAL 3.9.1 RC2 is available, and motion to approve it

Forgot to add my +1 obviously Le 23/06/2024 à 00:13, Even Rouault via gdal-dev a écrit : I've issued a 2nd release candidate for 3.9.1 with the following additional fixes: - GDALSieveFilter(): avoid assert() when all pixels are masked (3.9.0 regression)   (raster/rasterio#3101) - Overview

[gdal-dev] GDAL 3.9.1 RC2 is available, and motion to approve it

I've issued a 2nd release candidate for 3.9.1 with the following additional fixes: - GDALSieveFilter(): avoid assert() when all pixels are masked (3.9.0 regression)   (raster/rasterio#3101) - Overview generation: fix multi-threaded bug, resulting in locks/crashes with   GeoPackage in

Re: [gdal-dev] Motion: Adopt GDAL 3.9.1RC1 as 3.9.1 release

Changing my vote to -1. I've just discovered a few recent regressions of 3.9.1 that were not in 3.9.0 (last 2 commits of https://github.com/OSGeo/gdal/pull/10267) I'm going to prepare a 3.9.1RC2. Le 20/06/2024 à 14:52, Even Rouault via gdal-dev a écrit : Hi, Motion: Adopt GDAL 3.9.1RC1

Re: [gdal-dev] Motion: Adopt GDAL 3.9.1RC1 as 3.9.1 release

Andrew, As Greg said, 25 hours isn't long to test There's also a 2 business days phase after the motion has been initiated before declaring it passed, which will lead to us after the week end, so if someone finds something critical enough, that can still be taken into account. Hard to know

Re: [gdal-dev] Question: Layer intersection in Python

Luis, the issue is that shapefile layers do not really support a genuine unknown layer geometry type. They accept it on layer creation, but as soon as you write the first feature into it, the feature layer geometry type is used as the layer geometry type, and shapefile don't accept a mix of

[gdal-dev] Motion: Adopt GDAL 3.9.1RC1 as 3.9.1 release

Hi, Motion: Adopt GDAL 3.9.1RC1 as 3.9.1 release Starting with my +1 Even -- http://www.spatialys.com My software is free, but my time generally not. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org

[gdal-dev] GDAL 3.9.1 release candidate available

Hi, I have prepared a GDAL/OGR 3.9.1 release candidate. Pick up an archive among the following ones (by ascending size):   https://download.osgeo.org/gdal/3.9.1/gdal-3.9.1rc1.tar.xz   https://download.osgeo.org/gdal/3.9.1/gdal-3.9.1rc1.tar.gz  

Re: [gdal-dev] Changing many features in a GPKG in a transaction, why is the index updated?

Hi Nyall, What you observe is fully expected. The spatial index must be kept fully in sync with the changes in the feature table, even when run within a transaction. Otherwise if during the transaction you would execute a spatial query, you would get inconsistents result if the spatial index

Re: [gdal-dev] gdal2xyz

Le 11/06/2024 à 21:31, Even Rouault via gdal-dev a écrit : Le 11/06/2024 à 21:22, Andrew Bell via gdal-dev a écrit : Hi, The documentation describes an application `gdal2xyz`, but I don't see one built in my development environment. I also don't see anything in the CMakeLists.txt

Re: [gdal-dev] gdal2xyz

Le 11/06/2024 à 21:22, Andrew Bell via gdal-dev a écrit : Hi, The documentation describes an application `gdal2xyz`, but I don't see one built in my development environment. I also don't see anything in the CMakeLists.txt that refers to it. Is it named something I'm not expecting? Does it

Re: [gdal-dev] ogr2ogr no longer works with non super user in PG after update

Hi, The issue has been reported in https://github.com/OSGeo/gdal/issues/9994 and should be be fixed in 3.9.1 per https://github.com/OSGeo/gdal/pull/10004 (testing of the 3.9 branch at https://github.com/OSGeo/gdal/tree/release/3.9 would be appreciated to confirm that it fixes error for

Re: [gdal-dev] GDALGetGeoTransform

Johannes, access to your DIMAP product would be needed to investigate. I assume the product also returns RPC?   If so, test GetMetadata("RPC") != null, and if it does, you can likely consider than any GeoTransform is "garbage". If you have RPCs, you can directly compute a geotransform. You

Re: [gdal-dev] Adding multiple TREs to a NITF using gdal_translate

Le 11/06/2024 à 12:11, Marek Setnik via gdal-dev a écrit : Hello! I'm having trouble with adding multiple TREs to a NITF file (using C++ API), the documentation mentions that the TRE creation options allows for that but I can't figure out the syntax, how do I achieve something like this:

Re: [gdal-dev] Discrepancy in utilizing overviews with gdalwarp

Filed as https://github.com/OSGeo/gdal/issues/10174 Le 10/06/2024 à 10:57, Denis Rykov via gdal-dev a écrit : Thank you, Jukka, for reproducing the behavior and explaining the reason behind it! On Mon, Jun 10, 2024 at 9:19 AM Rahkonen Jukka wrote: Hi, Those two commands behave in

Re: [gdal-dev] pre-commit hook failure

Andrew, https://stackoverflow.com/questions/75591296/entrypoints-object-has-no-attribute-get-during-running-pre-commit would suggest that we should perhaps update the flake8 version in .pre-commit-config.yaml at the root of the GDAL source tree. Can you give a try to

Re: [gdal-dev] get_cli_utility_path_internal

Andrew, obviously this code having essentially passed through the ages since 2008, I don't remember all the details :-) I assume this was an attempt to pick up a binary that could be run and was part of the build tree, instead of a system gdalinfo/etc. binary, but this could likely be

Re: [gdal-dev] doc bugs about prereqs, surfaced by updating pkgsrc for 3.9

Le 06/06/2024 à 20:21, Greg Troxel a écrit : also, I am far from a cmake expert, but I looked in the CMakeFiles and cannot find where they - try to run the compiler with --std=c++17 set(CMAKE_CXX_STANDARD 17) at

Re: [gdal-dev] doc bugs about prereqs, surfaced by updating pkgsrc for 3.9

which is misplaced, because people are who merely intending to compile gdal but not contribute to it, still need to know. I almost didn't even look at it before writing that it wasn't documented which C++ flavor is needed, because it was obviously not about what I needed to know. Attempt to

Re: [gdal-dev] cmake error: IMPORTED_LOCATION not set for imported target "GEOTIFF::GEOTIFF"

Hi, I don't reproduce this on my Linux setup. Can you give more information on: - your operating system - CMake version - cmake command line you used to build libgeotiff - cmake command line you use to build GDAL Also, if you've reused an existing GDAL build directory that was used with a

Re: [gdal-dev] Thread-safe raster access

Andrew, what would be the purpose of thread-safe access: just making it thread-safe without any particular requirement on how efficient this would be (1), or hope for true concurrent access with ideally close to linear scalability with the number of threads (2) ? If (1), then we could add a

Re: [gdal-dev] gdalwarp across the antimeridian with a source extent >180E

Michael, https://github.com/OSGeo/gdal/pull/10108 will fix it. You can also workaround the issue by overriding the extent of the source dataset to be exactly -179.995,89.995,180.005,-89.995 with  

Re: [gdal-dev] OGR SQL CAST geometry example

According to http://www3.sqlite.org/series.html, generate_series() is only built in the sqlite3 command line utility, not in the library itself. That said, with some work, the source at https://www.sqlite.org/src/file/ext/misc/series.c could potentially be embedded into libgdal Le 31/05/2024

Re: [gdal-dev] OGR SQL CAST geometry example

Ah, I misunderstood and thought you wanted to extract points from linestrings. Given $ cat test.csv id,my_wkt 1,"POINT Z (1 2 3)" you can do: $ ogrinfo test.csv -sql "select id, cast(my_wkt as geometry(pointz, 4326)) from test" INFO: Open of `test.csv'   using driver `CSV' successful.

Re: [gdal-dev] OGR SQL CAST geometry example

Dan, you can't do operations on geometries with OGR SQL, but selecting it. You'd typically need to use the ST_PointN() from Spatialite with the SQLite dialect Even Le 31/05/2024 à 00:32, Dan Jacobson via gdal-dev a écrit : Hi. I will add an example to

[gdal-dev] RFC 96 adjustment: Re: Call for review and discussion on RFC96: Deferred in-tree C++ plugin loading

. Pedantically this will be an ABI change (between in-tree drivers built as plugins and core), although I suspect that it shouldn't be noticed for most use scenarios. Not clear if that's worth a SONAME bump for 3.9.1, or if that would be more an annoyance. Even Le 02/11/2023 à 12:59, Even Rouault via

Re: [gdal-dev] GDAL WMTS get tiles no documentation

Hi, The WMS cache (which is used underneath by the WMTS driver) writes each tiles in a separate file. So if you use multi-threaded, as long as you read in parallel different GDALDataset* object on the WMTS filename, and read disjoint areas, that should be fine. There might be a slight risk

[gdal-dev] libgeotiff 1.7.3 is released

Hi, Follow-up release of 1.7.2 to address a regression with CMake builds related to a typo in CMAKE_INSTALL_BINDIR install target that affects location of geotiff.dll (#117) Source packages can be found at: https://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.7.3.tar.gz

[gdal-dev] libgeotiff 1.7.2 is released

Hi, Source packages can be found at: https://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.7.2.tar.gz https://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.7.2.zip News is: * GTIFGetDatumInfoEx(): handle dynamic datums * CMake: adopt GNUInstallDirs * CMake: export TIFF as a public

Re: [gdal-dev] building just the python bindings (cmake)

Le 22/05/2024 à 16:59, Greg Troxel a écrit : I got 3.5 to work, so I'm focusing on the 3.9 upgrade. It seems that 3.9, vs 3.5, has withdrawn the swig generated files from the distfile. With 3.9, you could also do a more manual approach (not sure the python_generated_files target is

Re: [gdal-dev] building just the python bindings (cmake)

Greg, If the build requirements for the Python bindings are met (python + swig available), then a "make && make install" cycle will build and install libgdal and the python bindings, like it did in autoconf era. The CMake build target "python_binding" has libgdal as a dependency. The idea

Re: [gdal-dev] [Geotiff] libgeotiff 1.7.2 release candidate

oops. Here are the corrected URLs: https://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.7.2rc1.tar.gz https://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.7.2rc1.zip Le 21/05/2024 à 15:44, Greg Troxel via Geotiff a écrit : Even Rouault via Geotiff writes: do you mean

[gdal-dev] libgeotiff 1.7.2 release candidate

Hi, I've prepared a libgeotiff 1.7.2 release candidate. https://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.7.1rc2.tar.gz https://download.osgeo.org/geotiff/libgeotiff/libgeotiff-1.7.1rc2.zip I'll promote it to final later this week if nothing serious is reported on it before. News

Re: [gdal-dev] Conda failure in GA

As suggested in the comment of #939, attempting https://github.com/rouault/gdal/commit/1000cfaa950a18bd14b0c72109439cad58c789d5 That fixed it. Merged into master -- http://www.spatialys.com My software is free, but my time generally not. ___

Re: [gdal-dev] Conda failure in GA

It looks like the numpy 2.0 update was pushed to the gdal-feedstock https://github.com/conda-forge/gdal-feedstock/pull/939 (looking like  GDAL must also build and test clean against Numpy 2.0 at this point too). The error is the Conda builder complaining that it can't find Numpy 2.0 because

Re: [gdal-dev] Data Type Conversion

Andrew, Data type conversion is done by GDALCopyWords[64]: https://gdal.org/api/raster_c_api.html#_CPPv415GDALCopyWords64PKv12GDALDataTypeiPv12GDALDataTypei10GPtrDiff_t The doc was a bit outdated, regarding conversion from floating point data types to integer data types. I've just adjusted

Re: [gdal-dev] GPKG to PG single transaction, different schemas

Le 14/05/2024 à 17:30, Matteo Ghetta via gdal-dev a écrit : Hi all, I've a geopackage with many layers (in the following example let's pretend just 2) that I want to import in a single transaction (important!) into a PG database. GPKG and PG table names are the same, but it can happen that

Re: [gdal-dev] Discrepancy in reported Spatial Reference b/n gdalinfo and arcpy

Le 14/05/2024 à 18:08, Liyuneh Gebre a écrit : hi, thanks for your kind commitment.  I tried the docker version and unfortunately it shows the same result. That's expected. The fix has been done post 3.9.0. This will be available in 3.9.1 On Sun, May 12, 2024 at 4:02 PM Even Rouault

Re: [gdal-dev] GDAL 3.9.0 is released

Hi, The GDAL 3.9.0 Docker images are available: * ghcr.io/osgeo/gdal:alpine-small-3.9.0 * ghcr.io/osgeo/gdal:alpine-normal-3.9.0 * ghcr.io/osgeo/gdal:ubuntu-small-3.9.0 * ghcr.io/osgeo/gdal:ubuntu-full-3.9.0 Even Le 10/05/2024 à 16:10, Even Rouault via gdal-dev a écrit : Hi, On behalf

Re: [gdal-dev] Discrepancy in reported Spatial Reference b/n gdalinfo and arcpy

Hi, fix in https://github.com/OSGeo/gdal/pull/9909 Le 12/05/2024 à 12:06, Javier Jimenez Shaw via gdal-dev a écrit : I do not know if there is any documentation from esri about that specific format for LAMBERT_AZIMUTHAL. It would be great. And also I am surprised that in 13 years nobody

[gdal-dev] GDAL 3.9.0 is released

Hi, On behalf of the GDAL/OGR development team and community, I am pleased to announce the release of GDAL/OGR 3.9.0. GDAL/OGR is a C++ geospatial data access library for raster and vector file formats, databases and web services. It includes bindings for several languages, and a variety of

Re: [gdal-dev] Motion: approve GDAL 3.9.02RC2 as final release

Motion passed with +1 from PSC members EvenR, JukkaR and JavierJS Le 08/05/2024 à 13:13, Even Rouault via gdal-dev a écrit : Hi, Motion: Adopt GDAL 3.9.0RC2 as final 3.9.0 release Starting with my +1 Even -- http://www.spatialys.com My software is free, but my time generally

Re: [gdal-dev] Doxygen Arguments

Andrew, this is now fixed per https://github.com/OSGeo/gdal/commit/393eee77b40ae16751e4d2c0ad3e53386b22d025 . Doxygen apparently takes the function/method at declaration time, and not definition time, and we had a number of unnamed parameters in declarations. (I also struggled with weird

Re: [gdal-dev] SQL / gdal_get_pixel_value tips requested

Jesse, the answer lies in exploring available Spatialite SQL functions: https://www.gaia-gis.it/gaia-sins/spatialite-sql-5.1.0.html ST_Centroid() returns a Point geometry. You may get its coordinates with ST_X() and ST_Y(). I suppose you'd need to use a sub-select construct to get things

[gdal-dev] Motion: approve GDAL 3.9.02RC2 as final release

Hi, Motion: Adopt GDAL 3.9.0RC2 as final 3.9.0 release Starting with my +1 Even -- http://www.spatialys.com My software is free, but my time generally not. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org

[gdal-dev] GDAL 3.9.0 rc2 is available (Re: GDAL 3.9.0 rc1 is available)

/gdal/3.9.0/gdal390rc2.zip https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0rc2.tar.gz   https://download.osgeo.org/gdal/3.9.0/gdalautotest-3.9.0rc2.zip Even Le 06/05/2024 à 15:43, Even Rouault via gdal-dev a écrit : Hi, I have prepared a GDAL/OGR 3.9.0 release candidate. NEWS

Re: [gdal-dev] Mass operations to raster block?

Hi Andrew, no, there's no such support in GDAL itself. That could potentially be done using VRT and pixel functions, but I'm not sure that would qualify as "optimal", and that would require a bit of setup. You're probably better instantiating your for(y: ...) for (x: ...) loop manually with

[gdal-dev] GDAL 3.9.0 rc1 is available

Hi, I have prepared a GDAL/OGR 3.9.0 release candidate. NEWS at:   https://github.com/OSGeo/gdal/blob/v3.9.0RC1/NEWS.md Pick up an archive among the following ones (by ascending size):   https://download.osgeo.org/gdal/3.9.0/gdal-3.9.0rc1.tar.xz  

Re: [gdal-dev] Efficient raster bounding box transformation?

==> GDALCreateApproxTransformer(): https://gdal.org/api/gdal_alg.html#_CPPv427GDALCreateApproxTransformer19GDALTransformerFuncPvd Otherwise there's OGRCoordinateTransformation::TransformBounds(), but this works from a rectangle in the source CRS Most simple would be to use

Re: [gdal-dev] GDAL 3.9.0beta2 available for testing

/gdal:alpine-small-3.9.0beta2 Even Le 29/04/2024 à 14:26, Even Rouault via gdal-dev a écrit : Hi, I've prepared a beta2 of GDAL 3.9.0 as there have been a few non-trivial changes since beta1 The major ones are: * pyproject.toml: use numpy>=2.0.0rc1 for python >=3.9 (#9751) * Docker: update

Re: [gdal-dev] Test problem After Merge

Andrew, interestingly adding the debug traces I suggested to you to the GDAL CI MacOS 14 build witch no longer worked turns out to reveal the exact same issue as yours! (funny that I didn't even consider doing that myself ! interesting case where helping others actually is helping oneself

Re: [gdal-dev] Test problem After Merge

Andrew, first, check that you can use the command line utilities like gdalinfo, so you may need to adjust your PATH, DYLD_LIBRARY_PATH and GDAL_DATA. The Bash script scripts/setdevenv.sh might help setting up stuff (not totally sure if it works on Mac though). Also try in a Python

Re: [gdal-dev] another problem HDF5

Hi, oh well, so this i actually a HDF5 file using netCDF conventions, but likely created with the HDF5 API itself. Per se, this isn't the issue, as you've figured it, we can convince the netCDF driver to open it. The lack of CRS comes from the fact that the land_mask_map variable has this

Re: [gdal-dev] Re-post, user-defined

At first sight, I'd say that the ArcPy output is incorrect. The SRS definition of its output doesn't match what you want since it has PARAMETER["Latitude of natural origin",20, ANGLEUNIT["degree",0.0174532925199433], ID["EPSG",8801]], PARAMETER["Longitude of natural origin",6378137,

Re: [gdal-dev] Test problem After Merge

Andrew, Perhaps you're running updated GDAL Python bindings against a libgdal that hasn't been rebuilt recently? OSRIsDerivedProjected() has been added recently both in libgdal and the bindings Even Le 29/04/2024 à 23:27, Andrew Bell via gdal-dev a écrit : Hi, I just merged master into my

Re: [gdal-dev] HDF5 and geolocation arrays

Michael, actually support for those products was already there at 95% since they use the HDF5EOS GRID formalism which we support since 3.7. But that particular type of products has an oddity. They have an empty GROUP=Dimension within the GROUP=GridStructure in the HDF5EOS metadata, which our

  1   2   3   4   5   >