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 <[email protected]> wrote: > > Hi James, > >> On Sat, Feb 4, 2017 at 9:38 AM, James Wood <[email protected]> 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 > [email protected] > >> Sent from my iPhone >> >>> On Jan 26, 2017, at 14:19, Larry Shaffer <[email protected]> wrote: >>> >>> Hi Calvin, >>> >>>> On Wed, Jan 25, 2017 at 9:39 AM, C Hamilton <[email protected]> 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 >>>> [email protected] >>>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >>>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer >>> >>> _______________________________________________ >>> Qgis-developer mailing list >>> [email protected] >>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer >
_______________________________________________ Qgis-developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
