[gdal-dev] Considering drivers removal ?

[Jan Heckman]

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 <
stephenwoodbridge37 at gmail.com> wrote:

> 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
> wants/needs to fork it, something else like this?
>
> -Steve W
>
> On 1/10/2021 6:02 PM, Even Rouault 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) 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 (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
> >
>
> _______________________________________________
> 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/20210111/53bd1cf8/attachment.html>