On Mon, 11 Jan 2021 at 09:50, Jan Heckman <jan.heck...@gmail.com> wrote: > > 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.
I've previously found the SVG driver useful for getting data out of typically non-spatial formats for georeferencing (e.g. I once had to convert a bunch of spatial data which had been hand drawn in visio on top of a google map screenshot...). I'd be sorry to see this driver go, as it's a useful last-resort aid for situations like this. Nyall > 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 _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
