[gdal-dev] Removing write side of (SDK based) FileGDB driver ?

[Even Rouault]

Actually thinking that there isn't just update, but also pure creation.

2 potential options for that one:

- either just completely remove the Create() implementation of FileGDB. 
Slightly backwards incompatible as users will have to change in their 
code their "FileGDB" string to "OpenFileGDB"

- or make it just a shim that forwards the call to the OpenFileGDB driver

Le 14/01/2025 à 19:49, Even Rouault via gdal-dev a écrit :
> Hi,
>
> You all know my ever appetite to remove useless code (especially when 
> I have to do painful exercices such as RFC 105 changes). This time I'd 
> be very well tempted to axe the write side of the FileGDB driver (the 
> one based on the Esri SDK). Unless I'm missing something, I don't 
> think it provides anything that the write side of the OpenFileGDB 
> driver wouldn't provide, and it comes with various hacks to overcome 
> shortcomings of the SDK (some of the hacks involve relying on the 
> OpenFileGDB driver...). The read side of the FileGDB driver is still 
> useful for compressed datasets, so we can't unfortunately completely 
> kill the driver. The change would make the FileGDB driver skip if 
> opened in update mode so that the OpenFileGDB driver kicks in instead, 
> so this should be unnoticed by users of the API (thinking here of a 
> QGIS user that would have the FileGDB driver installed and switching 
> to edit mode. The OpenFileGDB driver should be used. I'd have to test 
> that theory)
>
> Thoughts?
>
> Even
>
-- 
http://www.spatialys.com
My software is free, but my time generally not.
Butcher of all kinds of standards, open or closed formats. At the end, this is just about bytes.