[gdal-dev] Killing useless write side of drivers
Howard Butler
howard at hobu.co
Mon Jan 20 11:41:43 PST 2025
> 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
More information about the gdal-dev
mailing list