[gdal-dev] Considering drivers removal ?

Mon Jan 11 15:34:20 PST 2021

> - GMT is an active project and some GMT developers appear on this list as well. Maybe some of them happend to read this and say if GMT ASCII vectors are still important for GMT. Or otherwise I can ask from the GMT forum.

Right.

The GMT raster driver is from the times GNT used a 1-d array to represent 2-D grids in netCDF. That was abandoned some ~15 years ago for COARS compliant nc grids and is a good candidate for deprecation.

The " GMT ASCII vectors" format (written under contract with NIWA) is still very much used (under the hood) by the GMT library and should be kept alive until we finish the integration with the GDAL vector side.

Joaquim

-----Original Message-----
From: gdal-dev <gdal-dev-bounces at lists.osgeo.org> On Behalf Of jratike80
Sent: Monday, January 11, 2021 6:56 PM
To: gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] Considering drivers removal ?

Hi,

The joy of being a Windows user is that it is so easy to use old GDAL versions if the binaries still happen to be on some dusty backup disk. Even the FWTools including GDAL 1.7.0 from 2010 seemed to work fine and include quite a many later removed drivers.

A few comments about the driver list:

- There are indeed questions about SVG in gis.stackexchange every now and then.
- I used LAN a lot when FWTools was young and ERDAS wrote bad GeoTIFFs.
Things are probably changed since that. 
- GMT is an active project and some GMT developers appear on this list as well. Maybe some of them happend to read this and say if GMT ASCII vectors are still important for GMT. Or otherwise I can ask from the GMT forum.
- GPS Track Maker, as far as I know, is quite popular in Brazil. However, when I used the software I just used GPX format for data transfer. Are there any Brazilian GDAL user here to comment?

When it comes to Windows binaries, there is a very valuable archive in https://gisinternals.com/archive.php. It would be pity if it would get lost some day.

-Jukka Rahkonen-

Even Rouault-2 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 at .osgeo

> https://lists.osgeo.org/mailman/listinfo/gdal-dev

--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev