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> 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@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
