[QGIS-Developer] Question on FGDB support for "Save As" / "Export"

[Alex M]

On 07/31/2018 02:28 PM, Nyall Dawson wrote:
> On Tue, 31 Jul 2018 at 20:06, Andreas Neumann <a.neumann at carto.net> wrote:
> 
>>
>> About issue 2:
>>
>> @Jürgen: can you include the necessary gdal-filegdb package also in the standalone installer - or are there license problems?
>>
> 
> -1 to packaging the gdal-filegdb package by default. My rationale:
> 
> - I've experienced lots of issues with this driver. For one, it's much
> slower to open gdbs, especially over networks. I've also hit bugs in
> the past where the driver doesn't handle certain subset queries in the
> same way as other ogr drivers (I can't recall the exact details, but I
> think the particular issue I hit was fixed.)
> 
> - The driver has known issues. From
> https://www.gdal.org/drv_filegdb.html, there's e.g. this important
> one: "The SDK is known to be unable to open layers with particular
> spatial reference systems.". And then on
> https://www.gdal.org/drv_openfilegdb.html there's a list of features
> that we'd lose by changing to the filegdb driver:
> 
> "Advantages of the OpenFileGDB driver:
> 
> Can read ArcGIS 9.X Geodatabases, and not only 10 or above.
> Can open layers with any spatial reference system.
> Thread-safe (i.e. datasources can be processed in parallel).
> Uses the VSI Virtual File API, enabling the user to read a Geodatabase
> in a ZIP file or stored on a HTTP server.
> Faster on databases with a big number of fields.
> Does not depend on a third-party library.
> Robust against corrupted Geodatabase files.
> 
> Drawbacks of the OpenFileGDB driver:
> 
> Read-only.
> Cannot use spatial indexes.
> Cannot read data from compressed data in CDF format (Compressed Data Format)."
> 
> That's a pretty significant loss in my opinion - especially the point
> about the closed source driver being non thread-safe.
> 
> - The OpenFileGDB driver is very heavily tested for robustness and
> security issues with the ongoing fuzz testing of GDAL drivers.
> 
> - Last, but not least, we'd lose the ability to actually fix issues.
> We'd be dependent on bug fixes in the ESRI SDK, and be powerless to
> get fixes we need implemented.
> 
> 
> These are all significant issues, and the moment we make the switch to
> the closed source driver and give users write support, there's no way
> we can revert this decision and remove the ability to edit GDB files.
> It's not a decision we can make lightly.
> 
> I'd rather leave this decision up to individual users (and those who
> make in-house software packages for deployment in their organisation)
> to make. I.e. leave it as is, where it's effectively an "opt-in"
> change. And push people to helping make the open driver better, as
> it's a more sustainable solution in the long term.
> 
> (Lastly, a rant: I hate file geodatabases. They are the WORST format
> for spatial data that I've seen. It's like ESRI took everything which
> people disliked about shapefiles and magnified those. Instead of a
> handful of files, we get hundreds. Instead of minor user confusion
> about how they need to package all the dependent files, we get this
> super-confusing folder/file mix, which causes all sorts of issues for
> non-ArcGIS software because it just breaks fundamental file management
> assumptions. And they are SLOW. So SLOOOOOOW. Even in ArcGIS they are
> slow to open and manage. GIve me shapefiles over this monstrosity any
> day.)
> 
> Nyall

I agree if there's no way to easily include both drivers and allow the
user to select which to use, the OpenFileGDB should be the default
installed. Perhaps we can make it selectable?

Also, a note on the original question/reason. Are users aware that Arc
products can read gpkg and spatialite formats (since at least ArcMap
10.3). Geopackage is an OGC specification, this to me should provide
leverage for people to argue that it's an acceptable deliverable fully
compatible with ESRI.

Thanks,
Alex