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]

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

[NicholasNilsson]

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

[RobertoRossi]

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

[SSWoodward]

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

[RobertoRossi]

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

1. if I open the attribute table of a Feature class from the Catalog pane, I'm able to Add a new field;
2. 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.

[SSWoodward]

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.  

[RobertoRossi]

thanks @SSWoodward for the clarifications!

[JordanCarmona]

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

[NicholasNilsson]

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.