On Tue, 14 Jan 2025, Even Rouault via gdal-dev wrote:
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?
If Esri released a new SDK with a changed file format,
would the SDK driver automatically write it, allowing (QGIS)
users to write the new format before OpenFileGDB catches up ?
Probably only possibly if the user updates the SDK *and* it is
binary compatible with the current one.
Is this a likely scenario ?
--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
