Re: [gdal-dev] Motion: ReadTheDocs Financial Support

+1 KurtS On Thu, Apr 17, 2025 at 9:39 AM Howard Butler via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Dear PSC, > > GDAL and PROJ depend upon ReadTheDocs for documentation generation and > hosting. RTD does not charge for open source projects to host > documentation. Projects can pay $60/yr to

Re: [gdal-dev] Motion: approve use of GDAL Sponsorship Program funds for 2 documentation contributors

+1 KurtS On Wed, Mar 12, 2025 at 6:16 AM Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hi, > > Seth Girvin (https://github.com/geographika) and Harrissou Sant-anna > (DelazJ) are interested in contributing improvements to the GDAL > documentation, one of the most recurring item w

[gdal-dev] Reading older NOAA GOES sat data in McIDAS format?

Hi all, A little off topic for GDAL as I'm not suggesting GDAL needs a driver for this. Does anyone know of tools other than McIDAS-X / McIDAS-V for reading older NOAA GOES 08-15 data as described in the McIDAS Programmer's Manual

Re: [gdal-dev] Motion: Add Michael Smith to GDAL PSC

+1 KurtS On Mon, Mar 3, 2025 at 8:30 AM Daniel Morissette via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hi PSC members, > > I would like to nominate Michael Smith to become a member of the GDAL > Project Steering Committee. > >https://www.osgeo.org/member/michael-smith/ > > Mike is a long

Re: [gdal-dev] How to wrap a zarr in a zip and read it with vsizip?

that I can follow, Thanks! > > Cheers, Mike > > > > On Tue, Feb 25, 2025 at 7:10 AM Kurt Schwehr via gdal-dev < > gdal-dev@lists.osgeo.org> wrote: > >> Thanks Laurentiu and Scott! >> >> I can't believe 1) I left off -r and 2) I didn't think to loo

Re: [gdal-dev] How to wrap a zarr in a zip and read it with vsizip?

ntiu > > On Mon, Feb 24, 2025, at 21:17, Scott via gdal-dev wrote: > > There's GDAL's sozip (Search Optimized Zip) utility as well. I have no > > idea if it works with .zarr. I'm sure someone will correct me! ;) > > > > cd nczarr_v2.zarr > > sozip

[gdal-dev] How to wrap a zarr in a zip and read it with vsizip?

Hi all, I seem to be having trouble exactly how to correctly make a zip of a zarr and how to correctly specify the vsizip url. e.g from autotest/gdrivers/data/zarr gdalinfo nczarr_v2.zarr # Works tar cf nczarr_v2.zarr.zip nczarr_v2.zarr Then what? I've tried lots of variations and not had any s

Re: [gdal-dev] Motion: adopt RFC 108 (Re: RFC 108 text: driver removals for GDAL 3.11)

+1 KurtS On Wed, Feb 19, 2025, 2:24 AM Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Motion: adopt RFC 108 > > +1 Even > > Le 18/02/2025 à 18:28, Even Rouault via gdal-dev a écrit : > > "Formalizing" recent discussions: > > https://github.com/OSGeo/gdal/pull/11862 > > > -- > http

Re: [gdal-dev] Motion: adopt RFC 100: Add support for the float16 data type

Thanks Even and Erik for the additional work on RFC 100!! Let's get the voting going again. I hereby change my vote: +1 KurtS On Thu, Nov 7, 2024 at 10:24 AM Kurt Schwehr wrote: > I vote -1 currently as there hasn't been enough discussion. I just added > comments to the RFC PR. > > On Thu, Nov

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

+1 for removing. On Tue, Jan 28, 2025 at 8:33 PM Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hearing silence, the only logical conclusion is that there is no interest > ==> https://github.com/OSGeo/gdal/pull/11746 > > Le 27/09/2024 à 20:15, Even Rouault via gdal-dev a écrit : >

Re: [gdal-dev] Killing useless write side of drivers

I think I'm just rephrasing Even and Howard... I am strongly in favor of removing write for any driver on that list where nobody has shown up to actively support the formats' write support. The one exception would be if there is a feature in a format that isn't provided by any other of the common

Re: [gdal-dev] ECW Driver

>From https://gdal.org/en/stable/drivers/raster/ecw.html "Support is optional and requires linking in the libraries available from the ECW/JP2 SDK Download page." You must build from source and have Hexagon's binary SDK. On Thu, Jan 16, 2025 at 8:06 AM Richard Greenwood via gdal-dev < gdal-dev@l

Re: [gdal-dev] Motion: adopt RFC 105: Add and use safe path manipulation functions

+1 KurtS. Thank you!! On Wed, Jan 15, 2025 at 7:13 AM Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hi, > > The candidate implementation is now ready (I'm afraid nobody will find the > energy to review the ~ 4000 different edits throughout the code base... ) > and all CI targets

Re: [gdal-dev] Call for review on RFC 105: Add and use safe path manipulation functions

While not exciting, definitely important. I didn't see anything to comment on in the RFC. Thanks for working on this! -Kurt On Mon, Jan 13, 2025 at 7:57 AM Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hi, > > nothing exciting, just robustness/enhanced security. > > RFC 105 tex

Re: [gdal-dev] Updating value for Compression tag for JPEGXL in TIFF to the one of DNG 1.7 ?

Here is the patch that I applied to my local //third_party/tiff copy of libtiff. My local libtiff and gdal are both at upstream head. I'm using bazel for building, so I don't have any autoconf or cmake patches. In case folks want, here is what I have. Suggestions welcome if I did anything wrong or

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

Packaging is hard. There are all sorts of sharp edges. I don't work in the windows world much at all, so I can't comment on the packaging there, but there are many package mangers that provide GDAL. And many of us who do packaging share ideas and fixes across packaging. I personally do bazel builds

Re: [gdal-dev] Updating value for Compression tag for JPEGXL in TIFF to the one of DNG 1.7 ?

Thanks Even! The overtired me kept overlooking frmts/gtiff/tif_jxl.c. I will give it a go. On Mon, Jan 6, 2025 at 1:12 PM Even Rouault wrote: > > Le 06/01/2025 à 22:03, Kurt Schwehr a écrit : > > Sounds good to me too (not that I really have the background to say so). > > master PR: https://gi

Re: [gdal-dev] Updating value for Compression tag for JPEGXL in TIFF to the one of DNG 1.7 ?

Sounds good to me too (not that I really have the background to say so). 1. Are there any plans to contribute JPEGXL in tiff to https://gitlab.com/libtiff/libtiff? 2. And what would one need to do to patch libtiff to use JPEGXL? Thanks! On Mon, Jan 6, 2025 at 9:54 AM thomas bonfort via gdal-dev

Re: [gdal-dev] Motion: approve use of GSP funds for work on Conda build infrastructure

+1 KurtS On Thu, Jan 2, 2025 at 6:54 AM Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hi, > > Happy New Year to everyone! > > PSC, > > GDAL depends on conda-forge builds for a number of its continuous > integration configurations, as well as offering builds of the master > branch

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

I figured there would be a bunch of blockers, but had to ask. On Fri, Dec 20, 2024 at 2:56 PM Even Rouault wrote: > > Le 20/12/2024 à 22:13, Kurt Schwehr via PROJ a écrit : > > In the long shot department... > > If you had to pick just one compressor, why not zstd? Yeah, I know that > most thing

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

In the long shot department... If you had to pick just one compressor, why not zstd? Yeah, I know that most things out there are deflate, but if we could break from that, would it make for a smaller faster world? On Thu, Dec 19, 2024 at 9:56 AM Javier Jimenez Shaw via PROJ < p...@lists.osgeo.org>

Re: [gdal-dev] Scientific citations of GDAL in 2024

Thank you Peter! I've tried to boost the idea here: https://bsky.app/profile/kurtschwehr.bsky.social/post/3ldqunk47oc2x -Kurt On Fri, Dec 20, 2024 at 5:36 AM Peter Löwe via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hello GDAL community, > > this is an update about references to the GDAL pr

Re: [gdal-dev] Call for discussion on RFC 100: Adding Float16 support to GDAL

But more importantly... I should have started with saying thank you Erik for working on this RFC for GDAL! On Thu, Nov 7, 2024 at 10:30 AM Kurt Schwehr wrote: > My first pass questions are: > > 1) For folks compiling with C++23*, can they use std::float16_t >

Re: [gdal-dev] Call for discussion on RFC 100: Adding Float16 support to GDAL

My first pass questions are: 1) For folks compiling with C++23*, can they use std::float16_t ? Sadly, that's not me yet as my environment is C++20. 2) For when C++23 is the minimum language version for GDAL, what is the plan? (*) https://en

Re: [gdal-dev] Motion: adopt RFC 100: Add support for the float16 data type

I vote -1 currently as there hasn't been enough discussion. I just added comments to the RFC PR. On Thu, Nov 7, 2024 at 6:40 AM Erik Schnetter via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > I move to adopt RFC 100 (adding support for the float16 data type). > > The pull request for RFC 100 is

Re: [gdal-dev] Motion: Renew Alessandro Pasotti GDAL Maintainer Contract

+1 KurtS On Wed, Oct 23, 2024, 5:32 AM Howard Butler via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > PSC, > > I am motioning to renew Alessandro's maintainer contract through the GDAL > Sponsorship Program that is hosted by NumFOCUS for another year. > > /me starts with a +1 > > Howard > __

Re: [gdal-dev] Motion: adopt RFC 102: Embedding resource files into libgdal

+1 KurtS On Thu, Oct 17, 2024 at 4:03 AM Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hi, > > Motion: adopt RFC 102: Embedding resource files into libgdal > > https://github.com/OSGeo/gdal/pull/10913 > > (PROJ parts have been moved to a PROJ specific RFC: > https://github.com/OS

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

For my weird google production setup: I haven't heard of any bugs along those lines. I only build cs2cs and gie for running tests and users have no access to any of the proj binaries in production. I don't think folks do much with sqlite (most db usage are things like Spanner or FireBase) and most

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

So excited for this feature. We have custom code that does stuff like this. e.g. +// BEGIN GOOGLE MODIFICATION +int flags = SQLITE_OPEN_READONLY | SQLITE_OPEN_NOMUTEX; if (path.empty()) { -path.resize(2048); -const bool found = -pj_find_file(pjCtxt(), "pro

Re: [gdal-dev] Motion: Renew Even Rouault GDAL Maintainer Contract

+1 KurtS On Wed, Sep 11, 2024 at 7:24 PM Howard Butler via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > PSC, > > I am motioning to renew Even's maintainer contract through the GDAL > Sponsorship Program that is hosted by NumFOCUS for another year. > > /me starts with a +1 > > Howard > __

Re: [gdal-dev] Motion: approve RFC 101 "Raster dataset read-only thread-safety"

+1 KurtS On Wed, Sep 11, 2024 at 12:27 PM Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hi, > > I move to approve RFC 101 "Raster dataset read-only thread-safety": > https://github.com/OSGeo/gdal/pull/10676 > > Starting with my +1, > > The candidate implementation is available in

Re: [gdal-dev] Call for review on RFC 101: Raster dataset read-only thread-safety

My take would be to not offer the force option unless there is someone who states they really need it. On Fri, Sep 6, 2024 at 6:52 AM Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hi, > > No other reactions? In particular w.r.t. the open question whether it is > worth to offer a

Re: [gdal-dev] Driver order for HDF5 versus netCDF

Thanks!!! I'm missing HAVE_HDF5. And it looks like I should set HAVE_HDF4 too as I have that in my build too. The joys of having to maintain a separate build system... On Thu, Sep 5, 2024 at 1:22 PM Even Rouault wrote: > Kurt, > > Looking at the expected behavior at GDAL's head, I see this. I t

[gdal-dev] Driver order for HDF5 versus netCDF

Hi Even, I'm trying to enable NETCDF_HAS_NC4 in my distribution's copy of GDAL. This is causing files metadata.h5 to show up as opened with netcdf rather than hdf5. I'm way back at 103fdca10 on 2022-Nov-16. e.g. these blaze-bin/third_party/gdal/gdalinfo third_party/gdal/autotest2/python/gdriver

Re: [gdal-dev] Call for review on RFC 101: Raster dataset read-only thread-safety

Thank you Even for this! I don't have any comments after a quick read beyond appreciating that you discussed an alternative approach. -Kurt On Thu, Aug 29, 2024 at 5:27 AM Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hi, > > I've worked on a new RFC 101: Raster dataset read-onl

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

+1 KurtS On Thu, Jul 25, 2024 at 8:03 AM Howard Butler via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > 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 i

Re: [gdal-dev] GDAL & CAD Files

https://gdal.org/drivers/vector/dwg.html says: > DWG files are considered to have no georeferencing information through OGR >From https://gdal.org/programs/ogr2ogr.html, you will need to specify the spatial reference system / projection with "-s_srs" -Kurt On Tue, Jun 25, 2024 at 12:55 PM Ashly

Re: [gdal-dev] Hungarian Notation

My personal take: I slightly Hungarian notation and it seems to me like needing that extra notation points to other coding style issues. However, I think moving away from it would be a chaotic mess for GDAL. It would be a massive change to switch it all. Consistency is critical. On Wed, Apr 17, 2

Re: [gdal-dev] Motion: adopt RFC 99: Geometry coordinate precision

+0 KurtS. It seems like a good idea, but I worry about unintended consequences, but can't come up with any. On Thu, Mar 7, 2024 at 11:07 AM Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hi, > > The flow of comments calming down, I motion to adopt RFC 99: Geometry > coordinate pre

Re: [gdal-dev] Official dataset for benchmarking GDAL I/O?

As Even said, this is a really tough topic. I have tried some micro benchmarking for small bits and for short term dev this is sort of ok. The biggest problem is getting a stable test env for benchmarking. Even a single user machine doing only benchmarking is all over the place. And if you are benc

Re: [gdal-dev] opening images via a URI

See vsicurl and the other network drivers for things more specific like /vsis3/, /vsigs/, /vsiaz/, /vsioss/ or /vsiswift/ https://gdal.org/user/virtual_file_systems.html#vsicurl-http-https-ftp-files-random-access On Sat, Jan 13, 2024 at 2:59 PM Barry DeZonia via gdal-dev < gdal-dev@lists.osgeo.or

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

+1 for un-vendoring. Long term, I think that will be a big win. Looks like others have covered all of the issues that I can think of. On Fri, Dec 15, 2023 at 4:45 PM Greg Troxel via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Even Rouault via gdal-dev writes: > > > I'm considering removing f

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

I lean towards just requiring numpy. It's super common and once a system brings in gdal python, it can't be a super constrained env where keeping things really small is critical. Just requiring numpy simplifies a number of aspects. I think the setup.py topic as a whole is somewhat separate.l. So

Re: [gdal-dev] Motion: adopt RFC 98: Build requirements for GDAL 3.9

+1 KurtS On Fri, Dec 1, 2023, 7:34 AM Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hi, > > Motion: adopt RFC 98: Build requirements for GDAL 3.9 > > https://github.com/OSGeo/gdal/pull/8802 > > Starting with my +1, > > Even > > -- > http://www.spatialys.com > My software is free,

Re: [gdal-dev] "RFC 98: Build requirements for GDAL 3.9" available for review

Woohoo! I look forward to the cleanups that this will enable. Thank you Even for working on this! I am hoping that the hdf4 will get some similar improvements in 2024. I haven't looked to see if any of the hdf4 cleanup in 2023 could allow GDAL cleanup. My guess is that there isn't anything yet as

Re: [gdal-dev] Motion: adopt RFC 96: Deferred C++ plugin loading

+1 KurtS One minor comment... I use pfnOpen in a few of my local fuzzers, but I build statically without plugins, so I think my use won't be impacted. But even if I am impacted, that's my problem and not a responsibility of the GDAL project as I'm using internal GDAL details. > Another potential

Re: [gdal-dev] Show isBigTIFF in image metadata

Jukka, What's the exact use case for needing to know if a tiff is traditional or BigTIFF? Is there a key tool that doesn't understand BigTIFF? The only one I know of is Autodesk Civil3D. Thanks, -Kurt On Thu, Nov 2, 2023 at 2:49 PM Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote: >

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

Thanks Even for the RFC! After a quick read, this seems reasonable. I was mostly concerned about the impact on folks who statically build everything (my biggest use case), but that is completely addressed in the doc. On Thu, Nov 2, 2023 at 5:00 AM Even Rouault via gdal-dev < gdal-dev@lists.osgeo.

Re: [gdal-dev] Motion: OSGeo Community Sprint Financial Support

+1 Kurt S On Tue, Oct 31, 2023 at 10:02 AM Howard Butler via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Dear PSC, > > Sorry for the short notice, but I would like to motion that the GDAL > Sponsorship Program financially support GDAL PSC members who wish to attend > the OSGeo Community Sprint

Re: [gdal-dev] Notice: issue about multi-threaded GTiff compression+decompression

> In short: multithreading is hard So true! With the introduction of tsan things are a little less bad, but tsan is still a tool with plenty of false positives and false negatives. And that assumes that a particular issue is covered by the tests being run under tsan. __

Re: [gdal-dev] Notice: issue about multi-threaded GTiff compression+decompression

Thanks for the heads up! Can you share that SHAs of the fix and cause? On Mon, Oct 16, 2023, 7:44 AM Even Rouault via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hi, > > For GDAL 3.6.0 to 3.7.2, use of multi-threaded GTiff > compression+decompression, in particular within the same file, as for

Re: [gdal-dev] Motion: Annual Contracts for Maintainers

+1 KurtS On Wed, Oct 11, 2023 at 9:17 AM Howard Butler via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > PSC, > > I'm a little late but I would like to make the following motions in > regards to GDAL maintainers: > > * Authorize Alessandro Pasotti for up to 30 hrs/month with a rate increase > of

Re: [gdal-dev] GDAL version in pip requirements file

I am not sure if there is anything in this, but take a look at https://packaging.python.org/en/latest/guides/ Also, I might suggest avoiding command line solutions. You can get the version from the python module On Mon, Sep 25, 2023, 11:55 PM Luca Delucchi via gdal-dev < gdal-dev@lists.osgeo.org>