Re: [gdal-dev] GDAL mailing list email delays

Markus Neteler via gdal-dev writes: > Am 29.05.25 um 7:55 PM schrieb Greg Troxel via gdal-dev: >> The way to debug this is to look at the logs at the computer that >> receives your mail from lists.osgeo.org, and to see if it is >> implementing greylisting. > > Yes,

Re: [gdal-dev] GDAL mailing list email delays

Barry DeZonia via gdal-dev writes: > For the record it is not just this user experiencing issues. I > received the java bindings Original email 11 minutes after the Reply > to that email.came through. However, I am accessing mail via gmail.com > too. Please open a support ticket to have the logs

Re: [gdal-dev] GDAL mailing list email delays

Daniel Evans via gdal-dev writes: > Tom's initial email was delayed by 48 minutes, arriving at 1715 UTC: > - Originally sent by the mailing list at 1627 UTC > - After a few internal hops, received by lists.osgeo.org at 1636 UTC (with > a header stating X-Greylist: delayed by 473 seconds) > - Rece

[gdal-dev] float16 woes on solaris

The pkgsrc package isn't building on SmartOS (which is illumos, which is OpenSolaris, more or less). Full build at the last link: https://reports.pkgci.org/SmartOS/upstream/trunk/20250518.2249/meta/report.html https://reports.pkgci.org/SmartOS/upstream/trunk/20250518.2249/gdal-lib-3.11.0/co

Re: [gdal-dev] float16 woes on solaris

The build I posted was gcc 13. This might be a gcc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117321 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.11.0 release candidate available

Sebastiaan Couwenberg via gdal-dev writes: > This seems to have caused breakage on some architectures where -latomic is > needed explicitly, as it now fails to build on armel & powerpc: > > > https://buildd.debian.org/status/fetch.php?pkg=gdal&arch=armel&ver=3.11.0%7Erc1%2Bdfsg-1%7Eexp1&stamp=

Re: [gdal-dev] How can I avoid absolute path to shared libraries in libgdal.so

"Fox, Shawn D (US) via gdal-dev" writes: > I'm sure a lot of people have opinions > about the concept of rpath vs using LD_LIBRARY_PATH. I'm not > interested in discussing that. Our team does have a complicated > application build and distribution process, and it isn't useful to try > and expla

Re: [gdal-dev] How can I avoid absolute path to shared libraries in libgdal.so

"Fox, Shawn D (US) via gdal-dev" writes: > ldd libgdal.so > linux-vdso.so.1 (0x7ffe0e3f7000) > libdl.so.2 => /lib64/libdl.so.2 (0x7feaca6a6000) > libcurl.so.4 => /lib64/libcurl.so.4 (0x7feaca417000) > libproj.so.22 => not found > libexpat.so.1 =

Re: [gdal-dev] GDAL 3.11.0 "Eganville" beta1 available for testing

Even Rouault writes: > those errors are related to the new float16 (RFC100) support. Support > for that type is a bit weak with some compilers / C/C++ libraries. Can > you give a try at https://github.com/OSGeo/gdal/pull/12165 ? Thanks for the quick fix! With that patch, I get a successful buil

Re: [gdal-dev] GDAL 3.11.0 "Eganville" beta1 available for testing

Even Rouault writes: > No, std::abs() is fine there. Fixed per > https://github.com/OSGeo/gdal/commit/2d169a75c24aece05be9bba588d50bc055e9b9ac great, thanks. > Those ones are related to the use of the old PCRE library. Should be > fixed per > https://github.com/OSGeo/gdal/commit/0e38a13e0c7784d

Re: [gdal-dev] GDAL 3.11.0 "Eganville" beta1 available for testing

Even Rouault via gdal-dev writes: > https://github.com/OSGeo/gdal/blob/v3.11.0beta1/NEWS.md I'm seeing errors on two or three files about what I think is referring to std::isinf and std::isnan with just isinf and isnan. Adding std:: before isinf/isnan seems to make it build. And, I see existin

Re: [gdal-dev] GDAL release compatibility with external libraries

"Fox, Shawn D (US) via gdal-dev" writes: > I recently read the details of RFC 98: Build requirements for GDAL 3.9 > - GDAL > documentation, > and I was wondering if there is any similar info for previous versions >

Re: [gdal-dev] Motion: adopt GDAL 3.10.2RC1 as final 3.10.2 release

I think 24h is way too fast for people to be able to test, so I would be -1 if I had a 1 to throw around, which I don't. (3.10.2RC1 did build for me on NetBSD 10/amd64 and with it qgis opens my layers just fine.) ___ gdal-dev mailing list gdal-dev@lists.

Re: [gdal-dev] GDAL 3.10.2 release candidate available

Even Rouault via gdal-dev writes: > The main trigger for it is the recent Poppler 25.02.00 release that > breaks their C++ unstable API and require code changes on our side. So > rather than letting each package maintainer cherry-picks the > appropriate patch commit, let's issue a clean release.

Re: [gdal-dev] CSharp bindings queued for removal (was Re: GDAL CSharp bindings maintainers/contributors listening... ?)

Even Rouault via gdal-dev writes: > - less provocative: add telemetry. obviously not opt-in because nobody > would take the time to turn it on, but just opt-out I know you said don't blow a gasket on your suggestions, but this is really not an ok thing to do. In all seriousness, I think the

Re: [gdal-dev] UTM local correction for height and distance-to-reference-meridian ?

Peter Bennewitz via gdal-dev writes: > To get exact distances between local points, UTM requires a correction > factor, depending on local height and distance to the UTM reference > meridian. Mainly due to UTM's 6deg steps, - as opposed to the smaller > 3deg of GK, where this correction could hav

Re: [gdal-dev] Improving GDAL production in our release

David Klaus writes: > Thank you for your fast response. > > Q: You didn't explain whether you are doing import/merge and carrying diffs > to the sources, and if so, you didn't give a link where others can look at > them. > > A: I apologize if I misunderstand your questions. I think you are asking

Re: [gdal-dev] Improving GDAL production in our release

David Klaus via gdal-dev writes: > I am reaching out for advice on streamlining the process my company uses to > produce new versions of GDAL for our releases. Currently, we maintain a > batch file that handles some preliminary setup tasks and then initiates a > custom GDAL build using CMake. Unf

Re: [gdal-dev] LIBERTIFF / Thread-safe TIFF reader

Even Rouault via gdal-dev writes: > Now for the PROJ community only: my evil idea when coding it was that > I could ""port"" a very subset of it to remove the libtiff depedency > from PROJ. As we only uses Deflate compression, at least for grids we > host on proj-data / the CDN, we could just swi

Re: [gdal-dev] GPU support for GDAL

Pradeep Mahato via gdal-dev writes: > In second approach i am facing issue in stacking and making it as one > ".ovr" file. So Pls help me in this regard. If you are going to ask for help, you should have your goals and software design in writing, and publish them. Before doing that, you should

Re: [gdal-dev] Github, AI and the proposed RFC 8 amendment

Andrew C Aitchison via gdal-dev writes: > Agreed. > > However, as I understand it, by using github we have allowed > copilot to include our code without it being covered by the usual > licence. Perhaps "acquiesced", but the project does not have to right to grant hat license for code whose copyr

Re: [gdal-dev] Proposed RFC 8 amendment regarding (prohibited use of) generative AI tools

ElPaso via gdal-dev writes: > I have read the discussion on lwn and I must say that I am more in > line with the debian position. My view is that code that comes out of generative AI should be viewed as an improper derived work, and lacking adequate provenance/permission to be added to an open s

Re: [gdal-dev] [PROJ] RFC 102: Embedding resource files into libgdal (and PROJ)

Even Rouault via PROJ writes: > Sending to both gdal-dev and proj, as this is intended to be a joint RFC. > > Summary: This RFC uses C23 ``#embed`` pre-processor directive, when > available, to be able to embed GDAL resource files directly into > libgdal. It is also intended to be used for PROJ,

Re: [gdal-dev] Assistance Required for Downloading GDAL Libraries and Dependencies for aarch64 and Static Compilation on LS1046 ARM64 Processor

Cross compilation requires a destdir for the target architecture, already populated with ilbs and includes. It looks to me like your cross environment is not set up correctly - and that's in my view out of scope for gdal-dev. I would suggest that you first be able to cross compile a number of pro

Re: [gdal-dev] Is there a FACE Conformant version of GDAL and its DTED drivers?

Ethan Payne via gdal-dev writes: > I'm currently assisting with a project that involves using DTED files > to analyze terrain and elevation. As this project adheres to the FACE > Technical Standard and must meet FACE Conformance requirements, I > wanted to inquire whether there is a version of GD

Re: [gdal-dev] Upgrading to GDAL 3.4.2 from 1.10.0 shows different outputs from gdaltransform and corresponding C++ API

Even Rouault via gdal-dev writes: > 3) You would get the most precise result (with lots of quotes, > because this is highly subjective, and assumes that NAD83(HARN) is > equivalent to WGS 84, according to the comment in the EPSG database) > with the "NAD27 to WGS 84 (41)" EPSG transformat

Re: [gdal-dev] Upgrading to GDAL 3.4.2 from 1.10.0 shows different outputs from gdaltransform and corresponding C++ API

"Fox, Shawn D (US) via gdal-dev" writes: > I have noticed that from GDAL 1.10 - GDAL 3.1.0 that gdaltransform is > producing different results for NAD27 GCS to WGS84 GCS > transformations. The differences in longitude in the output is more > significant. Having tested the differences in feet be

Re: [gdal-dev] GDAL 3.9.2 release candidate available

Even Rouault via gdal-dev writes: >   https://download.osgeo.org/gdal/3.9.2/gdal-3.9.2rc1.tar.xz On NetBDS 10 amd64, I locally updated pkgsrc, and gdal-lib, py-gdal (bindings split package), and qgis all built without issues, and the resulting qgis, when run on a project with a lot of layers of

Re: [gdal-dev] shapelib 1.6.1RC2 available (was Re: shapelib 1.6.1RC1 available)

Even Rouault via gdal-dev writes: > Here's a shapelib v1.6.1 RC2: > - https://download.osgeo.org/shapelib/shapelib-1.6.1rc2.tar.gz > - https://download.osgeo.org/shapelib/shapelib-1.6.1rc2.zip > > Changes since v1.6.1RC1: > - shapefil.h: bump version number to 1.6.1 > - CMake: (>= 3.21) Fix ctest

Re: [gdal-dev] shapelib 1.6.1RC2 available (was Re: shapelib 1.6.1RC1 available)

(I'm building with autoconf.) 1) It builds fine on NetBSD 10 amd64, using an old pkgsrc workaround/?? to explicitly build only the libs (that may well be no longer relevant): # \todo Explain why we don't install what shapelib installs. # \todo Perhaps file a bug upstream that the bin programs

Re: [gdal-dev] dealing with complex (a+ib) images

Javier Jimenez Shaw via gdal-dev writes: > I have to create a complex number (real and imaginary part) image out of > two "normal" images or bands. > How can I do it? I don't know, but it would be great if you explained what that means. I did a quick web search and didn't find anything. There i

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

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 documentation for pull > requests. A current build of the docu

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

David Klaus writes: > Thank you for the input. You don't happen to know where I can find > documentation on these NADCON5 related changes? I would suggest reading the 9.2.0 release notes. There is a link to a merged PR which has further discussion. The tl;dr; is that proj matches NGS tools. Wh

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

David Klaus writes: > As far as upgrading Proj4; because we build Proj4 statically in our custom > build, it's not a trivial task to upgrade versions. Also, I think there > might be compatibility reasons why we've stuck with 6.3.1 up until now. > > But if NAD83 realization transformation function

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

You didn't, as far as I can tell, post the code that is not doing what you want. Or perhaps turn that code into a small test case program. People reading that would be able to be more helpful, and the code example could help others. Proj 6.3 is quite old. I recommend you update to the latest re

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

Scott via gdal-dev writes: > On debian 12: > > /usr/include/c++/12/cstdlib, line 75. Context: > > // Need to ensure this finds the C library's not a libstdc++ > // wrapper that might already be installed later in the include search path. > #define _GLIBCXX_INCLUDE_NEXT_C_HEADERS > #include_next

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

I egreped over the gdal 3.9.1rc2 sources and do not find this include_next stdlib at all. $ egrep -R include_next.*stdlib . Please explain where you think it is in the sources. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org

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

Scott via gdal-dev writes: > #include_next is part of the c++ version 12. You can find it's usage > here on debian 12: > > /usr/include/c++/12/cstdlib, line 75 I think that's gcc 12, not C++12 which is not a thing :-) It being used in an internal header supplied by the compiler is one thing.

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

Barry DeZonia via gdal-dev writes: > Scott, is it that you are using #include_next instead of #include? > #include_next makes assumptions about the environment that #include does > not. And, stdlib.h is very much required by POSIX. On Debian 12 amd64, /usr/include/stdlib.h is there, just as exp

Re: [gdal-dev] GDAL 3.9.1 release candidate available

Even Rouault via gdal-dev writes: >   https://download.osgeo.org/gdal/3.9.1/gdal-3.9.1rc1.tar.xz I locally updated pkgsrc, and it builds fine on NetBSD 10 amd64. qgis 3.36 using it (without recompiling qgis) starts up and loads geopackage vector layers and postgis vector layers. So seems good

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

Even Rouault via gdal-dev writes: > Motion: > > Adopt GDAL 3.9.1RC1 as 3.9.1 release I haven't had a chance to test in the 24h59m between the rc and proposing a release. Not sure when I will, but this interval seems super short. Of the beyond-core-team people that usually test, has anybody el

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

Even Rouault writes: > [cmake] Thanks for cluing me in; that all makes sense. > No idea if you need gcc 7 or 8. I don't think we use super advanced > C++17 features, so gcc 7 might be fine, but only experimentation would > confirm that. I believe the minimum we test on our CI is gcc 9.4 that >

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

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 - fail the build if that does not work with a message that makes it clear that the compiler doesn't work --std=c++17 - if it works, add --std=c++17 to

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

Even Rouault writes: >> 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

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

1) README.md points to build hints (my fault if that's wrong..): https://gdal.org/development/building_from_source.html but really there is crucial information (like that a C++ compiler is required!) at https://gdal.org/development/dev_environment.html which is misplaced, because people are

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

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 available in 3.5) cmake .. make GDAL  # build the

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

Even Rouault writes: > 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 > dep

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

I had not gotten to converting the pkgsrc package to cmake, because it seemed like it would take a long time. So gdal is at 3.5.3, the last one that works with autoconf. Yes, I know that 3.5 was about two years ago. It turns out that it is taking hours to do the conversion, and the good news is

Re: [gdal-dev] false easting and northing units

Kirk Waters - NOAA Federal via gdal-dev writes: > Thanks for the explanation and tips. I'm not clear on how setting to 26988 > (Michigan North meters) would help. If I do a gdal_translate with that, it > shows as being in New Zealand, just as Arc had done. It would certainly > make lots more sens

Re: [gdal-dev] Un-vendoring a number of third-party libraries?

Even Rouault via gdal-dev writes: > I'm considering removing from the source tree a number of third-party > libraries that we have vendored over the years: zlib, libpng, libjpeg, > giflib, liblerc I'm basically strongly in favor of un-vendoring. I view vendoring as a bug, even if it is a workar

Re: [gdal-dev] Requiring numpy for the Python bindings

Laurențiu Nicola via gdal-dev writes: > On Wed, Dec 6, 2023, at 16:23, Greg Troxel via gdal-dev wrote: >> Keeping rust going has been an ongoing source of work and problems. >> This is partly because of not having a reasonable bootstrap story from >> C/C++, and mostly

Re: [gdal-dev] Requiring numpy for the Python bindings

Laurențiu Nicola via gdal-dev writes: > 1. do the platforms you care about package Firefox, librsvg, or any > other popular software that's using Rust? pkgsrc supports multiple operating system, multiple versions of those systems, and multiple cpu architectures. There are probably over a hundre

Re: [gdal-dev] Requiring numpy for the Python bindings

Thomas Knudsen writes: > 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 peo

Re: [gdal-dev] Requiring numpy for the Python bindings

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

Re: [gdal-dev] How do GCP's in a VRT file work?

Joe Lovick via gdal-dev writes: >        What is the recommended processing paradigm for slightly > off-nadir imagery where their is a need for a full [3x3] matrix > mapping to take it to a consistent projection? ie the images have at a > minimum perspective effects. > >     the reason i ask, is

Re: [gdal-dev] How do GCP's in a VRT file work?

Joe Lovick via gdal-dev writes: > Could someone explain how GCP's placed into a VRT file work, i was > expecting a linear/bi-linear, or polynomial fit between the points for > the simplest EPSG:4326 projection.however that is not what i see, > adjusting a single point, effects the projection of a

Re: [gdal-dev] including higher-level library in GPX creator string

Even Rouault via gdal-dev writes: > Cf https://github.com/OSGeo/gdal/pull/8558: "GPX: add a CREATOR > dataset creation option" Thanks; long pause on my part to let this settle in my head. > It will be of course up to the application / application user to set it. I guess the really interesting

[gdal-dev] including higher-level library in GPX creator string

I am a member of the GPX standards list, and we are discussing a new version and also dealing with broken data. I wrote a gpx (from geojson), with just ogr2ogr, and the creator looks like this: creator="GDAL 3.5.3" that's arguably totally fine with ogr2ogr. But it seems that if some random bi