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

[Andreas Neumann]

Hi Nyall, 

I agree - these are valid reasons not to replace the open source FGDB
driver with the closed source one. 

However - I wonder if there would be a way to support both drivers? The
Open Source driver as default for reading. And the FGDB driver for
writing? 

Note that I don't want to encourage usage of FGDB  - I am no fan either.
But it would be nice if we could write them in case a client demands
delivery in FGDB format - which can be the case in some contracts. 

Thanks for keeping the discussion going. 

Andreas 

On 2018-07-31 23:28, 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20180802/5bc1d30c/attachment.html>