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