[gdal-dev] Killing useless write side of drivers

[Kurt Schwehr]

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 formats, but I don't think there are any of those.
Other projects that are dependent on reading GDAL output of formats on this
list should aim to add reading of at least one common format for critical
data. I know that can be hard for legacy code bases and for organizations
that have lots of process getting in the way, but if they are stuck, then
they need to bring resources to GDAL for those formats.

Andrew,

For the mission statement, I suggest starting a separate thread focused
just on the mission statement.

-Kurt

On Mon, Jan 20, 2025 at 11:42 AM Howard Butler via gdal-dev <
gdal-dev at lists.osgeo.org> wrote:

>
>
> > On Jan 16, 2025, at 10:48 AM, Even Rouault via gdal-dev <
> gdal-dev at lists.osgeo.org> wrote:
> >
> > Hi,
> >
> > I strongly suspect a number of drivers are hardly used, in particular
> their write/edition side
> >
> > My list of candidate victims for removal (of the write side) is at
> https://docs.google.com/spreadsheets/d/12yk0p8rRK4rAYO_VwXboatWkiILAjE2Cepu32lsHhM8/edit?gid=0#gid=0
> . Please add your potential comments in the greyed column
>
> It is frustrating that it is quite easy to add a driver to GDAL, but the
> mere mention of deprecation or removal of unused stuff elicits feedback to
> the effect of "isn't GDAL supposed to read/write everything? why are you
> dropping xx or yy drivers?" Drivers have a cost, and if no one is using
> them, the project should be able to drop them.
>
> Old drivers are just like my giant box of might-as-well-keep-them cables.
> Do I really need to keep a firewire cable for my twenty five year old ipod?
> While it is an emotional proxy that reminds me how old I am and how fast
> time is going, I think I can let it go :) Unlike my firewire cable, if we
> remove a driver, there are still ways to get access to it. There's
> pre-built docker containers. The code is still there, and we could
> reinstate something that was shown later to be needed or in use. It
> shouldn't be GDAL's burden to provide working software for unused forty
> year old geospatial one-off formats where we have no insight into whether
> or not they actually work or are being used. We don't want to toss things
> that people are using, but we don't need to keep everything that someone,
> somewhere *might* use in some future.
>
> The project needs help to do this. If your software uses GDAL and has any
> kind of driver telemetry, can you please inform us on format usage mix? Do
> you have examples of large data archives with some of these old, esoteric,
> and often one-off formats? Please point them out so it is clear there is a
> reason to bother. Otherwise, GDAL having a requirement to support every
> format it ever has forever is a burden that hinders its evolution and
> improvement.
>
> Howard
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20250120/3aef910a/attachment.htm>