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 RF

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 ?

ge plane Tag 33550: 60.00,60.00,0.00 Tag 33922: 0.00,0.00,0.00,440720.00,3751320.00,0.00 Tag 34735: 1,1,0,7,1024,0,1,1,1025,0,1,1,1026,34737,21,0,2049,34737,6,21,2054,0,1,9102,3072,0,1,26711,3076,0,1,9001 Tag 34737: NAD27 / UTM zone 11N|NAD27| GDAL Metadata: LOSSLESS 5 On Mon, Jan 6, 2025 at 3:42 PM Kurt Schwehr wrote:

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). > >

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,

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 > <https://en.cpprefe

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>

Re: [gdal-dev] Motion: add Javier Jiménez Shaw to GDAL PSC

+1 KurtS On Sat, Sep 16, 2023, 4:32 AM Even Rouault wrote: > Hi, > > I would like to nominate Javier Jiménez Shaw for GDAL PSC membership. > Javier has been involved with GDAL for quite a time now, as a responsive > user & ticket reporter, and has occasionally contributed fixes. Javier > is well

Re: [gdal-dev] Call for discussion/review of RFC95: Use standard C/C++ integer types

+1 Yes please!! Thoughts: - I've battled with the types so many times over the years. The pain caused by a switch will be well worth it - Q1: I'm for going to GDAL 4.0. - Q2: Having a GDAL_USE_OLD_INT_TYPES for a while seems like a good idea to expose the alias to users of the library - Q3: Yes to

Re: [gdal-dev] Motion: Grant Dan Baston Merge Rights

+1 KurtS On Tue, Sep 12, 2023, 12:21 PM Howard Butler wrote: > Dear PSC, > > Dan Baston is an active GDAL maintainer who does not currently have merge > rights. Let's fix that so he can get more work done without waiting on > someone to merge things up :) > > /me starts with +1 > > Howard >

Re: [gdal-dev] GDAL Maintainers Meeting Minutes

That's a bummer about funding, but I have to say that the list of work going on with the GDAL is really exciting! On Mon, Aug 28, 2023 at 11:06 AM Howard Butler wrote: > Howard Butler, Even Rouault, and Dan Baston held the monthly GDAL > Maintainers Meeting on 08/24/2023. Alessandro was unavaila

Re: [gdal-dev] Minimum python version?

t; docker run --rm ghcr.io/osgeo/gdal-deps:ubuntu_18.04-master python3 > --version > > Dan > > On Tue, Jun 13, 2023 at 1:22 PM Kurt Schwehr wrote: > >> Hi all, >> >> What is the minimum python version for the GDAL python bindings? This is >> the only thing I fou

[gdal-dev] Minimum python version?

Hi all, What is the minimum python version for the GDAL python bindings? This is the only thing I found easily: find . -type f | grep -v git | xargs grep 3 | grep python_version cat autotest/requirements.txt pytest>=6.0.0 pytest-sugar<=0.9.6; python_version < '3.7' pytest-sugar; python_version >

Re: [gdal-dev] Python bindings: enabling exceptions by default?

We are heavy users of the swig bindings. We have some Fiona users and are only just now in the process of starting to use rasterio. We have only 3 instances of calling UseExceptions. Turning on UseExceptions immediately blew up a bunch of my tests that were making incorrect assumptions. Nothing maj

Re: [gdal-dev] Removal of Python SWIG python generated files from git

I am also okay with removing the files. I think removing the generated files will help the project's health. At Google, we have used the swig generated files from git for the python interfaces. It was helpful as we don't have a lot of control about which swig version is available. However, it's no

Re: [gdal-dev] Report on GEOS maintenance grant

+1 Awesome accomplishments and a great summary. Thank you! On Mon, Feb 27, 2023 at 7:34 AM Mateusz Loskot wrote: > On Mon, 27 Feb 2023 at 15:34, Daniel Baston wrote: > > > > As February comes to a close, I’m winding down the GEOS maintenance work > that the GDAL PSC funded in 2022 [1]. > > Dan

Re: [gdal-dev] More consistent use of pytest's parameterization in autotests

Agreed about test interdependency being rough. Internally at work, we have a test runner that intentionally does not run tests in order. All the autotest2 stuff I did should all be order independent. Sadly, my old tests are using pythons normal test setup, not pytest. On Mon, Feb 20, 2023, 7:57

Re: [gdal-dev] Motion: adopt RFC 91: GDALDataset::Close() method

+1 KurtS On Wed, Jan 25, 2023, 3:56 AM Even Rouault wrote: > Hi, > > Motion: adopt RFC 91: GDALDataset::Close() method > > https://github.com/OSGeo/gdal/pull/7108 > > Starting with my +1, > > Even > > -- > http://www.spatialys.com > My software is free, but my time generally not. > > ___

Re: [gdal-dev] Call for review on RFC 91: GDALDataset::Close() method

While it might not be exciting, I think this is a solid API improvement. On Fri, Jan 20, 2023 at 11:11 AM Even Rouault wrote: > Hi, > > Just to notify you that "RFC 91: GDALDataset::Close() method" is > available for review in https://github.com/OSGeo/gdal/pull/7108 > > Admittedly, nothing parti

Re: [gdal-dev] Code reformatting applied

Woohoo! Thanks! On Sat, Dec 17, 2022 at 1:20 PM Even Rouault wrote: > Hi, > > The code reformatting has now landed into master and release/3.6 > branches per pull requests https://github.com/OSGeo/gdal/pull/6937 and > https://github.com/OSGeo/gdal/pull/6939. I've applied it now since the > numb

Re: [gdal-dev] std::numeric_limits::min() vs LLONG_MIN

: > Thanks, Kurt for your response. > > I'm getting a very vague error message: > E0040 expected an identifier. > > Regards, > > Paul > > Op za 17 dec. 2022 om 00:40 schreef Kurt Schwehr : > >> What exact error are you getting? >> >> On Fri, Dec 16,

Re: [gdal-dev] std::numeric_limits::min() vs LLONG_MIN

What exact error are you getting? On Fri, Dec 16, 2022 at 3:31 PM Paul Meems wrote: > Hello List, > > We're trying to update MapWinGIS which is using the GDAL libraries from > gisinternals.com > Currently, we use the stable daily of December 9: > *release-1928-gdal-3-5-mapserver-8-0* > > I'm usi

Re: [gdal-dev] [Tiff] rc3 is available (was Re: libtiff v4.5.0 rc2 available)

I've made it to https://gitlab.com/libtiff/libtiff/commit/193c94b30ca5c7720454a786672ec48718ef3698 the >1M tests all work. Just starting on c2a28a12. It's a smoke test of 1K tests. I should know the rest in about 12 hours. On Tue, Dec 13, 2022 at 2:36 PM Even Rouault wrote: > Here's RC3 with

Re: [gdal-dev] [Tiff] libtiff v4.5.0 rc2 available

/-/merge_requests/444. > > Is that enough to get the build working for you before I generate a rc3 > with that extra fix ? > > Even > Le 13/12/2022 à 22:39, Kurt Schwehr a écrit : > > I'm seeing mac osx and ios failures at my most recent sync of > c4516f9dc72bad7f2c4a8f70

Re: [gdal-dev] [Tiff] libtiff v4.5.0 rc2 available

I'm seeing mac osx and ios failures at my most recent sync of c4516f9dc72bad7f2c4a8f704169afa0342e44ca : third_party/tiff/libtiff/tif_dir.c:1988:17: error: format sp

Re: [gdal-dev] [Tiff] libtiff v4.5.0 release candidate available

I'm a couple commits back from head and have no known issues. I pull directly via git head and use bazel for building, so I can't comment about the tar / zip. Specifically, I'm at https://gitlab.com/libtiff/libtiff/-/commit/1bdbd03fbb4e7d662af052450259fcd353a49cc0 and working on updating my patch

Re: [gdal-dev] Motion: adopt RFC69 C/C++ Code Formatting

+1. Having the hooks makes this feasible. Thank you for pickup the work that I let fall on the floor so long ago! On Mon, Nov 28, 2022 at 9:46 AM Javier Jimenez Shaw wrote: > Yes, those are two different issues: attribution and "blame", that is > really bothering when you want to see the histor

Re: [gdal-dev] Motion: adopt RFC88: Use GoogleTest framework for C/C++ unit tests

+1 KurtS On Mon, Nov 21, 2022, 5:43 AM Even Rouault wrote: > Hi, > > Motion: > > Adopt RFC88: Use GoogleTest framework for C/C++ unit > tests(https://github.com/OSGeo/gdal/pull/6720) > > Starting with my +1, > > Even > > -- > http://www.spatialys.com > My software is free, but my time generally

Re: [gdal-dev] Motion: adopt RFC 87: Signed int8 data type for raster

Hermann, Speaking to GDAL being one (not very small) piece of an ecosystem of libraries and tools: This is exactly what unit tests are for. A well done tool or library should have the tests that cover their critical uses of libraries they depend on. It's often referred to as the "Beyonce rule":

Re: [gdal-dev] Call for discussion: RFC88: Use GoogleTest framework for C/C++ unit tests

I am +1 for this switch, but I'm definitely biased by working at Google. My thoughts: tut definitely gets the job done, but I found it a bit awkward too. But I think the updates and the additional features of GoogleTest are probably worth it. I especially like the distinction between ASSERT.* th

Re: [gdal-dev] Motion: adopt RFC 87: Signed int8 data type for raster

+1 KurtS On Mon, Nov 14, 2022, 4:22 AM Even Rouault wrote: > Hi, > > I feel the discussion phase has finished. There were a few questions > about the existing GDT_Byte unsigned 8-bit integer type, if it should be > renamed/aliased/etc, but no obvious conclusion emerged from this, and > I'd sugge

Re: [gdal-dev] Call for discussion on RFC 87: Signed int8 data type for raster

Yes please! The friction from not having GDT_Int8 keeps coming up again and again. It is extra rough on beginners who hit this case. But I would like to hear any voices for not doing this incase there is something I haven't thought of. On Tue, Nov 8, 2022 at 2:43 AM Even Rouault wrote: > Hi,

Re: [gdal-dev] Does it hurt to *always* use BIGTIFF when using gdal_translate

I keep trying to find if anyone has examples for tools that still don't understand bigtiff, but haven't found anything that has a release in the last 5 years that can't handle BIGTIFF. I can't remember where I've asked before, but I'm asking again on twitter... https://twitter.com/kurtschwehr/sta

Re: [gdal-dev] odbc issue

Hi, Is the original data in FileMaker? If so, is there something about FileMaker that you specifically need? Like is a FileMaker archaeology app that you need? And are there more updates to the data coming? I ask because, if the data is static and there isn't anything special in the land of Fi

Re: [gdal-dev] Motion: Approve Even Rouault as a contracted GDAL maintainer for 2022-2023

+1 KurtS On Sat, Aug 27, 2022, 5:43 AM Howard Butler wrote: > Dear PSC, > > It has come to my attention that Even's term as a GDAL Maintainer > officially ended 31 JUL 2022. I propose that we extend him for another year > from 01 AUG 2022 to 31 JUL 2023 under the previous terms and conditions. >

Re: [gdal-dev] JPEG2000 via range request

It costs, but you could try this: https://gdal.org/drivers/raster/jpipkak.html I have kakadu, but I have never tried the jpip functionality so I can't say how well it works. On Fri, Aug 26, 2022, 5:03 AM Martin wrote: > Hi, > > I want to process JP2 data via vsicurl. Which works so far. > Unfo

Re: [gdal-dev] autoconf and nmake build systems ready to be removed

Congrats and many thanks! On Tue, Aug 9, 2022 at 5:52 AM Even Rouault wrote: > Hi, > > I've just merged the pull request removing them > > Even > > Le 21/07/2022 à 22:12, Even Rouault a écrit : > > Hi, > > > > Great news: the final step of the CMake migration (checklist in > > https://github.com

Re: [gdal-dev] gdal with stack smash protection

I have can confirm that most vanilla hardening available with llvm works for the core of gdal at around version 2.4. Can't speak for most drivers or newer versions, but I would guess that the core is fine with hardening for newer versions. Note: binary add-ons are not likely to play well. On Fr

Re: [gdal-dev] GEOS Maintenance Grant

+1 KurtS - GDAL PSC member On Tue, Feb 15, 2022 at 7:38 AM Howard Butler wrote: > GDAL PSC, > > When we wrote the GDAL RFCs on sponsorship, we provided an escape clause > to allow us to direct resources to other projects upon which GDAL depends. > Our sponsorship numbers are still increasing, wh

Re: [gdal-dev] cmake status update - 99% good news!

Just a note on static builds to follow-on to Even's comments: I do static builds of gdal driven by bazel. This has pros and cons: - Plugins are explicitly not allowed in the system I work in for security reasons (I also remove almost all networking) - The resulting bins are big, but VMs are very

Re: [gdal-dev] Motion: grant github commit rights to Nyall Dawson

+1 KurtS On Tue, Jan 25, 2022 at 3:34 PM Even Rouault wrote: > Hi, > > I'd like to motion to grant github commit rights to Nyall. We don't have > much people currently doing reviews of pull requests and pressing the > "Merge" button, and Nyall is definitely in a capacity of fulfilling this > res

Re: [gdal-dev] Motion: adopt RFC 85: Policy regarding substantial code additions

+1 KurtS On Fri, Jan 21, 2022 at 2:18 AM Even Rouault wrote: > Hi, > > As the discussion seems to have calmed down, I move to adopt RFC 85: > Policy regarding substantial code additions: > https://github.com/OSGeo/gdal/pull/5128 > > Starting with my +1 > > Even > > -- > http://www.spatialys.com

Re: [gdal-dev] Fwd: DOI for the GDAL project / Springer Handbook of Geoinformatics

I don't see a reason not to, but the question is what to point to. The GRASS link points to an RC, which doesn't feel right. It appears that we'd be wanting to do a new doi for each release. Is that really what the community wants? Does Zenodo want to be storing a tar for each release for all ti

Re: [gdal-dev] Motion: RFC 84: Migrating build systems to CMake

+1 KurtS On Mon, Oct 11, 2021 at 7:15 AM Howard Butler wrote: > All, > > Discussion on this topic has died down, and it appears there are no major > objections, so I would like to put forward a motion to approve RFC 84. With > a conservative timeline, the final outcome of this effort is GDAL wil

Re: [gdal-dev] RFC 84: Migrating build systems to CMake

I am strongly in favor of CMake for GDAL with this RFC. I was slightly approsed in prior proposals for CMake. Some supporting tidbits: - There is much support in IDEs for CMake - https://gitlab.kitware.com/cmake/community/-/wikis/doc/Editors - As a maintainer of an out-of-tree bazel bas

Re: [gdal-dev] Motion: Approve Nyall Dawson as a contracted GDAL maintainer

+1 KurtS On Tue, Sep 14, 2021 at 7:59 AM Howard Butler wrote: > Dear PSC, > > As a result of our fundraising activity and development of NumFOCUS as a > financial conduit, it is my pleasure to put forward a motion to approve > Nyall Dawson as a contracted GDAL maintainer for the year 2021-2022 >

Re: [gdal-dev] Retiring osgeo/gdal:alpine-ultra-small Docker image

+1 to match Howard's sentiment. Unless someone steps up with a strong use case for why to keep it, I think it should go. I am curious if any of the alpine images are getting lots of use outside of GDAL's CI testing. On Thu, Aug 26, 2021 at 7:20 AM Howard Butler wrote: > > > > On Aug 25, 2021,

Re: [gdal-dev] Motion: Approve Even Rouault as a contracted GDAL maintainer

+1 KurtS On Tue, Aug 17, 2021 at 8:35 AM Howard Butler wrote: > Dear PSC, > > As a result of our fundraising activity and development of NumFOCUS as a > financial conduit, it is my pleasure to put forward a motion to approve > Even Rouault as a contracted GDAL maintainer for the year 2021-2022 >

Re: [gdal-dev] How to deal with security related bug reports?

My take is pretty much the same as Even's. I suggest that we add a SECURITY.md that says we do not currently treat security bugs in gdal privately and that we don't generally do specific releases for security issues. I thought there used to be a statement somewhere in the files that said that th

Re: [gdal-dev] clang-tidy configs for gdal ?

My recommendation with clang-tidy is to start with all warnings disabled. Then pick one that looks to be more likely to have constructive warnings. Work on just those. Then you can progressively add them. And don't try to deal with warnings for anything involving swig. On Thu, Jun 10, 2021 at 12

Re: [gdal-dev] Motion: adopt RFC 83: guidelines for the use of GDAL project sponsorship

+1 KurtS On Tue, Jun 8, 2021 at 9:19 AM Frank Warmerdam wrote: > +1 FrankW > > I do think we need to give ourselves (the PSC) some latitude on how > proposals are solicited and evaluated. > > I am quite pleased with the characterization of the maintenance tasks. > > Best regards, > > > On Tue, J

Re: [gdal-dev] Renaming Sponsorships tiers to align with NumFOCUS ones

+1 KurtS On Tue, Jun 8, 2021 at 1:10 PM Even Rouault wrote: > PSC, > > We've had a request from NumFOCUS to align the titles of the GDAL > sponsorship tiers with the ones of NumFOCUS, to limit the risk of > confusion, which was one topic discussed during last meeting. > > For reference, the ones

Re: [gdal-dev] Renaming of GDAL Advisory Board

+1 KurtS On Fri, Jun 4, 2021 at 9:46 AM Frank Warmerdam wrote: > +1 Frank > > On Fri, Jun 4, 2021 at 12:36 PM Daniel Morissette < > dmorisse...@mapgears.com> wrote: > >> +1 >> >> Daniel >> >> >> On 2021-06-04 12:24, Even Rouault wrote: >> > Hi, >> > >> > We just had a meeting with NumFOCUS staff

Re: [gdal-dev] Motion: adopt RFC 81: support for coordinate epochs in geospatial formats

I've tried pinging David Sandwell at Scripps, geodesy / rtk / surveying folks at UNH CCOM, and Paul Wessel / Dietmar Muller of GMT about a week ago and haven't gotten any useful response. I'm +0 and feeling like Sean that we really could use some feedback from other communities. Having epoch info

  1   2   3   4   >