The purpose of this document is to provide a step-by-step guide on how to create SVG files for existing multi-layered symbology styles. SVG symbology can improve performance in services, and is recommended for publishing of Utility Network Model services. This workflow requires ArcGIS Pro and Adobe Illustrator
Thank you, this is exactly what I was looking for!
Hi, @Anonymous User, this is great. is this more performant in Pro also, or only for web services?
Also, this is quite a manual process and has to be re-executed if modifying the original stacked symbology or a custom dict, and it’s challenging to script. Is it worth to suggest an ‘export flattened svg’ from a symbol or a style file as a Pro Idea? Theres a great addinx to import svg back into a pro style that would close the loop here https://carto.maps.arcgis.com/home/item.html?id=c25ab2da6ae343af9acc632120c7cf01 from this thread https://community.esri.com/t5/arcgis-pro-questions/bulk-import-svgs-to-shape-markers-and-add-to-stylx/td-p/1102959
This is awesome. Thank you so much!
If you have a lot of these you need to do, it's possible to create a C# Add-In that uses the ArcGIS Pro SDK to convert all the symbols in a layer, map, or even project into separate named SVG files.
@RobertKrisher - can you elaborate on the benefits of using SVG - given there are many things that can enhance the performance of services it would be helpful to understand were to prioritize using SVG in the hierarchy of service improvement oppurtunities. Thanks in advance.
@AlanHope I've always considered this a compatibility issue, I've never measured whether there is any benefit with regards to performance between the different symbology formats. I would imagine it would depend on the complexity of the CIM definition and whether you're using PNG or SVG. There are other tradeoffs for each of these formats concerning quality as well as functionality (i.e. symbol-level arcade expressions).
When this article was first written there wasn't an option to publish symbology that is compatible with all client types. So, if you had a web map or service that was used by a client that didn't support the full CIM Web Map specification you didn't have a lot of good options, and this was one of the workarounds.
Now when you publish a map you can choose to publish symbols that are compatible with all client types (png) or to retain the original CIM.