A bit of googling sometimes gives an indication. I was a little confused about SVG, not using it myself but getting quite a few references. E.g. this one in stackexchange, with a mention how often it was looked up: https://gis.stackexchange.com/questions/11476/importing-svg-into-gis Just an idea. Obviously, it is not easy to decide exactly what to do with this sort of information. Jan
On Mon, Jan 11, 2021 at 12:02 AM Even Rouault <even.roua...@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) 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 > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com > _______________________________________________ > 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