Allow symbology export into Geopackage

[TomGeo]

When writing data from ArcGIS Pro into a geopackage the symbology is not preserved within the geopackage. It is possible to save symbology information within geopackages but it seems that's currently not supported by ESRI.

I would like to propose the implementation of  this functionality as a feature in ArcGIS Pro to increase the support of the geopackage format.

[JonathanNeal]

@TomGeo We use .lpkx, .slpkx, .mpkx to accomplish this now.
Share a layer package—ArcGIS Pro | Documentation

[BranislavBlagojevic]

Question not related to '.lpkx, .slpkx, .mpkx' then to 'to save symbology information within geopackages'!

[JonathanNeal]

@BranislavBlagojevic Yes, but why though when you have the alternatives.

Product development requires us to present this idea to our team and to prioritize it above other competing features.

Can you give us why geopackages is the preferred format?
What is the value that this change can deliver to you and our customers?

[CarlosGutierrez4]

@JonathanNeal Correct me if I am mistaken but the alternatives you mentioned are all proprietary esri formats. Geopackages are open-source and platform-independent. Many of esri's customers are government entities that are dedicated to providing data to all users, not just esri users, so having the ability to include symbology in a geopackage would be a very valuable improvement.

[JonathanNeal]

@CarlosGutierrez4 That's a good question on if we can support the sqlite in the same way as kml/kmz.  We would need to talk to the Geodatabase team to further our understanding, will make an internal topic issue on it and I will get back to you with a deeper understanding.

So, our current solution to open-source, platform-independence are the .kmz/kml formats.  They to allow data to glide from Esri, to non-Esri and back with symbologies.
Layer To KML (Conversion)—ArcGIS Pro | Documentation 
KML To Layer (Conversion)—ArcGIS Pro | Documentation

[CarlosGutierrez4]

@JonathanNeal Thanks for the follow-up. In my experience, kml/kmz formats do not handle the complex symbology that is used with geologic maps (e.g., dashed lines, lines with ornaments, etc.). Admittedly, I am not that experienced with the geopackage format but they do appear to be a superior format to kml/kmz. While Google Earth is a powerful visualization tool, it is not a true GIS application. Geopackages are compatible with open-source GIS apps like QGIS and provide significantly more functionality.

[RoseF]

@JonathanNeal I would like to support @TomGeo 's request for this enhancement and echo what @CarlosGutierrez4 mentioned about the importance of having an open source alternative that includes symbology. While the KML/KMZ option is available, it doesn't have some of the more robust capabilities that an actual database offers. At it's most basic, it'd be ideal to deliver our GIS data to our users in a single "package" such as a database. If this database could contain feature classes and non spatial tables, along with features like symbology, it'd be a significant improvement and help us answer some big questions we're asking right now.

The symbology on a geologic map is different from other maps I've made before -- almost every bit of it communicates some bit of science, from the size of the labels to the line decorations to the color-pattern combination of the polygons. While this information is stored in the attribute and non spatial tables of our geodatabases, it's a whole lot faster for a user to see a lot of the data/science at a glance if things are symbolized correctly. And after all, isn't this a big part of what a map is -- symbolizing tabular data with a spatial location for quick visual interpretation?

If you would ever like to take a look at a geodatabase that follows the national schema for geologic maps and how that data is presented to our users, I'm sure I speak for the larger group when I say I'd be happy to discuss! And a big thanks to you and Esri for taking our requests seriously -- these are the types of things that impact the day-to-day work of many GIS professionals and Esri users around the country.

[JonathanNeal]

Per conversation with @LanceShipman , we are currently doing it with our mobile map packages in our .geodatabase format which is sqlite.  There are no technical barriers to this request, just requires the kudos for the team to put in the release.  Will re-label this one to Geodatabase since they will be doing the work and the assessment.

[RoseF]

@JonathanNeal and @LanceShipman this is great news! Thanks so much for looking into it. Kudos will be forthcoming. 😁

[EricEagle]

Ultimately there are a lot more things that can/should be done with GPKG.  Some are being done by other groups outside the spec (e.g., QGIS building in support for GPKG domains).  However I believe Esri only supports aspects of GPKG that are explicitly identified as in-spec.  And currently there is no in-spec way of storing symbology (it's listed under "possible future work" right now).

I am not saying I agree with this; there is ultimately in fact no reason why a GPKG couldn't be just about as robust as a file geodatabase (I always found the insistence that GPKG is only a 'shapefile replacement' to be a little weak).  I am just saying the reality, and the reality here is that Esri doesn't do stuff with OGC formats that are out of spec.