Full functionality for .gpkg in ArcGIS Pro

[CordulaGöke]

At the moment, there are limitations on what is possible with .gpkg files. I can only load them to new maps (and then move them to existing maps), I can edit, but I cannot add columns or drag&drop them into the map as QGIS does.  Since I never use gdb, the ultimate wish would be that I can choose them as default output format/WS instead of .gdb for all tools.

[SSWoodward]

Thanks for the idea @CordulaGöke.

We'd love some more information about it.  Classes in geopackages can have fields added or removed, and can be dragged into the map just like a gdb feature class or table.  How are you trying to achieve this and what version of ArcGIS Pro are you using?

[RTPL_AU]

@SSWoodward  https://www.geopackage.org would be a start.

As it is an open standard there shouldn't be any reason for ArcGIS to not support the full functionality matrix of geopackages - other than those pesky politics or marketing reasons...

I currently have to use QGIS a fair bit to support clients that use gpkg and I'm sure I'm not the only one.

[CordulaGöke]

@SSWoodwardI work in ArcGIS Pro 3.2.2 and use a .gpkg produced in QGIS.

1 Classes in geopackages can have fields added or removed: I open the table and would continue with "add" which is greyed out. Similarly when you rightclick on the field name to delete. If you e.g. use calculate and define a new field, it throws an error.

2 Can be dragged into the map: I try to drag and drop from file explorer and get the following message:

 In QGIS it is possible.My gpkg has only 1 dataset, so I assume you would load all in QGIS if there were more. I just tested from catalogue view, and it really worked to add the dataset, so that is great. That changes the main complaint to that you cannot use the right-click-"add to Map" method, only "add to new Map" and adding from the explorer.

3 as default output format/WS instead of .gdb for all tools: Forcing people to set a default gdb does not help to promote ESRI products, more the opposite. People try to find out how to navigate through the restricted framework and often produce a folder which is called LayerName_ARCGIS and LayerName_QGIS/MapINFO It is extra work,  leading to unnessary uptake of storage space and could be easily avoided if all could agree to use gpkg for exchange. This requires for the occasional user that gpkg is really easy to handle and appears more prominently in the tools as an option. There might be .gdb functionalities that it does not cover everything a .gdb supoorts, but from my point of view it is really a good format for big datasets and just one file which makes it great for exchange.

[CordulaGöke]

@SSWoodward Something that I forgot to mention is, that it is often not possible to neither use the .gpkg layers directly nor export with the normal geoprocessing tools (I haven't used datainteroperability). It does not indicate inapropriate input types. When exporting I get both for QGIS and R produced .gpkgs:

ERROR 002809: Field OID in transekt_points2 is of an unsupported type for the output workspace.

When using tools the messages vary.

[CordulaGöke]

@SSWoodwardI realized when searching for workarounds that it also does not seem to work in arcpy. In the other idea the status is changed to offered, but is stopped working. https://community.esri.com/t5/arcgis-pro-ideas/install-sqlite3-from-sqlite-org/idc-p/1498942#M30853

[NicholasNilsson]

Within the national research infrastructure Swedigarch, the Department of Archaeology and Ancient History at Uppsala University in Sweden, are working on a standardized way to distribute data from archaeological sites that have been excavated.

The format they have chosen is the OGC standard format GeoPackage. It can be used efficiently in QGIS and FME without restrictions. However, when trying to open the GPKG in ArcGIS Pro there are currently limited functions for the GPKG format. As hey proceed with developing a national standard, it would be very useful to be able to open and use the data in ESRI’s products too.

There are three issues. 

Will ESRI implement the GPKG related tables extension? http://www.geopackage.org/guidance/extensions/related_tables.html

Will ESRI implement the ability to read features with different geometry within the same table in a GPKG? Requirement 20 from: https://www.geopackage.org/spec/#gpb_format

Will ESRI implement the ability to read feature database views from a GPKG? Requirement 150 from https://www.geopackage.org/spec/#feature_user_tables

[SSWoodward]

Thanks for the ping @CordulaGöke 

This idea has been stuck in needs clarification because there are multiple ideas within it that prevent us from being able to determine what idea is being supported when kudos are given to it, and from being able to correctly mark it as under consideration or implemented. 

In your most recent comment you said that your main complaint was that "you cannot use the right-click-"add to Map" method, only "add to new Map" and adding from the explorer."  This bug is no longer present in ArcGIS Pro 3.4. If this is the focus of your idea, I will close this as implemented.

There are multiple other ideas within this that I would not be able to mark as implemented.

The first is the inability to add fields when working with a feature layer created from a geopackage feature class. I do still see this bug in ArcGIS Pro 3.4.  I have brought the issue up with the appropriate team.  I encourage you to file a bug for this as well.  Since this is a bug and not an idea for a new feature, I would close this issue since bugs don't meet the requirements of an Ideas submission. 

The next is a feature request to be able to add an entire workspace to a map using drag-and-drop.  This is not currently supported on any workspace, not just geopackage, so I would encourage you to submit that as a unique idea.

Several additional ideas were added to the thread during conversation; Support of the related tables extension, multiple geometry types in a singe feature class, and the ability to create views in a geopackage.  These are all great ideas and I encourage users interested in them to open them as unique ides so the community can support and discuss them.  

[RTPL_AU]

@SSWoodward I started writing a new Idea but got stuck with picking out all the features that a gpgk has, that Esri doesn't currently support.
Based on the title of this Idea, would it not be better for Esri to draw up a spec matrix of gpkg capability vs ArcGIS equivalents and then define a roadmap towards feature equivalency?
Every user may have a slightly different requirement, AND we have to rely on the small fraction of overall users who participate in the promotion of Ideas.
With a hard push in some jurisdictions to only support open data formats (as @NicholasNilsson can attest to from what I can see) I would prefer Esri to be on the front foot rather than be reactive and we (the user) not have to face our 'Apple a day takes the encryption away' scenarios.

Some of the low hanging fruit would be to read & save default symbology to geometry tables and to create/edit/use field domains.

To close off - and I wish we could downvote something (and buy additional votes in packs of 100) - please do not allow the ability to save multiple geometry types and text objects into a single feature class. This will take us back to the dark ages of MapInfo & people making a full map in a single unprojected tab file. I know things are a bit complex in the US right now but allowing this feature to exist again is not the way to make the world right 😉

[CordulaGöke]

@SSWoodward thank you for the update and clarification of what you consider a bug or not implemented. @RTPL_AU made a perfect point about the complexity of the topic and opinions. If you want me to split it up (and I really take the time), it will result in many suggestions. With your explanation, what you consider a bug or not, in this case I can start bug reporting. In general there can be some detective work involved in determining, if the function is just lacking or not working as intended.

It is great that something has happened in the meantime. I was not aware of that. Once I have found out that something is not working as intended, I will not try to use that function again. I normally don't read version-release descriptions.