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

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

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,

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

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

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 <

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

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

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

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

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 <

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

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 <

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

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

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

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

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

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

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

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 >

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, 2022

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

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 > c4516f9dc72bad7f2c4a8f70416

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

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

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

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

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

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

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

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

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

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

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

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,

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

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 >

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

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

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

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

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

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,

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

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

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

Re: [gdal-dev] Registered Content-Type for VRT?

I was talking a bit with George Percivall back in November about MIME types for Earth Engine w.r.t. STAC which is sorta similar. He pointed me to Panagiotis (Peter) A. Vretanos. That chat wasn't public, but I can forward to anyone interested. And a similar discussion: Link rel type for links

Re: [gdal-dev] Motion: adopt RFC80

+1 KurtS On Fri, Apr 16, 2021 at 7:50 AM Even Rouault wrote: > Hi, > > I hereby motion to adopt RFC 80: > > https://github.com/OSGeo/gdal/pull/3682 > > This also implies adopting the "GDAL Sponsorship Prospectus" at > > >

Re: [gdal-dev] Long Term Prognosis for JPEG 2000

One downside in the jpeg2000 ecosystem that I have to call out: Kakadu doesn't come with any tests unit tests. I tried to donate some simple starter tests, but no luck getting traction. :( On Tue, Mar 30, 2021, 9:11 AM Kurt Schwehr wrote: > Jp2k is likely to continue with heavy

Re: [gdal-dev] Long Term Prognosis for JPEG 2000

Jp2k is likely to continue with heavy use for a long time to come. There are lots of hardware encoders in our solar system and the existing base of data in that format is massive. And with the improvements in Openjpeg, it's support seems viable. It's not the first choice for most, but that's

Re: [gdal-dev] Motion: RFC 78: gdal-utils package

+0 KurtS I have some vague undefined unease about this. Even's comments help diminish that some. I don't see strong enough arguments for me to vote for it. On Wed, Mar 24, 2021 at 12:03 PM Even Rouault wrote: > Hi Idan, > > > Motion: > > Adopt RFC 78: gdal-utils package >

Re: [gdal-dev] Motion (V2): remove and deprecate a few drivers

+1 KurtS On Thu, Mar 4, 2021 at 8:33 AM Even Rouault wrote: > Hi, > > Updating my yesterday motion with the feedback received (only second > bullet updated with a more restricted set of drivers) > > Motion: > > - remove the vector drivers BNA, AeronavFAA, HTF, OpenAir, SEGUKOOA, > SEGY, SUA,

Re: [gdal-dev] Motion: remove and deprecate a few drivers

Thanks Even! Hurray for cleanup! Some thoughts looking at the list: > SEGY Makes me sad, but I've never seen anyone use it. I've done seismic work but never needed it. +1 to nuke it. > E00GRID I keep running into E00 data from the USGS, but it's mostly been vector data. I'm +0 on removing

Re: [gdal-dev] New JPEG 2000 Driver

I can't touch grok... GNU Affero General Public License On Sat, Feb 27, 2021, 9:50 AM Aaron Boxer wrote: > Hello Everyone, > > For those who aren’t aware, there is a pending PR for a new open source > JPEG 2000 driver, based on the Grok JPEG 2000 library > >

Re: [gdal-dev] Motion: adopt RFC79: Listing of Service Providers on GDAL website

+1 KurtS On Thu, Feb 25, 2021, 3:46 AM Mateusz Loskot wrote: > +1 > > Mateusz > > On Thu, 25 Feb 2021 at 11:30, Even Rouault > wrote: > > > > Hi, > > > > I motion to adopt RFC79: Listing of Service Providers on GDAL website: > > https://github.com/OSGeo/gdal/pull/3473 > > > > Starting with my

Re: [gdal-dev] Driver maintenance - long-term solution ?

I mostly wanted to say that I'm here listening to the discussion and thinking about all these issues. On the technical side, I tried to publicly think about long term maintainability / reliability of GDAL over the years. It's always a moving target, but here are a few of my old thoughts:

[gdal-dev] netCDF chunk fetch failed

Hi all, In a build of gdal 3.2.0, I'm seeing this error: "netCDF chunk fetch failed" for 2 out of 5 subdatasets. Is there an easy way to handle this so the bad data is returned as the nodata value? And also, any idea what is actually wrong with the netcdf files? I am in contact with the NOAA

Re: [gdal-dev] Considering drivers removal ?

I am definitely for removing unused things that talk to servers or use binary drivers. I can see wanting to keep drivers that don't interact with servers for posterity, but I think that cost is starting to get high. A system like you describe with a good lead time sounds good. In the Google

Re: [gdal-dev] Motion: adopt RFC 77 Drop Python 2 support in favor of Python 3.6

+1 KurtS On Fri, Nov 20, 2020, 8:25 AM Howard Butler wrote: > > > > On Nov 20, 2020, at 10:24 AM, Even Rouault > wrote: > > > > Hi, > > > > given the positive feedback of the discussion phase, and since our CI is > now > > ready for it, I motion to adopt > > > > RFC 77: Drop Python 2 support

Re: [gdal-dev] "import gdal" broken in 3.2.0: what to do ?

+1 for dropping the old way On Thu, Nov 5, 2020, 7:59 AM Kai Mühlbauer wrote: > Hi, > > I'm using GDAL since 2012 and one of the first things I've read is this: > > https://trac.osgeo.org/gdal/wiki/GdalOgrInPython > > The first mention of the deprecation of this import was added 13 years > ago.

Re: [gdal-dev] How to build py-gdal using the C++ compiler

Here is the (very out of date) fink setup for gdal for comparison: https://github.com/fink/fink-distributions/blob/master/10.9-libcxx/stable/main/finkinfo/libs/pythonmods/gdal-py.info#L43

Re: [gdal-dev] Removal of API_PROXY mechanism: objections?

+1 for removing On Thu, May 7, 2020 at 11:53 AM Even Rouault wrote: > Hi, > > > > https://github.com/OSGeo/gdal/pull/2489 kills the API_PROXY mechanism, > which removes 7820 lines of code. Anyone objects ? > > > > Note: if you have no idea what this is about, then it means you never used > that

Re: [gdal-dev] Gdal compatibility to hdf4

> Ankit > IISER Mohali > > On Sun, 29 Mar 2020 at 10:14 PM, Kurt Schwehr wrote: > >> You need to give details about your platform and gdal install. I have >> been using gdal with hdf4 for modis for many years, so it is certainly >> possible >> >> O

Re: [gdal-dev] Gdal compatibility to hdf4

You need to give details about your platform and gdal install. I have been using gdal with hdf4 for modis for many years, so it is certainly possible On Fri, Mar 27, 2020, 2:11 AM ankit yadav wrote: > Hello Everyone, > > I am a new user to data visualization tools and currently experiencing >

Re: [gdal-dev] Motion: request 2000 USD from OSGeo for GDAL

+1 KurtS On Fri, Jan 10, 2020 at 9:43 AM Even Rouault wrote: > Hi, > > Motion: the GDAL project requests to OSGeo a 2000 USD budget for 2020 > > ~ > > +1 > > Even > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com >

Re: [gdal-dev] Motion: spend 60 USD / year for extended GitHub LFS

+1 Kurt On Tue, Oct 8, 2019, 6:22 AM Daniel Morissette wrote: > +1 > > Daniel > > > On 2019-10-08 06:49, Even Rouault wrote: > > Hi, > > > > This motion is to spend 5 USD/month * 12 = 60 USD annually to buy one > "data > > pack" ([1]) to extend the quota of the OSGeo GitHub organization for LFS

Re: [gdal-dev] Nomination of Sean Gillies for the GDAL PSC

+1 Kurt On Tue, Sep 17, 2019 at 6:22 AM Howard Butler wrote: > All, > > I would like to nominate Sean Gillies to the GDAL PSC. > > Sean leads the development of two important Python geospatial projects > based on GDAL/OGR – rasterio and Fiona. He has contributed many bug reports > and design

Re: [gdal-dev] Nomination of Mateusz Łoskot for the GDAL PSC

+1 Kurt On Tue, Sep 17, 2019 at 6:22 AM Howard Butler wrote: > All, > > I would like to nominate Mateusz Łoskot to the GDAL PSC. > > Mateusz has been an active contributor to the GDAL project for nearly > fifteen years. He was the very first paid maintainer for the project, > closing bugs and

Re: [gdal-dev] WKT driver in OGR?

Use the CSV driver? On Fri, Aug 16, 2019 at 7:02 AM Andrew Bell wrote: > Hi, > > I'm not seeing a driver for WKT geometry in OGR, though I know that WKT is > well-supported in the API in OGRGeometryFactory and such. Can I convert a > file containing WKT geometry with ogr2ogr? > > Thanks, > >

Re: [gdal-dev] NetCDF driver detected file type

. On Wed, Aug 7, 2019 at 2:36 PM Even Rouault wrote: > On mercredi 7 août 2019 14:24:32 CEST Kurt Schwehr wrote: > > Hmm... these are netcdf 5 according to file. > > HDF5, not netCDF 5. netCDF v4 file format is a profile on top of HDF5. > > > I have the extra fun that my buil

Re: [gdal-dev] NetCDF driver detected file type

Hmm... these are netcdf 5 according to file. Does that not imply that that I don't need to worry about NC4? file *.nc OR_ABI-L2-FDCF-M6_G17_s20192011300341_e20192011309408_c20192011309501.nc: Hierarchical Data Format (version 5) data

[gdal-dev] NetCDF driver detected file type

For a custom build of gdal, I'm seeing: Warning 1: NetCDF driver detected file type=5, but libnetcdf detected type=3 Any idea what is causing this? With gdal 2.3.2, from debian testing, I don't see the message. This warning message was added here:

Re: [gdal-dev] Migration of RFCs to Sphinx ?

+1 If possible: Rather than deleting old pages, they should link or redirect to the new location at there are many places that link to the old locations. On Fri, May 24, 2019 at 4:46 AM Jeff McKenna wrote: > Hi Even, > > I agree with emptying the old wiki page and placing a link there, to the

Re: [gdal-dev] Motion: adopt RFC 74: Migrate gdal.org to Sphinx

+1 KurtS On Mon, May 20, 2019 at 2:55 PM Even Rouault wrote: > Hi, > > I believe we are now in a state where the prototype new website is > functional > and should have content at least equivalent to the current one, so I > motion to > adopt RFC74: Migrate gdal.org to Sphinx: > >

Re: [gdal-dev] RFC 74: Migrate gdal.org to Sphinx

Awesome! On Sun, May 19, 2019, 9:55 AM Howard Butler wrote: > All, > > A successful OSGeo Community Sprint [1] saw myself, Even Rouault, Mateusz > Loskot, and Dan Baston furiously migrating and organizing gdal.org content > into a Sphinx-based organization. An example of that effort can be seen

Re: [gdal-dev] Motion: Add Norman Barker to GDAL PSC

+1 Kurt On Wed, May 15, 2019 at 10:01 AM Frank Warmerdam wrote: > +1 Frank > > On Wed, May 15, 2019 at 9:45 AM Daniel Morissette < > dmorisse...@mapgears.com> wrote: > >> +1 >> >> Daniel >> >> >> On 2019-05-15 09:03, Even Rouault wrote: >> > Hi, >> > >> > I propose to add Norman Barker to the

Re: [gdal-dev] Should the next version (previously 2.5) be called GDAL 3.0 ?

+1 Calling it 3.0 would definitely help non-developers understand how different/better things are. On Wed, May 1, 2019 at 12:09 PM Frank Warmerdam wrote: > Even, > > I think calling it 3.0 would be reasonable. > > Best regards, > Frank > > > On Wed, May 1, 2019 at 11:56 AM Even Rouault >

Re: [gdal-dev] Motion: Promote GDAL 2.5.0 rc1 for release

+1 kurt On Wed, May 1, 2019 at 7:56 AM Even Rouault wrote: > Hi, > > Motion: GDAL/OGR 2.5.0 rc1 is promoted to be the official 2.5.0 final > release. > > --- > > My vote: +1 > > --- > > A few bugs were discovered since rc1 (one of them in the new TileDB > driver), > but none of them are

Re: [gdal-dev] Trac Wiki (was: Closing remaining open Trac tickets ?)

If they are moved, can we put a redirect or at least leave a link to the new location? I am sure there are a huge number of links on the interwebs to the wiki and it would be a major bummer to have those all go dead. On Thu, Mar 21, 2019, 7:04 AM Mateusz Loskot wrote: > On Thu, 21 Mar 2019 at

Re: [gdal-dev] Closing remaining open Trac tickets ?

+1 On Wed, Mar 20, 2019 at 3:28 PM Even Rouault wrote: > Hi, > > As we have already more than 100 tickets open in github, I guess nobody no > longer looks at old Trac tickets. > I was wondering if we shouldn't mass close the remaining open tickets in > Trac, > with a message indicating that if

Re: [gdal-dev] Building only OGR

You can start by disabling drivers. You can get down to just a couple raster drivers pretty easily, but you won't be able to remove all of the raster code. I did exactly this with a bagel based build. I got it down to 21 raster drivers. I think I am down under 300K active LOC. On Sun, Mar 17,

  1   2   3   4   >