<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Hi,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Looking at the list, we use/support SDTS Raster import. As a US government format with the use case mentioned below, I’d prefer to not see the format removed from the software. We have some evidence that the format is still used by some
of our users.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The users of the software I help develop and maintain expect a high level of compatibility across releases. A commonly discussed use case involves rerunning the same code with the same data across many years to ensure reproducibility of
results. While we see the need to keep code maintainable, it feels important to consider this use case.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Not specific to the software I work on, I think of GDAL as a “swiss army knife” of geospatial format support. It is the FOSS way to access many formats both new and old. I do wonder whether alternatives available should be considered
when evaluating a given driver for removal. It would be unfortunate if there was no way to read a format anymore with available software.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Overall, we like the idea of introducing a process for this. Thinking about next steps, it is important to consider what the criterion should be as Even mentioned. How many users? Who are these users? How do we estimate the downstream
impact on users who don’t know that their format is being considered for removal? As others have mentioned, how does maintainability factor in? I hope that if there was a process to do this, that it would be codified and visible.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Best,<o:p></o:p></p>
<p class="MsoNormal">Jonathan<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> gdal-dev <gdal-dev-bounces@lists.osgeo.org> <b>
On Behalf Of </b>Even Rouault<br>
<b>Sent:</b> Sunday, January 10, 2021 6:02 PM<br>
<b>To:</b> gdal-dev@lists.osgeo.org<br>
<b>Subject:</b> [gdal-dev] Considering drivers removal ?<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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">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">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>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com">http://www.spatialys.com</a><br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><o:p></o:p></p>
</div>
</body>
</html>