idea Full functionality for .gpkg in ArcGIS Pro in ArcGIS Pro Ideas

Full functionality for .gpkg in ArcGIS Pro

CordulaGöke — Thu, 13 Jun 2024 11:20:08 GMT

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.

Re: Full functionality for .gpkg in ArcGIS Pro - Status changed to: Needs Clarification

SSWoodward — Thu, 13 Jun 2024 19:53:47 GMT

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?

Re: Full functionality for .gpkg in ArcGIS Pro

RTPL_AU — Fri, 14 Jun 2024 07:26:22 GMT

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

Re: Full functionality for .gpkg in ArcGIS Pro

CordulaGöke — Mon, 17 Jun 2024 09:50:40 GMT

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

Re: Full functionality for .gpkg in ArcGIS Pro

CordulaGöke — Fri, 21 Jun 2024 13:59:18 GMT

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

Re: Full functionality for .gpkg in ArcGIS Pro

CordulaGöke — Mon, 01 Jul 2024 11:14:20 GMT

@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

Re: Full functionality for .gpkg in ArcGIS Pro

NicholasNilsson — Thu, 23 Jan 2025 13:48:28 GMT

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

Re: Full functionality for .gpkg in ArcGIS Pro - Status changed to: Open

SSWoodward — Fri, 21 Feb 2025 17:03:38 GMT

Re: Full functionality for .gpkg in ArcGIS Pro

SSWoodward — Fri, 21 Feb 2025 20:00:55 GMT

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.

Re: Full functionality for .gpkg in ArcGIS Pro

RTPL_AU — Mon, 24 Feb 2025 05:31:59 GMT

@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 😉

Re: Full functionality for .gpkg in ArcGIS Pro

CordulaGöke — Tue, 04 Mar 2025 11:31:52 GMT

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

Re: Full functionality for .gpkg in ArcGIS Pro

SSWoodward — Tue, 04 Mar 2025 17:06:10 GMT

@CordulaGöke glad I could help. Most folks don't have the time or capacity to dig into the release notes for stuff like that. I certainly don't expect that from users. I'm super happy to have conversations with folks on here and bring new features to light. It's why we make ESRI staff available here on the boards, so we can share things like this.

@RTPL_AU Your downvote is certainly noted and highlights what makes these types of conversations so complex. Some users want all of the functionality for a feature, some folks beg us not to implement that same functionality. I'm glad to be able to have these types of conversations with users.

@NicholasNilsson I encourage you to have your organization put in an enhancement request for the functionality they want to see, in addition to the conversations being had here on the Ideas boards. It will help keep the momentum on the feature request.

Re: Full functionality for .gpkg in ArcGIS Pro

NicholasNilsson — Wed, 05 Mar 2025 07:54:17 GMT

@SSWoodward Thank you for the information. Very nce to be able to have this discussion this way! You recomend that my organsiaation shuould put in an enhancement request for the functionality we want. What is the best way to do that? I just wonder so it will be done the right way. 😀

Re: Full functionality for .gpkg in ArcGIS Pro

RobertoRossi — Mon, 15 Sep 2025 16:02:19 GMT

I see that in ArcGIS Pro 3.5 the Add Field button is still gray

but we can Add (but not remove or rename) Fields using the Data Design > Fields Option

Roberto

Re: Full functionality for .gpkg in ArcGIS Pro

SSWoodward — Mon, 15 Sep 2025 16:41:31 GMT

@NicholasNilsson the easiest wat to file a bug or an enhancement request is by contacting ESRI Technical Support

@RobertoRossi Thanks for pointing this out, this was also the behavior in previous versions. Users can add fields to classes in a Geopackage through the feature class's fields view, its the shortcut from the attribute table of feature layers created from Geopackage feature classes that shows as greyed out when viewing the layer. Opening the fields view of the feature class, or opening the attribute table of the feature class, and not the feature layer, allow you to interact with the data as usual. This is the bug discussed previously.

Re: Full functionality for .gpkg in ArcGIS Pro

RobertoRossi — Tue, 16 Sep 2025 10:36:09 GMT

@SSWoodward, thank's for your answer. I did not catch the previous discussion about the bug (February post), now it's clearer to me.

To recap:

if I open the attribute table of a Feature class from the Catalog pane, I'm able to Add a new field;
if I open the attribute table from the Contents pane (this is what you call "the attribute table of the feature layer", correct?) I'm not able to Add a new field.

I've also just realised that, if I want to Delete a field I can do it working from Table Tab (or right click on the field name), I cannot do it from the Field View. Finally, correct me if I'm wrong, at the moment it's not possible to Rename a field.

Re: Full functionality for .gpkg in ArcGIS Pro

SSWoodward — Tue, 16 Sep 2025 19:15:16 GMT

There are some yesses and some no's here so I'll try my best to help clarify.

A feature class is the actual data in the data source. A feature layer is an in memory representation of this data that is created when we add data from a feature class to a map. For Geopackages, a layer in the map is created using a query layer, which uses a SQL query issued to the geopackage, you can view this query in the layers properties. The return of this query creates the layer in the map.

1. Opening the attribute table of a feature class ( data in the data source as viewed in the catalog ) shows the option to add a field in the UI since users are interacting directly with the data. When there is at least one row in the feature classes' attribute table, the Delete field option is also available in the UI. The delete option is not present on an empty table. I'm currently chatting with the geopackage folks about this observation.

2. Opening the attribute table of a geopackage based feature layer does not support schema operations since you are looking at the result of a SQL query. Query layers generally are read-only, however for geopackages you are able to edit features, but not schema.

Users are able to delete fields and alter field names by passing the feature class in the geopackage to the Delete Field and Alter Field geoprocessing tools respectively. Your observation that these functions are not accessible in the fields view is also correct.

Re: Full functionality for .gpkg in ArcGIS Pro

RobertoRossi — Thu, 18 Sep 2025 16:06:30 GMT

thanks @SSWoodward for the clarifications!

Re: Full functionality for .gpkg in ArcGIS Pro

JordanCarmona — Tue, 28 Oct 2025 15:28:21 GMT

This comment really nails it on the head; geopackage fanciers expect that when a data type is "supported", that it is supported 1:1 like any proprietary Esri format (shapefile, file geodatabase, mobile geodatabase).

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?

It seems that there is a bit of a disconnect on what capabilities Esri believes are already functional within ArcGIS Pro (but currently broken/bugged) and what are OGC specifications for the geopackage that have not yet been built out within ArcGIS Pro.

A compatibility matrix would solve a few different problems by showing users:

functionality that should work but currently has a bug
functionality that works
functionality that is not yet built
- roadmap terminology would be helpful (short-term, mid-term, long-term, un-planned)

The other benefit is that this would serve as a centralized communication area for all of the ArcGIS stakeholders that are interested in this specification becoming a first-class citizen within the ecosystem.

similar to how the Experience Builder Roadmap, centralizes user feature requests: Feature planned for 2025 in Experience Builder
un-dilute the actual interest in geopackage functionality; currently there is no community group for it, so mentions and requests are scattered in a variety of places

And really, at the end of the day, how can development on the geopackage team be meaningful if there is not an accurate idea of what works, what's missing, and what the users want to prioritize?

And if we really wanted to swing for the fences, there could be an Open Geospatial Consortium (OGC) ideas/community where we could centralize discussion of all the new formats that are shaping the geospatial industry and that we all want to use inside of the ArcGIS ecosystem, like:

GeoParquet
GeoPackage
Cloud Optimized GeoTIFFs
FlatGeouf

Re: Full functionality for .gpkg in ArcGIS Pro

NicholasNilsson — Wed, 29 Oct 2025 07:15:58 GMT

Hello,
I think this sounds like a good idea!
I would make the road ahead more transparent for users. It would also give users a timespan when to expect upcoming solutions.