Re: [QGIS-Developer] Question on FGDB support for "Save As" / "Export"

[James Wood]

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] [Qgis-user] Split features tool behavior

[James Wood]

Hey Andreas,
I haven't experienced the invalid geometry as you describe, but I did find that 
my QGIS install had some issues. I have upgraded to 2.18.9 on Win10. If you 
have a sample of your data available, I would be happy to try to corroborate. 

James
Sent from my iPhone

> On May 29, 2017, at 06:16, Andreas Wicht <a.wi...@gmail.com> wrote:
> 
>> On 28 May 2017 at 14:43, James Wood <jwood...@gmail.com> wrote:
>> On the digitizing toolbar, try "Split Parts" instead of "Split Features" on 
>> multipart polygons.
> 
> Thank you for the hint, James. Somehow I always thought that this
> function is only suitable for separating an existing part from a
> feature (never used it though).
> Yet, if you cut a polygon with the "Split Parts" tool, the output will
> be an invalid geometry (I observed self-intersections). This as well
> can not be the intended behavior. I could observe those errors in
> simple scratch layers as well as in PostGIS layers.
> 
> Has anybody else experienced this behavior?
___
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] [Qgis-user] Split features tool behavior

[James Wood]

Hey Andreas,
On the digitizing toolbar, try "Split Parts" instead of "Split Features" on 
multipart polygons. 

HTH,
James
Sent from my iPhone

> On May 22, 2017, at 06:49, Andreas Wicht  wrote:
> 
> Hi all,
> 
> I have a question regarding the behavior of the "split features" tool
> when it comes to multipart polygons.
> For that I created a small example (see split_features_1.png).
> 
> The polygon "1" is a multipart polygon as shown in the screenshot.
> Let's say a user wants to split the lower polygon into two in order to
> merge one part to the polygon "3" (here the workaround would be the
> usage of the reshape features tool) or to create an entirely new
> feature. (see split_features_2.png).
> 
> The expected result would be a the separated polygon (here on the
> right) and the rest of the polygon including the part on the top. 1
> Multipart Polygon and 1 Polygon.
> 
> The QGIS result is three separate Polygons. This behavior can be
> dangerous when editing complex layers.
> If furthermore attributes are being changed and aggregations happen
> potential errors or unexpected results for a user are imminent.
> 
> Other GIS produce the expected output of 1 Multipart Polygon and 1 Polygon.
> 
> What is the specific intention behind this behavior as it seems not
> quite intuitive?
> 
> Cheers
> 
> 
> ___
> Qgis-user mailing list
> qgis-u...@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
___
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] What happened to FGDB writing support in QGIS?

[James Wood]

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 <lar...@dakotacarto.com> wrote:
> 
> Hi James,
> 
>> On Sat, Feb 4, 2017 at 9:38 AM, James Wood <jwood...@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

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

[James Wood]

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. 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. 

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

Sent from my iPhone

> On Jan 26, 2017, at 14:19, Larry Shaffer  wrote:
> 
> Hi Calvin,
> 
>> On Wed, Jan 25, 2017 at 9:39 AM, C Hamilton  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@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] 2.6: first overview

[James Wood]

Nic,
I upgraded to 2.6.0 x64 using the stand-alone installer for Windows (I have two 
machines: OS 8 and 7 SP1). I am not experiencing the attribute table editing 
issue that you describe. I experienced a couple of crash dump error windows on 
exit, but these were mostly while saving older QGIS documents to the new format 
that also had pathing problems to some layers. Once saved as a 2.6 doc, I have 
not had any crash dump errors on exit. Also, with respect to the Browse option 
for unhandled layers, it was greyed out for me when the referenced MSSQL 
spatial DB had already been deleted. Obviously, these layers were 
inconsequential, but it would have been easy to manually enter the new instance 
path had I needed to.
 
Love the new features and improvements with 2.6...
 
All the best,
James
 
 
From: sciurusurba...@hotmail.it
To: qgis-developer@lists.osgeo.org
Date: Sun, 2 Nov 2014 23:11:14 +0100
Subject: [Qgis-developer] 2.6: first overview








Hi all,
just few things I'm
experiencing with 2.6:





Attribute Table: modifying the content of a cell, it needs to save and reopen 
the table to
see it updated...normal behaviour?

Crash:
different types. Usually c
losing the project, QGIS ends up with a
minidump or the MS error window The software stopped to work
etc etc. This happens closing .qgs from 2.2 with or without
saving to 2.6 version. Sometimes also while working. Attached you
can find the .dmp (shall I upload them? I don't know how to deal
with). Actually it's a quite annoying issue...


Corrupt layers: the table appears but double-clicking the source it
doesn't open the explorer as in 2.2; it only allows to modify the folder
destination as text. Is that the new behavior?
Translation (ITA):
just few oversights:

color selection
panel: incolla collore

modify widget
properties: il widget di modica può...






Is there anyone with the
same issues? I'm working with W8.1 64bit and QGIS standalone. 






As always: thank you all for
your work!




All the best,




Nic

  

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer  
  ___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Geoprocessing Bug on ubuntu 14.04 and OSGEO4W

[James Wood]

Randy,I can confirm on Win 7 x64 with the standalone installer. It was toast at 
35%... right on cue. As an alternative, in the Processing Toolbox, under 
SAGAShapes - ToolsCut shapes layer worked super quick using the 'completely 
contained' method. Best Regards,James Date: Sun, 20 Jul 2014 13:47:23 -0400
From: rjh...@northrivergeographic.com
To: qgis-developer@lists.osgeo.org
Subject: [Qgis-developer] Geoprocessing Bug on ubuntu 14.04 and OSGEO4W


  


  
  
Sorry if this is cross posting (to a degree - I just filed a bug
report also). 



This occurs on Ubuntugis-unstable and osgeo4w 64bit. 



I've run into a problem using clip under geoprocessing: I'm clipping
a large contour dataset by a polygon. At 34% ubuntu throws an error
and at 35% windows throws an error. I went back and double checked
projection/data/etc. Both windows and Ubuntu seem to create the same
log. Here is the Ubuntu-unstable one: 



An error has occured while executing Python code: 
Traceback (most recent call last):

   File
/usr/share/qgis/python/plugins/fTools/tools/doGeoprocessing.py,
line 316, in run

   geos, feature, match, error = self.clip()

   File
/usr/share/qgis/python/plugins/fTools/tools/doGeoprocessing.py,
line 1537, in clip

   geom = QgsGeometry( inFeatA.geometry() )

  TypeError: arguments did not match any overloaded call:

   QgsGeometry(): too many arguments

   QgsGeometry(QgsGeometry): argument 1 has unexpected type
'NoneType'

 
Python version:

  2.7.6 (default, Mar 22 2014, 23:03:41) 

  [GCC 4.8.2]

 
QGIS version:

  2.4.0-Chugiak Chugiak, exported

 Python path: ['/usr/share/qgis/python/plugins/processing',
  
'/home/rjhale/.qgis2/python/plugins/opengeo/ext-libs/httplib2-0.8-py2.7.egg',

  
'/home/rjhale/.qgis2/python/plugins/opengeo/ext-libs/requests-2.0.1-py2.7.egg',

  
'/home/rjhale/.qgis2/python/plugins/opengeo/ext-libs/raven-3.5.1-py2.7.egg',

  
'/home/rjhale/.qgis2/python/plugins/opengeo/ext-libs/gsconfig-0.6.6-py2.7.egg',

  
'/home/rjhale/.qgis2/python/plugins/opengeo/ext-libs/gsimporter-0.1-py2.7.egg',

  
'/home/rjhale/.qgis2/python/plugins/opengeo/ext-libs/nose-1.3.0-py2.7.egg',

  
'/home/rjhale/.qgis2/python/plugins/opengeo/ext-libs/nose_html-1.1-py2.7.egg',

  
'/home/rjhale/.qgis2/python/plugins/opengeo/ext-libs/coverage-3.7-py2.7-win32.egg',

  '/usr/share/qgis/python', u'/home/rjhale/.qgis2/python',
  u'/home/rjhale/.qgis2/python/plugins',
  '/usr/share/qgis/python/plugins', '/usr/lib/python2.7',
  '/usr/lib/python2.7/plat-x86_64-linux-gnu',
  '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old',
  '/usr/lib/python2.7/lib-dynload',
  '/usr/local/lib/python2.7/dist-packages',
  '/usr/lib/python2.7/dist-packages',
  '/usr/lib/python2.7/dist-packages/PILcompat',
  '/usr/lib/python2.7/dist-packages/gtk-2.0',
  '/usr/lib/pymodules/python2.7',
  '/usr/lib/python2.7/dist-packages/ubuntu-sso-client',
  '/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode',
  '/home/rjhale/.qgis2/python/plugins/opengeo/ext-libs',
  '/home/rjhale/.qgis2/python/plugins/DigitizingTools/tools',
  '/home/rjhale/.qgis2/python/plugins/MetaSearch/ext-libs',
  '/usr/share/qgis/python/plugins/fTools/tools']



I filed a bug report: http://hub.qgis.org/issues/10917

I have shared my data if you wish to play with it (337mb):
https://drive.google.com/folderview?id=0B8WLtz606XDdOTNkN0xhenVCX0kusp=sharing



Thanks again, 

Randy

-- 
-
Randal Hale
North River Geographic Systems, Inc
http://www.northrivergeographic.com
423.653.3611 rjh...@northrivergeographic.com
twitter:rjhale http://about.me/rjhale
http://www.northrivergeographic.com/spatial-connect
  


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer  
  ___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Selection Within Stacked Geometry

[James Wood]

I'm working with conflict data, and because of escalation (e.g., kidnappings, 
bombings and insurgent attacks can lead to full-scale territorial disputes), 
temporal point features can become stacked. I was initially trying to figure 
out a way to highlight a record within a selected set in the attribute table 
and zoom to that point without loosing the original selection, but the Advanced 
Filter may be the best way to handle that. As I was panning the map, though, I 
noticed some locations that should have been selected from my query, and upon 
inspection, realized they were stacked points. Evidently the points on top 
prevented me from seeing the selected ones underneath. Even using the point 
displacement renderer (which is a pretty slick tool, btw) the selection was 
still hidden in the original point stack. Should I not be able to see my 
selections on the map canvas in relation to my other point data or is there a 
setting or trick here that I'm missing?
 
I'm a relatively new QGIS user, so please take that into consideration. I'm 
sure this has been discussed before, and I did some online searches but came up 
with very little. I did find this, but nothing related to point selections or 
how those would be affected by feature request changes. If I missed a solution, 
I would greatly appreciate a nudge in the right direction, but perhaps the 
development community is still reviewing how best to handle this...
 
Win 7 x64 SP1
QGIS 2.4.0 (x64 standalone installer)
 
Thanks in advance for any feedback,
James
  ___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] QGIS 2.4 Chugiak

[James Wood]

​As a user, I just wanted to express gratitude to the developers for all
the hard work, consideration, deliberation, and indulgence of the user
community. Your dedication to making this a competitive open source
alternative is not overlooked.

Thank you.
James
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer