[gdal-dev] [EXTERNAL] Re: Considering drivers removal ?

Mon Jan 11 16:08:54 PST 2021

Speaking on behave of folks who support archives, I highly recommend keeping old drivers, unless as Frank stated, they cause an issue (code or license). We are often faced with dealing with code rot, but in the same vein, we will also find ourselves dealing with more and more outdated file formats. I would much rather keep an old harmless driver around than trying to install crusty binaries (or compile old code). To clean-up the growing list of drivers, perhaps the code and driver listings can be grouped together (only shown with some flag .e.g. --show_crusty_drivers :-).

my 2 cents,
Trent

________________________________
From: gdal-dev <gdal-dev-bounces at lists.osgeo.org> on behalf of Frank Warmerdam <warmerdam at pobox.com>
Sent: Monday, January 11, 2021 3:54 PM
To: Even Rouault <even.rouault at spatialys.com>
Cc: gdal dev <gdal-dev at lists.osgeo.org>
Subject: [EXTERNAL] 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 to dependence on external libraries and services.  We can always reintroduce them if someone comes forward and wants them and is willing to help support them.

LAN, NTv1 and SDTS Raster are examples (IMHO) of relatively low value drivers that should be retained because they are buildable, testable and not problematic.

Best regards,
Frank

On Sun, Jan 10, 2021 at 6:02 PM Even Rouault <even.rouault at spatialys.com<mailto:even.rouault at spatialys.com>> wrote:
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<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOSGeo%2Fgdal%2Fpull%2F3366&data=04%7C01%7Cthare%40usgs.gov%7C1e2f55b493a14743e05308d8b68403af%7C0693b5ba4b184d7b9341f32f400a5494%7C0%7C0%7C637460025413382723%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=yL2QV58xeFIATK6fhCNe9D5spR49Hi9wdmOFwPZLwV4%3D&reserved=0>) but the issue is more general.

Any idea how we can know what is used and what isn't ? A "call-home"
functionality where we would track driver usage would only be acceptable if
people enable it and have network connectivity, so we won't probably get lots
of feedback. Having a spreadsheet with the driver list and asking people to
fill it would probably also receive little feedback. So the idea I had was to
do something like the following in the Open() method of a candidate for
removal:

GDALDataset* FooDriver::Open( .... )
{
   if( !Identify(poOpenInfo) )
      return nullptr;

   if( !CPLTestBool(CPLGetConfigOption("GDAL_ENABLE_DRIVER_FOO", "NO") )
   {
       CPLError(CE_Failure, CPLE_AppDefined,
    "Driver FOO is considered for removal in GDAL 3.5. You are invited "
    "to convert any dataset in that format to another more common one ."
    "If you need this driver in future GDAL versions, create a ticket at "
    "https://github.com/OSGeo/gdal<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOSGeo%2Fgdal&data=04%7C01%7Cthare%40usgs.gov%7C1e2f55b493a14743e05308d8b68403af%7C0693b5ba4b184d7b9341f32f400a5494%7C0%7C0%7C637460025413382723%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=acUQRtJEPXcmhT0cB0VeH0pRzCc8r5n5Pj7E1EtdFjA%3D&reserved=0> (look first for an existing one first) to "
    "explain how critical it is for you (but the GDAL project may still "
    "remove it), and to enable it now, set the GDAL_ENABLE_DRIVER_FOO "
    "configuration option / environment variable to YES");
       return nullptr;
    }
    ...
}

That is, when we detect a file to be handled by the driver, emit the above
error message and do not open the dataset, unless the user defines the
environment variable.
Similarly in the Create()/CreateCopy() methods.
If we ship this in 3.3, with a 3.5 milestone for removal, this would offer a
feedback period of one year / 2 feature versions.

Here's my own list of candidates for retirement (probably over-conservative).
Mostly based on gut feeling. None of them are particularly bad citizens, but I
have no indication that they are still used, which doesn't mean they aren't.

* Raster side:
BPG
DB2Raster
DOQ1
DOQ2
E00GRID
Epsilon
FujiBAS
GS7BG
GSAG
IDA
JDEM
JPEG2000 (Jasper): JP2OpenJPEG is a better replacement
JPEGLS
LAN
MFF
MG4Lidar ?
NDF
NTv1
SDTS Raster
SGI
XPM
ZMap

* Vector side:
AERONAVFAA
ESRI ArcObjects
ARCGEN
BNA
Cloudant
CouchDB
DB2
DODS
FMEObjects Gateway
Geomedia MDB
GMT ASCII Vectors
GTM
HTF
INGRES
MongoDB (the old one, superseded by MongoDBv3)
OpenAIR
REC
SDTS
SUA
SVG
TIGER
WALK

Anything you'd add / remove ?

What is not obvious is what would be the criterion for keeping a driver: 1,
10, 100 users asking for the driver to be kept ?
If a GDAL developer contributing to the overall good of the project needs the
preservation of a driver to be able to justify its continued involvement, I'd
tend to think it to be enough to keep it.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com<https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.spatialys.com%2F&data=04%7C01%7Cthare%40usgs.gov%7C1e2f55b493a14743e05308d8b68403af%7C0693b5ba4b184d7b9341f32f400a5494%7C0%7C0%7C637460025413392679%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=BLvei4JhJxnKvFiWEo2uq5u3uNOvvZ%2FowLqGsOqqmjE%3D&reserved=0>
_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/gdal-dev<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fgdal-dev&data=04%7C01%7Cthare%40usgs.gov%7C1e2f55b493a14743e05308d8b68403af%7C0693b5ba4b184d7b9341f32f400a5494%7C0%7C0%7C637460025413392679%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=vrqrivmgWe6K9hicpHpkREkj85zYGQsJ7loflu9I3VQ%3D&reserved=0>

--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com<mailto:warmerdam at pobox.com>
light and sound - activate the windows | +1 650-701-7823
and watch the world go round - Rush    | Geospatial Software Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210112/9b7cb4c9/attachment-0001.html>