<div dir="ltr">Hey guys, I was just typing pretty much the same thing.<div>So these drivers could be removed gracefully with a trace allowing gis-archeologists/archivists to use them.</div><div>I can just see the papers in my imagination.</div><div>Jan</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 11, 2021 at 1:03 AM Stephen Woodbridge <<a href="mailto:stephenwoodbridge37@gmail.com">stephenwoodbridge37@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Even,<br>
<br>
This makes a lot of sense to me. How would you handle this in Python?<br>
Would it make sense to create a GDAL-removed repository and move stuff <br>
into it just so it is available if someone wants it. This would not be <br>
supported or updated by GDAL just making it available if someone <br>
wants/needs to fork it, something else like this?<br>
<br>
-Steve W<br>
<br>
On 1/10/2021 6:02 PM, Even Rouault wrote:<br>
> Hi,<br>
><br>
> It's not spring yet, but I'm in a mood lately of axing useless things, and we<br>
> probably have tons of candidate for that in GDAL, especially in drivers.<br>
> I was going to just axe the DB2 driver<br>
> (<a href="https://github.com/OSGeo/gdal/pull/3366" rel="noreferrer" target="_blank">https://github.com/OSGeo/gdal/pull/3366</a>) but the issue is more general.<br>
><br>
> Any idea how we can know what is used and what isn't ? A "call-home"<br>
> functionality where we would track driver usage would only be acceptable if<br>
> people enable it and have network connectivity, so we won't probably get lots<br>
> of feedback. Having a spreadsheet with the driver list and asking people to<br>
> fill it would probably also receive little feedback. So the idea I had was to<br>
> do something like the following in the Open() method of a candidate for<br>
> removal:<br>
><br>
> GDALDataset* FooDriver::Open( .... )<br>
> {<br>
>     if( !Identify(poOpenInfo) )<br>
>        return nullptr;<br>
><br>
>     if( !CPLTestBool(CPLGetConfigOption("GDAL_ENABLE_DRIVER_FOO", "NO") )<br>
>     {<br>
>         CPLError(CE_Failure, CPLE_AppDefined,<br>
>      "Driver FOO is considered for removal in GDAL 3.5. You are invited "<br>
>      "to convert any dataset in that format to another more common one ."<br>
>      "If you need this driver in future GDAL versions, create a ticket at "<br>
>      "<a href="https://github.com/OSGeo/gdal" rel="noreferrer" target="_blank">https://github.com/OSGeo/gdal</a> (look first for an existing one first) to "<br>
>      "explain how critical it is for you (but the GDAL project may still "<br>
>      "remove it), and to enable it now, set the GDAL_ENABLE_DRIVER_FOO "<br>
>      "configuration option / environment variable to YES");<br>
>         return nullptr;<br>
>      }<br>
>      ...<br>
> }<br>
><br>
> That is, when we detect a file to be handled by the driver, emit the above<br>
> error message and do not open the dataset, unless the user defines the<br>
> environment variable.<br>
> Similarly in the Create()/CreateCopy() methods.<br>
> If we ship this in 3.3, with a 3.5 milestone for removal, this would offer a<br>
> feedback period of one year / 2 feature versions.<br>
><br>
> Here's my own list of candidates for retirement (probably over-conservative).<br>
> Mostly based on gut feeling. None of them are particularly bad citizens, but I<br>
> have no indication that they are still used, which doesn't mean they aren't.<br>
><br>
> * Raster side:<br>
> BPG<br>
> DB2Raster<br>
> DOQ1<br>
> DOQ2<br>
> E00GRID<br>
> Epsilon<br>
> FujiBAS<br>
> GS7BG<br>
> GSAG<br>
> IDA<br>
> JDEM<br>
> JPEG2000 (Jasper): JP2OpenJPEG is a better replacement<br>
> JPEGLS<br>
> LAN<br>
> MFF<br>
> MG4Lidar ?<br>
> NDF<br>
> NTv1<br>
> SDTS Raster<br>
> SGI<br>
> XPM<br>
> ZMap<br>
><br>
> * Vector side:<br>
> AERONAVFAA<br>
> ESRI ArcObjects<br>
> ARCGEN<br>
> BNA<br>
> Cloudant<br>
> CouchDB<br>
> DB2<br>
> DODS<br>
> FMEObjects Gateway<br>
> Geomedia MDB<br>
> GMT ASCII Vectors<br>
> GTM<br>
> HTF<br>
> INGRES<br>
> MongoDB (the old one, superseded by MongoDBv3)<br>
> OpenAIR<br>
> REC<br>
> SDTS<br>
> SUA<br>
> SVG<br>
> TIGER<br>
> WALK<br>
><br>
><br>
> Anything you'd add / remove ?<br>
><br>
> What is not obvious is what would be the criterion for keeping a driver: 1,<br>
> 10, 100 users asking for the driver to be kept ?<br>
> If a GDAL developer contributing to the overall good of the project needs the<br>
> preservation of a driver to be able to justify its continued involvement, I'd<br>
> tend to think it to be enough to keep it.<br>
><br>
><br>
> Even<br>
><br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>