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.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
