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
