[Qgis-developer] What happened to FGDB writing support in QGIS?

Sat Feb 4 10:56:00 PST 2017

Hi James,

On Sat, Feb 4, 2017 at 9:38 AM, James Wood <jwood911 at gmail.com> wrote:

> I've always wondered why the read-only driver was chosen to be included
> with the packaged app over the other. Both "open" the fGDB format. The file
> geodatabase is enough of a ubiquitous exchange format now that it makes
> sense to me to just include the write option by default instead of having
> to go install it with each upgrade.
>

FileGDB is a proprietary and closed data format (regardless of whether the
*use* of its compiled API is open-licensed). While it is ubiquitous in some
commercial software workflows, the data is locked into the vendor's format,
which is not even publicly described. This helps no one but the vendor.

In order for OGR's default, read-only OpenFileGDB driver to be created,
Even Rouault had to figure out the format by way of a huge amount of effort
(also note: his spec notes are freely available and open-licensed):
https://github.com/rouault/dump_gdbtable/wiki/FGDB-Spec

The source code for the driver is also open-source:
https://github.com/OSGeo/gdal/tree/trunk/gdal/ogr/ogrsf_frmts/openfilegdb

Without Even's work there would be no read-only driver, let alone one that
anyone else can improve upon.

Packaging GDAL/OGR, or QGIS, by default with the FileGDB driver and the
FileGDB API libs is now possible (or at least appears to be, due to the API
libs' new Apache 2.0 license). However, the onus to provide support for
vendor proprietary formats should not necessarily be on the open-source
projects. Even providing read-only drivers is not within their purview
(though they often do that). If a user wishes to use these formats and the
projects have volunteered development to support them, the user needs only
enable (like by choosing the option to install it in OSGeo4W) or compile
that support. This is an entirely appropriate expectation of users by
open-source project contributors and open data format supporters.

I'm also glad that Esri now includes some functionality with the
> SpatiaLite/Geopackage formats, although, IMHO, it still misses the mark and
> is lacking in functionality on several levels. The ability to write to a
> fGDB is definitely a nice option to have.

While it is definitely good to see such support, commercial GIS software
vendors have no real need to fully support non-vendor formats. Indeed, it
may go against their business model, which, by definition of using vendor
formats, is not in anyone else's interest. Supporting open data formats to
a limited extent allows such vendors to *say* they support such formats.

The solution is to move away from vendor proprietary formats and use open
data formats and open source software to read/write them. Everyone wins in
this scenario, except those looking to make money off of other's
vendor-locked data misfortunes.

I realize moving away from proprietary formats is not possible for many
users, who may be stuck using them due to constraints out of their control.
Petitioning to have those vendor formats accessible via at least an open
protocol is something users can attempt, to alleviate the situation.

I'm running QGIS 2.18.3 and ArcGIS Desktop 10.5/ArcGIS Pro 1.4 on Win10.
>

If you have Arc Feature or Map services available, which are REST-enabled,
consider investigating the new Arc REST provider in QGIS to access those.
It is open-source and was contributed by QGIS developer Sandro Mani:
https://changelog.kartoza.com/en/entry/543

Regards,

Larry Shaffer
Dakota Cartography
Black Hills, South Dakota
----------------------------------
Boundless Desktop and QGIS Support/Development
Boundless Spatial - http://boundlessgeo.com
lshaffer at boundlessgeo.com

Sent from my iPhone
>
> On Jan 26, 2017, at 14:19, Larry Shaffer <larrys at dakotacarto.com> wrote:
>
> Hi Calvin,
>
> On Wed, Jan 25, 2017 at 9:39 AM, C Hamilton <adenaculture at gmail.com>
> wrote:
>
>> I notice that FGDB writing support seems to have been dropped from QGIS.
>> It was in 2.14, but not in 2.16 nor 2.18. What happened? Can it be included
>> back into QGIS?
>>
>
> FileGDB write support is provided by the GDAL/OGR FileGDB driver, which
> requires the FileGDB API SDK [0] (that happens to now be under the Apache 2
> license [1]), not QGIS itself. When installing QGIS via the OSGeo4W
> installer, you also have to install the gdal-filegdb package, which is a
> plugin for GDAL/OGR that provides this write functionality; though, I am
> not sure which version of the SDK is currently included.
>
> In other words, the support was not dropped from QGIS, per se, but maybe
> just not included as a dependent package for GDAL/OGR, given its further
> proprietary library dependency. Upon looking at the 2.14 OSGeo4W 'full'
> packaging [2], I don't see that it is included, by default, there as well
> (at least, not anymore).
>
> There is also the read-only OpenFileGDB driver [3], included in GDAL/OGR
> 1.11+. While this does not allow writing, it can be used to dump data into
> a PostGIS setup (see page).
>
> [0] http://www.gdal.org/drv_filegdb.html
> [1] https://github.com/Esri/file-geodatabase-api
> [2] http://download.osgeo.org/osgeo4w/x86_64/release/qgis/qgis-l
> tr-full/setup.hint
> [3] http://www.gdal.org/drv_openfilegdb.html
>
> Regards,
>
> Larry Shaffer
> Dakota Cartography
> Black Hills, South Dakota
>
>
>> Thanks,
>>
>> Calvin
>>
>> _______________________________________________
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20170204/a0e0d572/attachment-0001.html>