Re: [gdal-dev] Considering drivers removal ?

I am also supportive of RFC approvals before someone goes and invests the time to develop a driver. Otherwise it is easy to get in the spot where it's not merged because the community didn't want it included. A nice thing the RFC process would ensure is a full document of the expectations of

Re: [gdal-dev] Considering drivers removal ?

Hi Sean, I would also be supportive to formalize the driver submission process. Best regards, Tamas Sean Gillies ezt írta (időpont: 2021. jan. 28., Cs, 17:39): > Hi Tamas, > > Are you suggesting that a RFC be required for a new driver? I would > support this 100%. > > On Wed, Jan 27, 2021

Re: [gdal-dev] Considering drivers removal ?

Hi Tamas, Are you suggesting that a RFC be required for a new driver? I would support this 100%. On Wed, Jan 27, 2021 at 2:17 PM Tamas Szekeres wrote: > David, > > Up to this time the driver writers were highly welcomed to author new > drivers for the project and these effort didn't require a

Re: [gdal-dev] Considering drivers removal ?

On Wed, 27 Jan 2021, gdisk.mike wrote: Just curious - Some time ago there was a motion for RFC 76 - OGR Python drivers. Correct me if I'm wrong, but this sort of makes it easy to add python drivers? Perhaps this could be a means for others to add/reclaim a driver that gets dropped? RFC 76 is

Re: [gdal-dev] Considering drivers removal ?

Just curious - Some time ago there was a motion for RFC 76 - OGR Python drivers. Correct me if I'm wrong, but this sort of makes it easy to add python drivers? Perhaps this could be a means for others to add/reclaim a driver that gets dropped? v/r, Mike On Wed, Jan 27, 2021 at 2:17 PM Tamas

Re: [gdal-dev] Considering drivers removal ?

David, Up to this time the driver writers were highly welcomed to author new drivers for the project and these effort didn't require a separate RFC in terms of the Project Management Committee Guidelines document. Adding new drivers hasn't been

Re: [gdal-dev] Considering drivers removal ?

I think a 4th option is a hybrid approach of moving to a more modular plug-in architecture that allows the core more flexibility to evolve at the same time by moving to a more plug-in driver allows for more independent development, testing and release lets the community participation. This does

Re: [gdal-dev] Considering drivers removal ?

> but from my point of view supporting a lot of formats is part of GDAL's > success, GDAL is a 22 year old software project. It's not just that GDAL supports lots of formats. It is also that the code supporting all of those formats is meticulously maintained, and it maintains *good* support

Re: [gdal-dev] Considering drivers removal ?

I am currently trying to add a Zarr driver to GDAL (see https://github.com/OSGeo/gdal/pull/3411), but from what I can see the trend is to remove drivers, so I'm now wondering it I should pursue this effort. I'm relatively new to GDAL, but from my point of view supporting a lot of formats is part

Re: [gdal-dev] Considering drivers removal ?

On Tue, Jan 12, 2021 at 11:36 PM Even Rouault wrote: > > The issue with esoteric/legacy drivers is not that much maintenance of the > actual code of the drivers, in the sense of dealing with bug reports, > questions, etc. (pretty sure they are none for the ones I listed). Most of > them must

Re: [gdal-dev] Considering drivers removal ?

On 1/12/2021 5:36 PM, Even Rouault wrote: On mardi 12 janvier 2021 12:56:13 CET Frank Warmerdam wrote: On Tue, Jan 12, 2021 at 12:38 PM Howard Butler wrote: The only question that matters here is "Who is going to maintain it?" and if the answer to that is "no one", it should be removed. There

Re: [gdal-dev] Considering drivers removal ?

On mardi 12 janvier 2021 12:56:13 CET Frank Warmerdam wrote: > On Tue, Jan 12, 2021 at 12:38 PM Howard Butler wrote: > > The only question that matters here is "Who is going to maintain it?" and > > if the answer to that is "no one", it should be removed. There doesn't > > need > > to be any

Re: [gdal-dev] Considering drivers removal ?

On Tue, Jan 12, 2021 at 12:38 PM Howard Butler wrote: > The only question that matters here is "Who is going to maintain it?" and > if the answer to that is "no one", it should be removed. There doesn't need > to be any meetings because the only criteria that matters is if someone is > willing

Re: [gdal-dev] Considering drivers removal ?

> On Jan 12, 2021, at 8:48 AM, Jonathan Gale wrote: > > Hi, > > Looking at the list, we use/support SDTS Raster import. As a US government > format with the use case mentioned below, I’d prefer to not see the format > removed from the software. We have some evidence that the format is

Re: [gdal-dev] Considering drivers removal ?

: gdal-dev On Behalf Of Even Rouault Sent: Sunday, January 10, 2021 6:02 PM To: gdal-dev@lists.osgeo.org Subject: [gdal-dev] Considering drivers removal ? Hi, It's not spring yet, but I'm in a mood lately of axing useless things, and we probably have tons of candidate for that in GDAL,

Re: [gdal-dev] Considering drivers removal ?

In good company when pruning the source trees: https://www.phoronix.com/scan.php?page=news_item=2021-Linux-Drop-Old-CPUs Apparently 68000 may not be supported any longer in linux... Just joking. Hope you don't mind... On Tue, Jan 12, 2021 at 3:46 AM Jed O. Kaplan wrote: > I for one am using the

Re: [gdal-dev] Considering drivers removal ?

I for one am using the GMT vector driver for GDAL on a regular basis, e.g., for integration between GRASS GIS and GMT for cartography. I am grateful to the developers for their continued support for this driver. Thanks, Jed ___ gdal-dev mailing list

Re: [gdal-dev] Considering drivers removal ?

hould be kept alive until we finish the integration with the GDAL vector side. Joaquim -Original Message- From: gdal-dev On Behalf Of jratike80 Sent: Monday, January 11, 2021 6:56 PM To: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] Considering drivers removal ? Hi, The joy of b

Re: [gdal-dev] Considering drivers removal ?

Even, My opinion is that old drivers which do not depend on external libraries/services and that we have tests for should be retained until they cause painful problems. I would be supportive of dropping drivers for which there is no apparent interest, and that are not buildable and testable due

Re: [gdal-dev] Considering drivers removal ?

Hi Even, On Mon, Jan 11, 2021 at 7:44 AM Even Rouault wrote: > Hi, > > trying to answer the different points raised up to now: > > - SVG: let's keep it as it is used. This is exactly the feedback I'm > seeking > for. I had developed this as a toy, crazy me, I won't do it anymore. No > idea >

Re: [gdal-dev] Considering drivers removal ?

Hi, The joy of being a Windows user is that it is so easy to use old GDAL versions if the binaries still happen to be on some dusty backup disk. Even the FWTools including GDAL 1.7.0 from 2010 seemed to work fine and include quite a many later removed drivers. A few comments about the driver

Re: [gdal-dev] Considering drivers removal ?

Sorry, I didn't read the first message in it entirety before digging in to the thread. Reading over the proposed list of removals, nothing jumps out at me as problematic. signature.asc Description: PGP signature ___ gdal-dev mailing list

Re: [gdal-dev] Considering drivers removal ?

Bearing in mind that I use none of the drivers on Even's list, I find his suggestion and reasoning compelling. I especially agree with his comment that the only way to get anyone's attention is to break their workflow, if only temporarily. The main risk here is that a

Re: [gdal-dev] Considering drivers removal ?

Hi, trying to answer the different points raised up to now: - SVG: let's keep it as it is used. This is exactly the feedback I'm seeking for. I had developed this as a toy, crazy me, I won't do it anymore. No idea anyone was using it actually. - making those driver plugins. This would require

Re: [gdal-dev] Considering drivers removal ?

On Mon, 11 Jan 2021, Even Rouault wrote: It's not spring yet, but I'm in a mood lately of axing useless things, and we probably have tons of candidate for that in GDAL, especially in drivers. I was going to just axe the DB2 driver (https://github.com/OSGeo/gdal/pull/3366) but the issue is more

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] Considering drivers removal ?

Hey guys, I was just typing pretty much the same thing. So these drivers could be removed gracefully with a trace allowing gis-archeologists/archivists to use them. I can just see the papers in my imagination. Jan On Mon, Jan 11, 2021 at 1:03 AM Stephen Woodbridge < stephenwoodbridg...@gmail.com>

Re: [gdal-dev] Considering drivers removal ?

Even, This makes a lot of sense to me. How would you handle this in Python? Would it make sense to create a GDAL-removed repository and move stuff into it just so it is available if someone wants it. This would not be supported or updated by GDAL just making it available if someone

Re: [gdal-dev] Considering drivers removal ?

Could you simply make them all plugins and announce that they will be unmaintained? After a release cycle, we place such things into their own repo. Don't know if that would work for GDAL. On Sun, Jan 10, 2021, 6:02 PM Even Rouault wrote: > Hi, > > It's not spring yet, but I'm in a mood lately

Re: [gdal-dev] Considering drivers removal ?

On Mon, 11 Jan 2021 at 09:50, Jan Heckman wrote: > > A bit of googling sometimes gives an indication. I was a little confused > about SVG, not using it myself but getting quite a few references. > E.g. this one in stackexchange, with a mention how often it was looked up: >

Re: [gdal-dev] Considering drivers removal ?

A bit of googling sometimes gives an indication. I was a little confused about SVG, not using it myself but getting quite a few references. E.g. this one in stackexchange, with a mention how often it was looked up: https://gis.stackexchange.com/questions/11476/importing-svg-into-gis Just an idea.

[gdal-dev] Considering drivers removal ?

Hi, It's not spring yet, but I'm in a mood lately of axing useless things, and we probably have tons of candidate for that in GDAL, especially in drivers. I was going to just axe the DB2 driver (https://github.com/OSGeo/gdal/pull/3366) but the issue is more general. Any idea how we can know