Re: [QGIS-Developer] Question on FGDB support for "Save As" / "Export"
As a QGIS and ArcGIS user, I am glad the file geodatabase support is there, so please don’t take the following negatively. I am the Spatial Infrastructure Manager for a statewide Next Generation 9-1-1 implementation here in the U.S., and we have successfully shared data with local public safety agencies using GeoPackage generated from the Esri suite. Alex had mentioned this earlier, but I wanted to elaborate so you could pass it on to your constituents if need be. Users can create SpatiaLite or GeoPackage (v1.0, 1.1, 1.2) using either the Python Console or a Python script stored in the Workspace toolset under the Data Management Tools toolbox. This works at all license levels (Basic, Standard, or Advanced) and in Desktop (ArcMap\ArcCatalog) and ArcGIS Pro. Here is a link to the Desktop help which, in this case, is the same for Pro: http://desktop.arcgis.com/en/arcmap/latest/tools/data-management-toolbox/create-sqlite-database.htm Once created, it’s easy to drag-and-drop simple feature classes (points, lines, and polygons) from ESRI geodatabases into the OGC DB, and from OGC to Esri. We have no reported errors from QGIS users in the field with this type of data exchange, and vice versa. From my perspective, there is little use for file geodatabase exchange unless the other user is at a lesser ArcGIS Desktop version (as referenced by Alex). This also promotes the OGC portable database model over the use of shapefiles, in which we have seen degradation of attributes because of the DBF restrictions. v/r James Sent from my iPhone > On Aug 2, 2018, at 08:17, Even Rouault wrote: > >> On jeudi 2 août 2018 19:34:54 CEST Nyall Dawson wrote: >>> On Thu, 2 Aug 2018 at 18:21, Andreas Neumann wrote: >>> 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? >> That's a great idea! >> >> In the QGIS world we'd have to compromise a bit here and not allow >> editing of existing layers (as you'd normally get with the closed >> driver). I.e. we'd only use it when writing an existing layer out to a >> copy on disk (e.g. via right click menu on a vector layer). But still, >> allowing layers to be saved as a geodatabase would be a step forward. >> >> I'm not sure how this change would need to be made though. At the >> moment if you install the closed driver in osgeo4w it's always used, >> for both reading and writing layers. Even/Jürgen is this an osgeo4w >> thing or a GDAL thing? Is it possible to have two drivers installed >> for the one format and always read using the closed driver? > > As the FileGDB driver is loaded as a plugin by GDAL, it is registered first, > and then probed first when opening a dataset. > Banning one of the driver can be done by defining GDAL_SKIP=FileGDB or > GDAL_SKIP=OpenFileGDB and calling GDALAllRegister() again. > It is also possible to control which drivers are allowed at dataset opening > with GDALOpenEx() and the papszDriversAllowed argument (but that means you > need to know this is a FileGeodatabase) > > Even > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com > ___ > QGIS-Developer mailing list > QGIS-Developer@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@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Question on FGDB support for "Save As" / "Export"
On jeudi 2 août 2018 19:34:54 CEST Nyall Dawson wrote: > On Thu, 2 Aug 2018 at 18:21, Andreas Neumann wrote: > > 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? > That's a great idea! > > In the QGIS world we'd have to compromise a bit here and not allow > editing of existing layers (as you'd normally get with the closed > driver). I.e. we'd only use it when writing an existing layer out to a > copy on disk (e.g. via right click menu on a vector layer). But still, > allowing layers to be saved as a geodatabase would be a step forward. > > I'm not sure how this change would need to be made though. At the > moment if you install the closed driver in osgeo4w it's always used, > for both reading and writing layers. Even/Jürgen is this an osgeo4w > thing or a GDAL thing? Is it possible to have two drivers installed > for the one format and always read using the closed driver? As the FileGDB driver is loaded as a plugin by GDAL, it is registered first, and then probed first when opening a dataset. Banning one of the driver can be done by defining GDAL_SKIP=FileGDB or GDAL_SKIP=OpenFileGDB and calling GDALAllRegister() again. It is also possible to control which drivers are allowed at dataset opening with GDALOpenEx() and the papszDriversAllowed argument (but that means you need to know this is a FileGeodatabase) Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Question on FGDB support for "Save As" / "Export"
чт, 2 серп. 2018 о 12:35 Nyall Dawson пише: > I'm not sure how this change would need to be made though. At the > moment if you install the closed driver in osgeo4w it's always used, > for both reading and writing layers. Even/Jürgen is this an osgeo4w > thing or a GDAL thing? Is it possible to have two drivers installed > for the one format and always read using the closed driver? AFAIK, you can select which driver to use with envronment variable. > Another complication is that we'd still need a way for users to opt in > to using the closed driver for reading - as that may sometimes be > required too... So not a straightforward change, but still one that > I'd support! As I understand, we need something like existing rasters drivers list in the QGIS setttings where one can choose which drivers should be used. There is already ticket about this https://issues.qgis.org/issues/10313 -- Alexander Bruy ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Question on FGDB support for "Save As" / "Export"
On Thu, 2 Aug 2018 at 18:21, Andreas Neumann wrote: > 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? That's a great idea! In the QGIS world we'd have to compromise a bit here and not allow editing of existing layers (as you'd normally get with the closed driver). I.e. we'd only use it when writing an existing layer out to a copy on disk (e.g. via right click menu on a vector layer). But still, allowing layers to be saved as a geodatabase would be a step forward. I'm not sure how this change would need to be made though. At the moment if you install the closed driver in osgeo4w it's always used, for both reading and writing layers. Even/Jürgen is this an osgeo4w thing or a GDAL thing? Is it possible to have two drivers installed for the one format and always read using the closed driver? Another complication is that we'd still need a way for users to opt in to using the closed driver for reading - as that may sometimes be required too... So not a straightforward change, but still one that I'd support! Nyall ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Question on FGDB support for "Save As" / "Export"
Hi Andreas, On Tue, 31. Jul 2018 at 12:05:52 +0200, Andreas Neumann wrote: > 2. Currently, it can only be enabled in the OSGeo4W version by selecting > the "gdal-filegdb" package. The standalone installer does not include > this package. > About issue 2: > @Jürgen: can you include the necessary gdal-filegdb package also in the > standalone installer - or are there license problems? The standalone is just a partly snapshot of OSGeo4W (ie. the (virtual) qgis-full package and all it's dependencies). Any issues would already apply to OSGeo4W. The standalone includes the OSGeo4W Installer so you can add not included packages afterwards. Not very convienient of course for people that always need filegdb. Inclusion wouldn't be a problem - and just require adding gdal-filegdb as dependency to the qgis-full. Lack of (obvious) control which driver to use might be a problem for use (i.e. setting the environment variable OGR_SKIP) - if you want to switch between the two drivers. I don't have much experience with FileGDB. I only very rarely got data in FileGDB. Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de QGIS release manager (PSC) GermanyIRC: jef on FreeNode signature.asc Description: PGP signature ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Question on FGDB support for "Save As" / "Export"
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 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 SLOOW. Even in ArcGIS they are > slow to open and manage. GIve me shapefiles over this monstrosity any > day.) > > Nyall___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Question on FGDB support for "Save As" / "Export"
On 07/31/2018 02:28 PM, Nyall Dawson wrote: > On Tue, 31 Jul 2018 at 20:06, Andreas Neumann 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 SLOOW. Even in ArcGIS they are > slow to open and manage. GIve me shapefiles over this monstrosity any > day.) > > Nyall I agree if there's no way to easily include both drivers and allow the user to select which to use, the OpenFileGDB should be the default installed. Perhaps we can make it selectable? Also, a note on the original question/reason. Are users aware that Arc products can read gpkg and spatialite formats (since at least ArcMap 10.3). Geopackage is an OGC specification, this to me should provide leverage for people to argue that it's an acceptable deliverable fully compatible with ESRI. Thanks, Alex ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Question on FGDB support for "Save As" / "Export"
On Tue, 31 Jul 2018 at 20:06, Andreas Neumann 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 SLOOW. Even in ArcGIS they are slow to open and manage. GIve me shapefiles over this monstrosity any day.) Nyall ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Question on FGDB support for "Save As" / "Export"
Hi Matthias, We need to be able to select an existing fgdb-folder (as seen by the OS it is just a regular folder). Currently, QGIS just opens the folder and then expects the user to pick a file, but currently we can't select a folder without traversing deeper into it. Andreas On 2018-07-31 13:58, Matthias Kuhn wrote: > Hi, > > Just a quick question about the file vs. directory problem. Do we need > to be able to select an existing directory or a new one? > If it's the latter (new .gdb-folder), we can just use the existing file > dialog, which will return a path to a file name (but not yet create a > new file) and we can then have the fgdb driver create a new folder > instead of a file at this position. > I might be missing something though. > > Matthias > > On 07/31/2018 12:05 PM, Andreas Neumann wrote: > >> Hi, >> >> A Swiss QGIS user asked me if/how FGDB for export/Save as can be >> supported in QGIS - question specifically about the Windows distribution >> of QGIS 3.x. Sometimes, QGIS users have to deliver results in fgdb >> format, because their clients require it. >> >> A quick e-mail exchange with Even Roualt revealed the following: >> >> 1. it is already supported if the proper "gdal-filegdb" packages are >> installed. >> >> 2. Currently, it can only be enabled in the OSGeo4W version by selecting >> the "gdal-filegdb" package. The standalone installer does not include >> this package. >> >> 3. There are issues when wanting to "Save As" an additional layer into >> an already existing FGDB. The problem is that fgdb files are actually >> directories. And the current "Save As" dialog does not support selecting >> "directories" to save into, only files. As a workaround, it works if one >> copy/pastes the full path from the Windows file explorer into the "Save >> As" dialog, but not when selecting a directory interactively. >> >> Here is some info on the third issue from Even: >> >> "I don't have the solution on top of my mind. According to >> http://doc.qt.io/qt-5/qfiledialog.html#FileMode-enum it seems that you can >> setup the selector to select file or directories, but not both. >> We actually use the QFileDialog::getSaveFileName() API that probably >> internally resolves to QFileDialog::AnyFile >> Perhaps a more experience QT dev than me would have an idea. >> Or an hack (but not sure we can really do better) would be to allow the user >> to select any file in the .gdb directory, and then automatically strips out >> the filename to just keep the directory name when we see this a file in in a >> .gdb directory" >> >> --- >> >> So here are my two questions: >> >> About issue 2: >> >> @Jürgen: can you include the necessary gdal-filegdb package also in the >> standalone installer - or are there license problems? >> >> About issue 3: >> >> Does some dev have an idea or solution on how to more easily select a >> folder instead of a file, for the case of writing an additional layer >> into an already existing .fgdb folder? >> >> Thank you all for your ideas and the discussion, >> >> Andreas >> >> ___ >> QGIS-Developer mailing list >> QGIS-Developer@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@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@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Question on FGDB support for "Save As" / "Export"
Hi, Just a quick question about the file vs. directory problem. Do we need to be able to select an existing directory or a new one? If it's the latter (new .gdb-folder), we can just use the existing file dialog, which will return a path to a file name (but not yet create a new file) and we can then have the fgdb driver create a new folder instead of a file at this position. I might be missing something though. Matthias On 07/31/2018 12:05 PM, Andreas Neumann wrote: > Hi, > > A Swiss QGIS user asked me if/how FGDB for export/Save as can be > supported in QGIS - question specifically about the Windows distribution > of QGIS 3.x. Sometimes, QGIS users have to deliver results in fgdb > format, because their clients require it. > > A quick e-mail exchange with Even Roualt revealed the following: > > 1. it is already supported if the proper "gdal-filegdb" packages are > installed. > > 2. Currently, it can only be enabled in the OSGeo4W version by selecting > the "gdal-filegdb" package. The standalone installer does not include > this package. > > 3. There are issues when wanting to "Save As" an additional layer into > an already existing FGDB. The problem is that fgdb files are actually > directories. And the current "Save As" dialog does not support selecting > "directories" to save into, only files. As a workaround, it works if one > copy/pastes the full path from the Windows file explorer into the "Save > As" dialog, but not when selecting a directory interactively. > > Here is some info on the third issue from Even: > > "I don't have the solution on top of my mind. According to > http://doc.qt.io/qt-5/qfiledialog.html#FileMode-enum it seems that you can > setup the selector to select file or directories, but not both. > We actually use the QFileDialog::getSaveFileName() API that probably > internally resolves to QFileDialog::AnyFile > Perhaps a more experience QT dev than me would have an idea. > Or an hack (but not sure we can really do better) would be to allow the user > to select any file in the .gdb directory, and then automatically strips out > the filename to just keep the directory name when we see this a file in in a > .gdb directory" > > --- > > So here are my two questions: > > About issue 2: > > @Jürgen: can you include the necessary gdal-filegdb package also in the > standalone installer - or are there license problems? > > About issue 3: > > Does some dev have an idea or solution on how to more easily select a > folder instead of a file, for the case of writing an additional layer > into an already existing .fgdb folder? > > Thank you all for your ideas and the discussion, > > Andreas > > > > ___ > QGIS-Developer mailing list > QGIS-Developer@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@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Question on FGDB support for "Save As" / "Export"
Hi, A Swiss QGIS user asked me if/how FGDB for export/Save as can be supported in QGIS - question specifically about the Windows distribution of QGIS 3.x. Sometimes, QGIS users have to deliver results in fgdb format, because their clients require it. A quick e-mail exchange with Even Roualt revealed the following: 1. it is already supported if the proper "gdal-filegdb" packages are installed. 2. Currently, it can only be enabled in the OSGeo4W version by selecting the "gdal-filegdb" package. The standalone installer does not include this package. 3. There are issues when wanting to "Save As" an additional layer into an already existing FGDB. The problem is that fgdb files are actually directories. And the current "Save As" dialog does not support selecting "directories" to save into, only files. As a workaround, it works if one copy/pastes the full path from the Windows file explorer into the "Save As" dialog, but not when selecting a directory interactively. Here is some info on the third issue from Even: "I don't have the solution on top of my mind. According to http://doc.qt.io/qt-5/qfiledialog.html#FileMode-enum it seems that you can setup the selector to select file or directories, but not both. We actually use the QFileDialog::getSaveFileName() API that probably internally resolves to QFileDialog::AnyFile Perhaps a more experience QT dev than me would have an idea. Or an hack (but not sure we can really do better) would be to allow the user to select any file in the .gdb directory, and then automatically strips out the filename to just keep the directory name when we see this a file in in a .gdb directory" --- So here are my two questions: About issue 2: @Jürgen: can you include the necessary gdal-filegdb package also in the standalone installer - or are there license problems? About issue 3: Does some dev have an idea or solution on how to more easily select a folder instead of a file, for the case of writing an additional layer into an already existing .fgdb folder? Thank you all for your ideas and the discussion, Andreas___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
