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

Tue Feb 7 01:29:16 PST 2017

Hey Larry,
Thanks for your reply. It's sometimes tough to mention Esri on this list without hackles getting raised, but it's out there. It's a fact. People use it. Some HAVE to use it. I'm in that crowd. It would be wrong on your part to assume that because I use it, I am unappreciative of the work that goes on for open source development. I also use QGIS in my workflows, and many kudos to all the devs that have created a really great open source product that has received international attention and in some places replaced COTS software. 

This was more of a "suggestion box" item than creating a stage for commercial vs. open source. And I deeply appreciate the work Mr. Rouault put into accessing the format. It makes my job infinitely easier... 

You grabbed the pulpit, and that's fine, but I wouldn't be on this list if I weren't a fan, so back to the target item, and let's keep this simple: 
1. It has already been written. 
2. There are two things that do the same task, but one does an additional task (value-added). 
3. Many things that have already been written have been incorporated into the core.
4. OpenFileGDB is incorporated by default in the core now. 
5. My question was simple and innocent without prejudice: Why choose one over the other to package in the core?

Thanks,

Sent from my iPhone

> On Feb 4, 2017, at 12:56, Larry Shaffer <larrys at dakotacarto.com> wrote:
> 
> 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-ltr-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/20170207/3951fddd/attachment.html>